Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: The Documentary

herbsutter.com

Post reply on HN
Print view View original

131–140 of 334 posts

Re: C++: The Documentary

#131

Post by drysine »

whstl wrote: post #71
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze. There's basically dozens of very nice languages inside C++. That can be a blessing or a curse. I'm anxious for Herb Sutter's CPP2/CPPFront to become a stand…

>I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.

Why? It doesn't remove complexity, it (partially) hides it and makes the whole thing even more complex.

Re: C++: The Documentary

#133

Post by johannes1234321 »

zabzonk wrote: post #83
flohofwoe wrote: post #43

Earlier quoted context omitted.

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though. Edit: Also not sure what can possibly be downvoted here.

auto_ptr is an exception. Not the rule.

Regular expressions in C++ are an example "everybody" advises against using, but it's still there. vector will stay forever and so on.

Re: C++: The Documentary

#134

Post by Joker_vD »

einpoklum wrote: post #99
tialaramex wrote: post #94

Earlier quoted context omitted.

So, a few things (aside from the whole nomenclature argument already in another reply) 1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea. 2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++)…

> There's a single "I guess I would use this" container type, std::vector. About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy. Agree with your takes on most of the c…

> a similar type, but whose size and capacity are fixed on construction and never change.

There is std::array for that. Also, for a type with fixed capacity but variable (up to that capacity) size, we're getting std::inplace_vector soon™.

Re: C++: The Documentary

#135

Post by hcrisp »

tenderfault wrote: post #60

So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?

I read it recently. I liked a few of the chapters especially how policy classes fix some issues with OO design. I do recommend asking an AI chatbot to summarize each chapter and say what the modern equivalent is since some of the idioms have improved. I think one whole section was obsoleted through the use of std::variant and std::visit.

Re: C++: The Documentary

#136

Post by bregma »

flohofwoe wrote: post #34
jdw64 wrote: post #14

Earlier quoted context omitted.

There are so many standards and idioms that it gets confusing. There are still legacy codebases out there — some codebase still use C++98 as their standard, others use C++11... And with Unreal Engine, the modern C++ standard is C++14, right? There are things like smart pointers, but some places don't even use them. I feel like there are just too many features. When I saw template metaprogramming — that new feature —…

> When I saw template metaprogramming — that new feature — I realized I have no talent for C++. It's not a new feature. And tbh, compared to Typescript, C++ templates are tame ;) (but yeah, deciding when to stop digging into the template metaprogramming rabbit hole requires some common sense and sanity, too much template complexity is almost never worth the hassle)

It was a new feature. Over 30 years ago now. Template metaprogramming was even featured in the ARM.

Re: C++: The Documentary

#137

Post by justin66 »

jdw64 wrote: post #14
bayindirh wrote: post #13

Earlier quoted context omitted.

Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code. I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.

There are so many standards and idioms that it gets confusing. There are still legacy codebases out there — some codebase still use C++98 as their standard, others use C++11... And with Unreal Engine, the modern C++ standard is C++14, right? There are things like smart pointers, but some places don't even use them. I feel like there are just too many features. When I saw template metaprogramming — that new feature —…

> And with Unreal Engine, the modern C++ standard is C++14, right?

Unreal Engine depends on C++20 at this point.

https://dev.epicgames.com/documentation/unreal-engine/epic-c...

Re: C++: The Documentary

#138

Post by flohofwoe »

jibal wrote: post #106
flohofwoe wrote: post #25

Earlier quoted context omitted.

For games, C++ becomes a much simpler language since game code bases usually ignore the C++ stdlib (at least mostly, and for good reasons, e.g. see [0]). And without the stdlib C++ is actually kinda-sorta okay-ish. Related, the main problem with the C++ ecosystem is that everybody carves out their own language subset, so it's not one ecosystem but many ecosystems with contradicting styles and language/stdlib subsets.…

Your citation refers to the register keyword and trigraphs, among other language features -- the author seems to have forgotten his own point, among a number of other inconsistencies and contradictions, and at times seems to go out of his way to come across as a jerk, e.g., "This is what fifteen years of standards work on an eight-letter keyword looks like". People love to rag on the standards committee. I was on X3J…

The C Committee is fine and doing great work! The C++ Committee could actually learn a thing or two from how things are done on the C side.

Re: C++: The Documentary

#139

Post by bregma »

zabzonk wrote: post #83
flohofwoe wrote: post #43

Earlier quoted context omitted.

As I understood the article, the main critique is that the stdlib has no concept of deprecation and breaking backward compatibility. E.g. the C++ committee is quick to add badly designed features to the stdlib but then can't roll them back when people actually realize that those new features are useless for most real-world code.

Badly designed things get replaced. For example unique_ptr replaced auto_ptr. I'm not sure if the language standard actually supports the term "deprecation" though. Edit: Also not sure what can possibly be downvoted here.

ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.

Re: C++: The Documentary

#140

Post by kibwen »

GodelNumbering wrote: post #89

Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still

An elegant language is one that achieves a lot with very little. Forth and Scheme are elegant languages. You're free to like working in C++, and you can sure achieve a lot with it, but I don't think it's controversial to say that it does not do so with very little.
Post reply on HN