Oh, wow. The language was complex already and this makes me avoid C++ unless it's constrained to a narrow subset (something like Google C++ Style Guide). No wonder languages like Go and Rust gain so much traction.
I find comments of this type bizarre. C++20 is trying to make the language -less- complex by deprecating the aspects of it that make things gross. Yes, for it to still be C++, you have to "add" the modules feature to the compiler, but the whole point of adding them is so that you -don't- have to think about include's. All of the disgusting complexity that results from doing literal textual inclusion goes away if we all use modules. Instead of having mandatory ifdef's in every header, repeated compilation of the same code, humongous compilation units, separation of implementation and interface (except for templates!)(and inlines!), you get... the interface we know we want.
If you have arguments with the implementation that's one thing, but what would you prefer? That the language just stay still, warts and all? Ok... well then just keep using C++03. But you probably don't want to do that, because '03 sucks, right? Ok, and what would make it better? ----> All the things they're trying to fix via C'11 through C'20...
Well, hopefully NOT like the Google Style Guide, which is pretty universally seen in the C++ community as A Bad Thing, unless you work for Google.
And as I pointed out in another comment, these additions are mostly not aimed at C++ application developers. If you don't need them (and you probably won't) then don't use them.
And as I pointed out in another comment, these additions are mostly not aimed at C++ application developers.
That's often been true in other recent C++ standards, but looking at the linked page about C++20 in particular, quite a lot of those points might reasonably appear in application code.
If you don't need them (and you probably won't) then don't use them.
The trouble with this argument has always been that if your language provides a certain feature or syntax, even if you don't use it, there is no guarantee that everyone else whose code you depend on won't use it either.
Some language features are inherently contagious. If you are calling code that uses exceptions or const qualifiers or asynchronicity, you probably need to take that into account in your own code. I recognise that these aren't particularly esoteric as language features go, but I've still seen plenty of teams over the years that attempted to avoid using them in C++ based on some argument about making things too complicated, mostly with results that weren't great.
Even for new language features that are expected to be used mostly within libraries and not to be seen much in application code, you might still have to dig into the source code for a library to trace a bug or performance problem, which means in practice you still need enough awareness of the full language to do that.
Extra complexity in the design of a programming language always comes at a cost, whether or not you intend to use it. The important question is usually whether the price is worth paying.
> I've still seen plenty of teams over the years that attempted to avoid using them in C++ based on some argument about making things too complicated
Of course - the Google Style Guide being a prime example.
> you might still have to dig into the source code for a library to trace a bug or performance problem
I've been programming in C++ since the 1980s and I've never even tried to debug someone else's library - life's too short, and it's not what I'm getting paid for. Have you looked at the source for (say) your Standard Library implementation? If you are not intimately familiar with it (which kind of negates the advantages of using a library in the first place) you won't stand a chance of debugging it, no matter how deep your knowledge of the C++ Standard.
One recent thing I caught from going over the implementation was how MSVC's implementation of std::tuple is semantically different from GCC's, where GCC constructs left to right, but MSVC constructs from right to left.
I also debug through boost and have reported bugs, or just found bugs in it that had already been reported.
Qt is another library that I am constantly reading over, heck if anything just for the sake of learning interesting UI implementation techniques.
Anecdotally, I find it unfortunate that people who talk about how they've been programming in C++ for 30+ years are almost always the ones who have very backwards and archaic practices and talk about those practices like they are common place.
"I've been programming in C++ for 500 years and never once have I had to do this, therefore it follows that no other C++ developer will ever have to do it either!"
There are entire generations of developers who've learned C++ and use it in ways very different from you, in technical domains you may not even realize exist. Don't presume that just because you personally have never done something, that it can't possibly be relevant or useful to an entire community of developers using the same technologies as you but in different ways.
I'm saying that on principle I do not debug other people's libraries (I do, of course, debug my own). I also do use many modern C++ features, (C++11 and later) particularly from the Standard Library, and I think that more developers should do so.
Fair enough, that's a principle you can have for yourself and depending on your role and responsibilities that may suit you. But at least be aware that others may have a different principle and set of responsibilities. I have a professional responsibility to take all measures I can to deliver the most reliable software to my customers and if that means debugging third party libraries, so be it. Heck if that means debugging the toolchain, the operating system, whatever the case, then it's my job to do it.
I don't have the luxury of having the software I deliver to end users fail and then saying "Oh well, it's because there's a bug in a third party library and as a matter of principle I don't bother debugging it, reporting it, or taking basic measures to deal with it so you poor customers will just have to deal with it."
a) "I spent the week chasing down an apparent bug on one of the Standard Libraries we use."
or:
b) "I implemented connectivity with the Hong Kong stock exchange, improved our MT performance to get a 20% improvement on submitting trades, and identified a bug we were having with currency conversions as possibly being in one of the libraries we use, wrote a work-around for it, wrote the fix and tests up on our developer wikki, and submitted a report to the library vendor."
Now, I would say that(b) is of far more value for the company I work for and is at least as "professional" as (a).
Several times in my life I've been in situations where a) was more important because the bug was causing real issues now. In your industry a bug that miscalculates risk can cost billions of dollars. In my industry a bug can cause a safety system to fail and kill people.
It looks like we're in similar industries then based on your comment and if that's more or less the level you've been operating at on a weekly basis for decades then without a doubt you are a significantly more productive individual than I am and really kudos to you for it.
My point is mostly that not everyone is you though, similarly I don't presume everyone works like I do. Hence arguing that because you've done something for 30 years that it reasonably follows that everyone else should also do it is a really poor argument.
Now, I would say that(b) is of far more value for the company I work for and is at least as "professional" as (a).
That's fine, but it does assume that a workaround exists and can be implemented within a reasonable amount of time. If you're talking about a bug in a library of convenient text processing utilities, that might well be the case. If you're talking about a bug in a security-related library that you rely on to authenticate instructions to make high-value trades, maybe not so much.
Fair enough, that's a principle you can have for yourself and depending on your role and responsibilities that may suit you. But at least be aware that others may have a different principle and set of responsibilities.
I can't upvote this sentiment enough. C++ has been used by millions of programmers working in numerous fields over a period of decades. Any attempt to generalise from a single person's own experience of using C++ to that entire community is surely unwise. I note (for no particular reason, honest) that this applies even if you are a long-standing member of the standards committee.
I've never even tried to debug someone else's library - life's too short, and it's not what I'm getting paid for.
What is your general strategy to deal with bugs in other code? Sometimes just stepping through other code and fixing something small there is by far the fastest way to get things done. Not life-shortening at all :) I.e. way faster than alternatives like submitting a bug report and hoping it gets fixed, or hacking around the bug, or looking for another library. I do not understand why you'd abandon the idea out of principle. Perhaps you had some really bad experiences with it when you just started or so?
Have you looked at the source for (say) your Standard Library implementation?
Very often. Usually not to 'debug it' in the sense of finding bugs but to figure out in detail why my code invokes UB or asserts or whatever somewhere else. Or in case of documentation not being clear to find out what really happens. Also a good way to learn by seeing how others write code.
Of course - the Google Style Guide being a prime example.
Indeed, though it's been going on since long before Google was around!
Have you looked at the source for (say) your Standard Library implementation? If you are not intimately familiar with it (which kind of negates the advantages of using a library in the first place) you won't stand a chance of debugging it, no matter how deep your knowledge of the C++ Standard.
Some years ago, I did exactly that. Found a bug in it, too.
Part of my concern with the ever-increasing complexity of C++ since C++11 is that what I did back then would be increasingly difficult today, because there are so many intricacies aimed at library writers squeezing out every last drop of performance. Of course, for a systems programming language like C++, that emphasis is understandable. But as I said, extra complexity in language design always comes at a cost. And if we'd had to wait for someone upstream to fix the bug in the library I mentioned above, that cost would have had quite a lot of digits in it and a dollar sign at the front.
Many of the new features will help with readability. Conditionally explicit is a good example. There are a ton of places in the standard library where conditionally explicit constructors are needed, and the workaround isn't too nice, it's a ton of boilerplate.
Concepts will also help for the same reason. SFINAE is used a lot in libraries and it's simply not readable. Concepts will make it more approachable.
Many of the new features will help with readability.
Indeed, and this has been the argument for many of the new developments right back to C++11. There is something of a devil-you-know argument here as well, though.
SFINAE is a surprisingly useful consequence of the way overload resolution is specified, but as you say, it's been used a lot. Many C++ programmers have encountered it over the years. Much has been written about it to explain it for those encountering it for the first time.
Realistically, C++ programmers will still have to understand the resolution rules even after C++20 becomes widely adopted. Those rules are also relevant for other reasons, and even in the specific case of SFINAE, the entire ecosystem isn't going to rewrite all its code to use newer alternatives overnight.
So now, any new C++ programmer who wants to analyse a third party library to trace the source of a bug is going to need to recognise multiple techniques to achieve that kind of behaviour and not just the strange but at least ubiquitous way we had before.
Only somewhat. As new features become more common the old ones that were harder to use become less important. C++11 has made a big impact on the type of C++ you see in the real world, now that it is 9 years old we can see change. The change wasn't overnight, but it is there.
It's the style guide for Google's specific environment. If you are not Google, much of it is likely irrelevant.
For example, the style guide says that C++ exceptions are the way to go...except that by the time the guide was written there was already too much existing code that wasn't exception safe. Therefore the guide says that regretfully, exceptions cannot be used.
And this is why the guide is "bad" - you simply can't avoid dealing with exceptions in C++ code, unless you also forgo the Standard Library, use weird and unreliable methods to detect constructor failures, and a bevy of other problems.
And I disagreed. Application developers need to break their code up, Modules aid that. Applications generally have a few custom templates for something and so concepts will be useful. <=> is useful for a lot of classes.
As I said: "mostly not aimed at C++ application developers" - note the word "mostly". Of course, some features are usable and useful to application developers.
The only thing here where I think "wow, that's a lot" is the whole `module` thing (and even that, I'm sure I could love, it's just alien to me for now, and I doubt it'll gain much traction for quite a while). Everything else seems like a very C++ thing, or an improvement.
No one ever forces you to use extra features. But if you can improve/reduce your code, why not?
