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

141–150 of 334 posts

Re: C++: The Documentary

#141

Post by einpoklum »

Joker_vD wrote: post #134
einpoklum wrote: post #99

Earlier quoted context omitted.

> 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™.

std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)

Re: C++: The Documentary

#142

Post by bregma »

pjmlp wrote: post #72
jdw64 wrote: post #11

It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…

Not really, despite all its warts, it is exactly because of them that many reach out to C++. Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks. The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C a…

I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years.

Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certification. If someone's life depends on your software, you really want to be able to reason about its correctness because orange jumpsuits enhance no one's complexion.

Many of customers are now using C++. From the problems they have reported, well, they just shouldn't. It's not that it is a bad language (it isn't) or that it is inherently unsafe (it really isn't: exceptions are safer than propagating return values as long as you use them in exception conditions, because not catching one will return you to a designed safe state very quickly, and RAII is the best thing since sliced cheese). It's that cutting and pasting from Stack Overflow, and now vibe coding, makes for massive codebases that are next to impossible to reason about. I now see a lot of problems from customers where my first reaction is "don't write code like that" and "you can write bad JavaScript code in any language, can't you?". While it butters my bread and I enjoy the language, I really recommend against using C++ for safety-certified embedded software. Stick to C.

Re: C++: The Documentary

#143

Post by bregma »

tialaramex wrote: post #110
tenderfault wrote: post #50

Earlier quoted context omitted.

funny, I think the same about rust.

(Safe) Rust is a lot better about the "Pit of Success" design than C++ There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.

C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.

Re: C++: The Documentary

#144

Post by mirmor23 »

Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity.

IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to spend as much time to sanitize the implementation with Coverity/Valgrind and the ilk when the compiler could've handled it.

With C++98, Bjarne's book on c++ internals could've give you good insight into what went on, but later it turned into a whole cottage industry of "effective, more effective, proficient, performant, c++" series of books -- so kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived). I'm happy to have spent time to learn problem domain instead.

I'll still watch the documentary since it has some of my favorite folks (Kernighan, Stepanov).

Re: C++: The Documentary

#145

Post by bregma »

pjmlp wrote: post #78
Davidbrcz wrote: post #56

Earlier quoted context omitted.

No it's not. The language keeps growing, with - new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less key for transparent lookup in maps) - new features not usable by the layman (coroutines ...) - Cryptic syntax (reflection...) - Stuff you are told not to use because of performance reason and that cant be fixed…

So a bit like Python or any other language of similar age.

Python3 is what, 15 years old?

Re: C++: The Documentary

#146

Post by criddell »

Chaosvex wrote: post #61
flohofwoe wrote: post #40

Earlier quoted context omitted.

> Usually poorly. On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger. A specialized dynamic array class in a few hundred lines (at most!) and with ju…

Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature. You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time. NIH implementations are usually grossly inferior because as it…

Sometimes there are ways of getting runtime bounds checking.

For example, both of these return the 3rd element of a std::vector:

    auto val1 = vec[3];     // no bounds checking
    auto val2 = vec.at(3);  // bounds checking

Re: C++: The Documentary

#147

Post by bregma »

bayindirh wrote: post #73
Davidbrcz wrote: post #56

Earlier quoted context omitted.

No it's not. The language keeps growing, with - new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less key for transparent lookup in maps) - new features not usable by the layman (coroutines ...) - Cryptic syntax (reflection...) - Stuff you are told not to use because of performance reason and that cant be fixed…

I wonder how many programming languages would be able to devoid of all or some of these problems when they are 40 years old. It's easy to compare new and old languages, and saying older languages are wrinkly. Let's see how other shiny programming languages look like when they are 40 years old.

There are two kinds of programming languages: the kind everyone complains about and the kind nobody uses.

Re: C++: The Documentary

#148

Post by GodelNumbering »

kibwen wrote: post #140
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.

Makes sense. This appears to be also a symptom of whatever you work on most (or start with), your brain starts to absorb that into its way of thinking.

Re: C++: The Documentary

#149

Post by criddell »

TonyAlicea10 wrote: post #122

I always tell web developers I teach that the language of the internet isn’t JavaScript it’s C++. Web devs are just users playing in a C++ dev’s program. ;)

I tend to think of the web and the internet as distinct things.

For the language of the web I'd probably nominate HTML.

For the language of the internet it's a lot less clear to me.

Re: C++: The Documentary

#150

Post by tialaramex »

bregma wrote: post #143
tialaramex wrote: post #110

Earlier quoted context omitted.

(Safe) Rust is a lot better about the "Pit of Success" design than C++ There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.

C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.

Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.

That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable.

† The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds

Post reply on HN