The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
There are a number of bits related to determining types of things and type traits and such that are now tied to the standard libraries, i.e. they are in library headers, not intrinsic parts of the language. But they are required to do various fancy template'ish type things. So you can't do those unless you include the standard library stuff.
Actually, it's more advanced static type info, for doing template stuff at compile time really. Basically to let you do a certain amount of logic at compile time to select this or that bit of template code, set that size value, etc...
hmm, well that's neat, actually. the only question is do you have to use the libraries or are they only invoked if you use that language feature? (you don't have to answer) - if it's not, then i am hesitantly okay with it.
The rationale being that the more you can get a C++ compiler to do for you, the better.
I love that it can solve equations for you and the like, but more importantly, it's critical for offloading absolutely as much as possible to the compiler.
a little bit of special knowledge of the standard libraries is about as much of a hack as parsing C languages is in general, see for example, the "type problem" requires a backchannel from the syntax analyzer back into the lexer, and these are as old as C itself.
if it's targeted and optional to use, and helps the compiler do more at compile time, I'd side-eye it, but i think the pros can outweigh the cons. I'm guessing the standards committee came to more or less the same rationale.
Here's a different take on this problem -- the IDE vendors have run out of real additions to the languages so they are pushing their people to create snazzy new but ultimately unnecessary "features" to sell the next version of the IDE. That explains languages like C# -- every time I see a list of new "features" I find a small percentage that is actually useful.
Open source has a different part of that same problem -- they need to be seem as making progress. If they are not adding features, the language is seen as stagnant and falling behind, which results in a software version of "keeping up with the Jones". Like IDE vendors, they have run out of real things to add, so they add "features" that impress the vocal fanbois.
I just searched for "C# new features" and looked at a few "top 10" features in C 7#. The lists were virtually identical and each contained 2 things of real use, 2 things of interest, and 6 that made me scratch my head.
C++ has this problem, and it isn't even a product from some corporation. I like many of the new features of C++, but some leave me shaking my head (any, variant, lambdas). They seem to be solutions looking for a problem. And what else they do is shake my mastery of the language, so I don't know any longer if there is a better way.
I think each new generation of PhDs and young professors wants to make a mark on C++ by copying bits from some research language into C++ so it feels more "advanced". That's great for the people who learn C++ with these tools already baked in, but kinda sucks for more experienced developers who already know C++.
I'd like to see the tempo of new features reduced. Maybe a new standard every 5 years is enough?
I think part of it C++'s problem is that it is in danger of entering a death spiral, and maybe a lot of folks think that if it doesn't appear to be moving forward quickly to become 'more modern' that it will just get worse.
Ultimately, I think that may be counter-productive, because it's now so complicated that it probably puts off a lot of new developers looking at it.
Lambdas I get. They can obviously be abused, but they have the one massive advantage in that they can be capturing. So it allows for a range of things that couldn't otherwise easily be done in the way of callbacks.
The downside is that, capturing lambdas cannot be passed to a function pointer parameter. So you can't strictly define the parameter if you want to pass capturing lambdas, you have to use a generic templatized parameter. So you can only use them with other templatized code which is sub-optimal, and you get immediately into 'million errors that mean nothing' land any time you make a mistake, because the compiler has no idea what you really are trying to do.
People have predicted the imminent death of C++ since 2003 or so. Instead of dying, it just gets more users, and remains near the top of the TIOBE index.
The people who think about C++ have observed since 2011 that it is becoming two languages: one very sophisticated language for creators of template libraries, and another language for ordinary users. I'm not sure this is a healthy evolution.
Some day, Rust may overtake C++, but I don't see any other contender today.
There's dying and there's dying. Looking through the job listings out there, C++ seems to me to be suffering, mainly because it's not well suited for the projects that are getting lots of investment. Often C++ seems to be often only even in a listing because it's in the 'experience in one or more of these languages' list, but it's probably not the one you are going to be using, it's just that at least you would have OO development experience if you know it.
I mean I think that the browser and the phone have been amongst the worst things to happen to programming in a long time (let's throw out all of the work done over decades and go back through the exact same ridiculously long and painful process again but even worse), but the fact is that so many development jobs are there. Or maybe they are on the back-end but they related to how can we collect as much data on people as possible and apply AI to exploit that data as much as possible and that's usually not C++ related either. It's more likely to be SQL or Hadoop or Azure experience or some such.
Don't get me wrong. I have a HUGE investment in C++ and it would be to my benefit if it were doing better. But I just really get the impression that it's on a precipice.
I think you are exactly correct. C++ is not the go-to language for writing web pages, web servers, or phone apps. Apple had an investment in Object Pascal, and then Swift, to create a typical Apple lock-in. Google chose Java for Android, probably to take advantage of the many programmers who knew Java and the Spring graphics library, but found C++ difficult.
C++ is always going to be the language for implementing embedded things, for writing operating systems, compilers and databases, and for any place performance is critical.
And of course Microsoft only supports C++ out of obligation and for reputation at this point I think. Most Windows work is C# these days. So, if you backed the Windows/C++ horse, and a lot of people did, it was sort of the worst case scenario. Much of the C++ work that is available is on Linux/Unix.
I think you're right about many general purpose languages out there. I've felt a lot of fatigue with C#/ESNext/TypeScript.
On the flip side, the tempered, thoughtful, and consistent design is something I didn't expect to appreciate when I first discovered Elm. The language and ecosystem becomes simpler and more reliable with new releases. It's a breath of fresh air.