hplus0603 said:
but all that complexity also makes me producing working, bug-free code take longer. And templates increase compile times

My experience too. If i would handle such options with templated specializations (which i considered), the ‘software architecture’ part of work becomes just tedious / distracting.
And while i only work on tools currently, not sure if i would take that burden for each and every runtime code either.

Why should we optimize an ass out, if later artists generate shaders from nodegraphs, in game GUI runs with interpreting html and CSS, or whole game logic is implemented with scripts? : )

(Did not know about std::optional though. I'm really slow with catching up and only adopt what i see occasionally in other peoples code)

hplus0603 said:
They have distributed compile farms, and any 0.1% savings in runtime they can achieve saves their companies millions of dollars every month.

That's really interesting to hear. I always assumed some sloppiness about performance is the norm quite everywhere nowadays.

hplus0603 said:

However, what the true baller C++ programmers want you to do, is use template specializations/deductions to generate optimal code in each of the present/absent combination cases. And here is where my frustration with C++ starts showing: the goals of the library writers and standards developers are slightly different from my goals. Most of them write code that runs on Xeon datacenter servers with terabytes of RAM. They have distributed compile farms, and any 0.1% savings in runtime they can achieve saves their companies millions of dollars every month. They're totally Stockholm Syndromed into the idea that no cost is too high for a programmer in the pursuit of full efficiency.

Games need high frame rates, true, but we also need to actually ship tons of content using a smallish workforce. All the complexity that was added with rvalue references (and thus xvalues, glvalues, and so on) may allow you to write certain classes of templates easier, and save one instruction of moving a value in the edge case, but all that complexity also makes me producing working, bug-free code take longer. And templates increase compile times, and frequently also increase executable binary size, which has its own follow-on costs – loading plugins takes longer at runtime, invoking a tool takes longer per invocation, and so forth.

Maybe it's a problem of different users and language maintainers pulling in different directions. I know of developers who mainly want to write beautiful and maintable code, those who want to write performant code, and those who just want to ship features. These three use cases generally put different requirements on the code and definitely lead to to different approaches. It seems C++ allows programmers many ways of solving the same problems (partly because of legacy reasons), which make it so that these approaches branch off even further than if the language didn't allow all these options.

hplus0603 said:

Even unique pointers have overhead, epically if you are going to pass them around.

There is a lot of bullshit in the standards and libraries to make it so that they really don't. Assuming you have the bleeding edge of compiler and standard library, a unique_ptr<> should be as efficient as a raw pointer, and give you some ownership guarantees. Still no Rust, of course.

I've seen a couple videos on the overhead of unique_ptr, however your right in that it isn't really much and the trade off is worth it. The problem with using it everywhere is that it is supposed to signify ownership, and when you pass an object into a function for some processing, that function does not really own the object. You can always pass a unique_ptr by reference but now you are creating an extra complication for no other reason than to stick to some mindset. I agree with what Herb Sutter says in the video Fleabay posted. However uniqeu_ptr itself isn't bad, if used correctly.

My main issue is with shared_ptr, which I consider just bad 90% of the time, and this is coming from someone who has used reference counting for 30 years. An intrusive reference count is a better solution for the vast majority of cases you need it.