Hacker News Reader

Also, the C++ committee is very serious about not paying for what you don't use. You can rest assured that there's no unused, hidden C++ bloat that is chipping away at your frame budget.

This is not meant to be a strawman against the complexity cost argument, it's just a related feature of C++ that I thought might be worth explicitly pointing out in case anyone is misinterpreting.

Also, if anyone has a credible dispute against the claim I'd like to hear it.

You are describing 'zero cost abstractions'. Except that they are anything but zero cost. Game developers and low level programmers shy away from them because of their impact in compile and build times, debug build performance and stack trace bloat, increased cognitive load, reduced refactoring ability. Even std::unique_ptr has runtime costs in release builds that a raw pointer does not.

In game development performance is a feature and anything that makes performance and memory usage less deterministic is frowned upon, like a GC. But iteration times are still paramount and things that make compile, load and link times longer and make it more difficult to debug are also frowned upon. Yes, we'd like to have our cake and eat it too :)

> Even std::unique_ptr has runtime costs in release builds that a raw pointer does not.

O RLY ? https://gcc.godbolt.org/z/QhbUjI

How would I create the pointer to int in the unique_ptr case without initializing the int? I tried this: https://gcc.godbolt.org/z/SfVxzU

I expect there is a way, just I don't know it.

See the docs : https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...

For C++ < 20 replace `std::make_unique<int>()` by `std::unique_ptr<int>(new int)` (which with all explicit uses of `new` can end up not being safe in some cases (in that case, only if you've not enough memory to allocate an int which should not really be a common occurence...)

For C++ >= 20 you get std::make_unique_default_init which does that properly.

Have created a Stackoverflow question focused on this point:

https://stackoverflow.com/q/58050872/1593077

Yes, really. It's fine for simple types but for more complex types in more complex situations, you pay the price.

Unique pointers carry around not just the type but also a default deleter, if you provide one. That deleter has to be copied around, checked for nullptr before execution and set to nullptr when ownership changes.

For even more examples of this have a look at this talk when it comes out: https://cppcon2019.sched.com/event/Sfq4/there-are-no-zero-co...

Only if the deleter you define has any state, which is very rare and in that case you would need to copy that data around anyway...

(for example: https://gcc.godbolt.org/z/mU7hub)

It's pretty stupid to compare a unique_ptr with a deleter that contains state to a pointer - obviously those two things are completely different and the unique_ptr contains way more information.

> You are describing 'zero cost abstractions'

No, that's a different (and orthogonal) concept. The point is that in C++ "you don't pay for what you don't use" - whether it's a cheap or an expensive abstraction, if you don't use it then its overhead won't affect your code's performance.

However, many of the C++ abstractions are zero-cost in many common cases.

> Game developers and low level programmers shy away from them

No, they don't. They shy away from abstractions which are too expensive; or whose scope of optimization doesn't fit the game's use; or which don't combine well with out-of-standard-library code used in the game etc.

But game developers use _lots_ of C++ abstractions; and fancy non-C-like C++ features.

Serious game developers often do not use STL as a matter of habit and principle.

That goes for most of your points about standard libraries. If you are developing code that you expect (or hope) to run on Windows, Linux, Nintendo consoles, phones, PS4's and Xboxes and expect to know the real performance cost of operations, you will be writing all of your own standard libraries anyway. It is very much a problem of "...the complexity of non-standardized often-inconsistent idiosyncratic platforms and libraries for achieving the same things."

> Complexity of implementation is not complexity of use.

And that's where the language complexity comes into play. Game developers who are bootstrapping need to implement and use these pieces. If you are simplifying your life with C++ features, you must know the ins-and-outs and you cannot rely on new language features because you don't have a choice of compiler in most cases.

> I find looking up language features, and quirky 'clever' api's incredibly tiring. The ideal language would be one I can memorize, and then never have to look things up.

This is a fair ask and is definitely more accurate of C than C++. What you might write is longer, more tedious code, but that is its own trade-off.

From the article:

"...I care about the speed of the compiler. I am not a zen master of focus, and waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone."

5 minutes? Commendable, it's more like 2 hours in my case.

Some people just like writing code. You can't say that C's features are insufficient, when you can implement the vast majority of C++ features in native C, and all of 'em with tooling. What's wrong with having direct control of only the features you need? What's wrong with code generation? Not to trample on C++, I like it (albeit less than C). I would definitely create C++ if it didn't exist.

> when you can implement the vast majority of C++ features in native C

No, you absolutely cannot, even in principle. C++ is not "C with classes" and some syntactic sugar like it started out. That's not been the case for many years already.

Also, even the features you can implement - you won't; you don't have the person-years for that. You will have to, need to, use libraries. For those you need to compare the libraries available for C and for C++, and C comes up quite short (not just because C libraries are also usable in C++...)

"No, you absolutely cannot, even in principle."

Which is why it has been done for my 2D Second Life clone?

Some of us can very easily implement C++ stuff in native C.

So which feature can you not implement? The only I can think of which you'd have real problems are anonymous functions/lambdas. Most other features I think you can implement. It won't look the same, but it will serve the same purpose.

Things coming to mind:

Pointers which can't be NULL (aka. references)

Exceptions which also clean up intermediate frames (the exception itself can be done with longjmp, but no destructors which could be run)

Pointers that can't be null are usually implemented by struct embedding. That's typical for Linux kernel code, for example.

Destructors. It is the defining feature of the language; everything else in the language extends their reach. They are the key to full exercise of code paths, and thus reliable code.

A programmer who makes full use of destructors is simply a better programmer than one who doesn't.