Lol.mar wrote: ↑Wed Nov 14, 2018 2:00 amYes, well. I think anyone can write a proposal and it may/may not make it into the standard.lucasart wrote: ↑Wed Nov 14, 2018 12:24 am This is typically the result of the "design by a committee" approach:
* some idiot, who just discovered namespaces, and wet his pants dreaming about them says: hey this is awesome, we should encapsulate C library in a namespace too!
* someone else, likely the political kind, who knows it's a stupid idea, but doesn't want to say it to not offend the aforementioned idiot says: hum... ok, but let's not break backward compatibility, so we'll duplicate everything, with and without 'std::'.
Which is why good language design, and good design generally, can never result from committee decisions. The benevolent dictator approach is far superior, and avoids this kind of nonsense.
Generally speaking, I think it's better to have a couple of competent people rather than hundreds of random guys proposing random stuff
that solves absolutely nothing and just adds unnecessary bloat.
I'll rant a bit about things I dislike about C++ now, take it with a grain of salt (IMO/YMMV)
There were some good changes since C++11, but also some disasters. Obviously this is a matter of opinion, it's hard to satisfy everybody...
The only thing that's obvious is that it gets more and more complicated and bloated, C++ is not elegant nor pretty.
I wonder how this shit made it into the standard btw: http://www.stroustrup.com/C++11FAQ.html#gc-abi
Nobody implemented it, nobody every uses it. GC is NOT the way to manage memory. Especially in realtime applications.
Of course you can use Boehm GC for C++ which scans the whole heap, all stacks of all threads and all registers, i believe "stop the world" type of GC with potential FPs.
In C++ or C, you can manage memory any way you want, preferrably on stack, you can write pool allocators, LIFO allocators or anything you need.
GC is for inexperienced programmers and solves nothing, you can still get leaks plus you get unknown and potentially unbounded performance hit that can occur at any time, lifetime of allocated objects is unknown, no control over actual memory usage.
I consider exceptions a disaster, many will probably disagree but yeah, if you don't mind tagging lots of functions with noexcept and like the false impression that your code is more robust with exceptions, go on. It's really just a hard-to-debug super-goto over several stack frames. Not to mention that probably nobody can write complicated code with strong exception safety without performance loss, those who think so are just delusional or never went beyond hello world scale.
Now good luck if someone loves to try {} catch(...) {} or throws across dynamic library boundaries
Multiple/virtual inheritance is another abortion, no need to go into details here.
The good thing about C++ on the other hand is that unless someone is forcing you, you don't have to use all the fancy features it offers just to be cool, it's still a very powerful language.
Another thing is move semantics. It solves like 2 problems but adds 20 more, a whole new layer of complexity. Many (not only beginners) actually
don't even understand how it works. std::move moves nothing, just "removes reference", it's actually move constructors and move assignment operators that do the heavy lifting;
so when you move from, you basically perform a shallow copy (+target cleanup in the case of move assignment) plus you need to invalidate the source object, because it will still be destroyed.
Now the symbol used for rvalue references means something else in templates and auto, in templates you also have to use std::forward if you want "perfect forwarding". A tremendous mess if you ask me.
Now people typically "move everything" because it's so cool, but it's really pointless to "move" POD types.
Also some even std::move return values, but don't understand that this will break RVO/NRVO, which is now actually even mandatory in recent standard.
So the only benefit is that the compiler can do default move ctor for you, but the price is rather high. I'd prefer a good auto-generated swap operator anytime which would be orders of magnitude simpler.
Now the standard library. I would say there are some good things, just streams is not one of them, they're so bad it's not even funny.
The standard imposes a lot of unecessary restrictions on some containers, so you waste tons of memory for various sets and maps which do heap allocation per node by default.
I don't know if this applies to all implementations, but std::map or std::set allocates root in constructor, this is also horrible, a good container should never allocate in default ctor. Fortunately there're custom allocators but still... set<int> typically consumes some 32 bytes per node in 64-bit mode, now add some 16 bytes heap block overhead...
Now heap allocations are very well optimized these days, most likely pooled for small blocks, they scale relatively well unless you start to allocate large blocks and get fried on global heap mutex or something like that.
Sure, you can use custom allocators (if I'm not mistaken the API still lacks realloc, which sucks)
Now someone wants to add a "2d rendering" library as part of the std, based on some ancient cairo, the API is absolutely horrible and reference implemention is piece of shit written by someone who doesn't have a clue, but this is actually really happening http://www.open-std.org/jtc1/sc22/wg21/ ... 0267r8.pdf
Next time some idiot will want to embed chromium... I can imagine std::browser
And I forgot the evergreen, UBso that optimizers can do bogus optimiziations that will only trigger in some artificial nonsense cases that you'll never benefit from in real world code (but you'll benefit from long debug sessions and headaches if you're not careful
Anyway - until Blow finishes Jai, I'll stick with C/C++
Think of all the time wasted learning that encyclopedic pile crap. In the same amount of time, imagine what you could have done with a simple and pragmatic language like golang…
I wonder how big the next C++ encyclopedia will be. C++2017 standard is already well above 2000 pages, right?