6 ms·

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 won

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.

zabzonk 5y ago
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.
- vamega 5y ago
  Do you have any pointers to information as to why it’s considered the Google style guide is considered to be a bad thing?
  - pjmlp 5y ago
    Many of the rules that are considered best practices in Tour of C++ or C++ Core Guidelines are no go for Google.
  - zabzonk 5y ago
    https://news.ycombinator.com/item?id=18555771 https://news.ycombinator.com/item?id=18555771
  - gumby 5y ago
    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. Edit: clarification
    - zabzonk 5y ago
      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.
- Silhouette 5y ago
  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.
  - zabzonk 5y ago
    > 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.
    - Silhouette 5y ago
- bluGill 5y ago
  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.
  - zabzonk 5y ago
    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.
0xTJ 5y ago
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?
sebastos 5y ago
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...

zabzonk 5y ago

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.

vamega 5y ago
Do you have any pointers to information as to why it’s considered the Google style guide is considered to be a bad thing?
- pjmlp 5y ago
  Many of the rules that are considered best practices in Tour of C++ or C++ Core Guidelines are no go for Google.
- zabzonk 5y ago
  https://news.ycombinator.com/item?id=18555771 https://news.ycombinator.com/item?id=18555771
- gumby 5y ago
  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. Edit: clarification
  - zabzonk 5y ago
    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.
Silhouette 5y ago
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.
- zabzonk 5y ago
  > 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.
  - Silhouette 5y ago
bluGill 5y ago
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.
- zabzonk 5y ago
  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.

0xTJ 5y ago

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?

sebastos 5y ago

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...