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

61–70 of 334 posts

Re: C++: The Documentary

#61

Post by Chaosvex »

flohofwoe wrote: post #40
samiv wrote: post #31

Earlier quoted context omitted.

If you don't use the STL you end up re-implementing it yourself. Usually poorly.

> 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 turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.

Re: C++: The Documentary

#62

Post by demorro »

flohofwoe wrote: post #40
samiv wrote: post #31

Earlier quoted context omitted.

If you don't use the STL you end up re-implementing it yourself. Usually poorly.

> 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…

I find it hard to agree that the stdlib is poorly designed and implemented. In my entire career it has pretty much worked entirely to spec.

Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.

Re: C++: The Documentary

#63

Post by VoidWarranty »

Davidbrcz wrote: post #49
logicchains wrote: post #22

Earlier quoted context omitted.

>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. If you'd already been using it for 10+ years you wouldn't feel that way, because you'd already have memorized a lot of it.

Except the language keeps growing, with - new features overlapping old features previous standards without replacing them or deprecating them. - new features not usable by the layman - ... See function::copyable_function vs std::function, modules, coroutines, Reflection syntax is cryptic at best, ...

You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment.

Hell, if you wait long enough, they'll just deprecate it before you can care to bother.

Re: C++: The Documentary

#65

Post by flohofwoe »

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…

> bounds checking in release builds

Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).

The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, everything) was somewhere in the 2..3% range, which is fine when budgeted for upfront.

Re: C++: The Documentary

#66

Post by fc417fc802 »

zerr wrote: post #24
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…

You can be pretty productive even with 70% of the language :) It is a common misconception that C++ is suitable only for game engines and similar domains. It is perfectly fine for applications domain as well. As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.

> You can be pretty productive even with 70% of the language

Or even far less than that. I like to use it as C with lambdas and namespaces. Sprinkle in metaprogramming as needed. Even just not having to remember to call cleanup code thanks to dtors would alone be enough to sell me on it.

Re: C++: The Documentary

#67

Post by Chaosvex »

_hao wrote: post #6
scott01 wrote: post #3

[flagged]

I have the utmost respect for Casey, but his disdain for Stroustrup is unfounded. The fact of the matter is C++ occupied a niche in the right place and at the right time, and it grew from there. Many mistakes have been made, but Stroustrup is in no way personally responsible for all of them and I don't think Stroustrup is a bad programmer (something I've heard Casey say in some of his videos). You can argue that the…

Strangely, I've never seen any nice code from Casey despite all of the mud slinging he's done over the years. Maybe it exists somewhere but I watched a lot of Handmade Hero when it was starting off and the code was a mess.

It feels as though he just attracted an audience of junior developers who take everything he says as gospel, as is often the case with social media programmers. Lord knows I've argued with some of them and they usually crumble as soon as they don't have one of his opinions to throw back at you.

Re: C++: The Documentary

#68

Post by Chaosvex »

flohofwoe wrote: post #65
Chaosvex wrote: post #61

Earlier quoted context omitted.

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…

> bounds checking in release builds Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course). The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens…

That's your opinion, others won't agree and would much rather not pay the price at all.

Re: C++: The Documentary

#70

Post by W0lf »

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?

Yes, I feel the same way. I met Andrei once on a Meetup in Munich, basically telling him that he taught me how to think which led to a somewhat awkward conversion. Fun times nonetheless :-)
Post reply on HN