6 ms·

The most exciting news about C++ would not be added features, but removed features. That is what everyone in their heart is waiting for.

jeffreyrogers 4y ago
I'm glad C++ has added more features, it is a much nicer language than it used to be. string_view from C++17 is very convenient and just this past week I had to use std::latch from C++20.
- witx 4y ago
  Yes, but the problem in my view is that for each of those small things we find useful they introduce tons of other features no one needs ...
  - jcelerier 4y ago
    Can you list some that are present in c++20?
  - usefulcat 4y ago
    s/no one/I/
usefulcat 4y ago
The only problem being that “everyone” can’t agree on which particular set of features should be removed. Breaking existing code is always going to be a tough sell, for hopefully obvious reasons.
- Brybry 4y ago
  Would code need to be broken? I thought it was normal to deprecate features and then have the compiler throw a warning.
  - Jare 4y ago
    "Treat warnings as errors" is a standard best practice.
    - Gibbon1 4y ago
      Treat warnings as errors is terrible practice.
      - still_grokking 4y ago
        It's the only sane thing to do. And everybody who doesn't do so really deserves the pain that results later on.
        rightbyte 4y ago
        What is the point of having warnings then.
        still_grokking 4y ago
        You can suppress them in the rare cases this is needed. Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched. Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore. But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
        Gibbon1 4y ago
        Yeah at best you can force can force people unfamiliar with the code to waste their time suppressing a dumb ass warning that means nothing. Or worse accidentally introduce a bug.
        Gibbon1 4y ago
        No it's completely insane because you never know what a different or future compiler is going to decide to bitch about.
FpUser 4y ago
>"That is what everyone in their heart is waiting for." Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.
- nine_k 4y ago
  Operator delete still exists. Dereferencing void * still exists. Access like a[i] is still unchecked. Etc. But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
  - jcelerier 4y ago
    > Dereferencing void * still exists. ... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o https://gcc.godbolt.org/z/hK6qb1z6o
pjmlp 4y ago
Even Go gets to add features.
omoikane 4y ago
One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to. I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.
- 29athrowaway 4y ago
  They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help. If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more. C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. If you are using ancient C++, compiler security updates are the least of your security concerns. If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
  - int_19h 4y ago
    > C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
    - still_grokking 4y ago
      > I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP. Sounds like pure joy.
      - int_19h 4y ago
jcelerier 4y ago
no, i really want reflection and better code generation features for instance ; this would allow me to simplify and remove a lot of useless code. likewise, "deducing this" which made it into C++23 is likely going to allow me to remove at least a few hundred and hopefully a few thousand lines of the codebase I'm working on. And all this means less chances for bugs and more time actually writing features.
- still_grokking 4y ago
  > i really want reflection and better code generation features for instance I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3: https://docs.scala-lang.org/scala3/reference/metaprogramming/index.html https://docs.scala-lang.org/scala3/reference/metaprogramming... With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
  - jcelerier 4y ago
    Most of what you sent under this link falls under the general idea of reflection, e.g. the quoted macros, and is fairly similar to the kind of things that are being proposed for c++. Of course all the reflection systems proposed for c++ are purely compile-time, no one even proposed runtime reflection I think
    - still_grokking 4y ago
      For most people "reflection" is a synonym to "runtime reflection". In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹. Where can I learn more about the C++ proposals to compare? --- ¹ https://dl.acm.org/doi/10.1145/3136000.3136005 https://dl.acm.org/doi/10.1145/3136000.3136005 ¹ https://dl.acm.org/doi/10.1145/3158101 https://dl.acm.org/doi/10.1145/3158101 And the recent work that underlines the solution included in Scala 3: ¹ https://se.informatik.uni-tuebingen.de/publications/stucki21multistage.pdf https://se.informatik.uni-tuebingen.de/publications/stucki21...

jeffreyrogers 4y ago

I'm glad C++ has added more features, it is a much nicer language than it used to be. string_view from C++17 is very convenient and just this past week I had to use std::latch from C++20.

witx 4y ago
Yes, but the problem in my view is that for each of those small things we find useful they introduce tons of other features no one needs ...
- jcelerier 4y ago
  Can you list some that are present in c++20?
- usefulcat 4y ago
  s/no one/I/

usefulcat 4y ago

The only problem being that “everyone” can’t agree on which particular set of features should be removed. Breaking existing code is always going to be a tough sell, for hopefully obvious reasons.

Brybry 4y ago
Would code need to be broken? I thought it was normal to deprecate features and then have the compiler throw a warning.
- Jare 4y ago
  "Treat warnings as errors" is a standard best practice.
  - Gibbon1 4y ago
    Treat warnings as errors is terrible practice.
    - still_grokking 4y ago
      It's the only sane thing to do. And everybody who doesn't do so really deserves the pain that results later on.
      - rightbyte 4y ago
        What is the point of having warnings then.
        still_grokking 4y ago
        You can suppress them in the rare cases this is needed. Such suppression are than big warning signs in the code telling you that something exceptional is going on which needs extra attention when touched. Also warnings may be wrong. Errors mustn't be and can't be as strict as warnings therefore. But it shouldn't be possible to "just ignore them". If you do, this needs to be done deliberately and explicitly.
        Gibbon1 4y ago
        Yeah at best you can force can force people unfamiliar with the code to waste their time suppressing a dumb ass warning that means nothing. Or worse accidentally introduce a bug.
      - Gibbon1 4y ago
        No it's completely insane because you never know what a different or future compiler is going to decide to bitch about.

FpUser 4y ago

>"That is what everyone in their heart is waiting for." Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.

nine_k 4y ago
Operator delete still exists. Dereferencing void * still exists. Access like a[i] is still unchecked. Etc. But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)
- jcelerier 4y ago
  > Dereferencing void * still exists. ... huh? i'm fairly confident dereferencing void is not valid C++ ; at the very least gcc/clang/msvc do not compile it: https://gcc.godbolt.org/z/hK6qb1z6o https://gcc.godbolt.org/z/hK6qb1z6o

pjmlp 4y ago

Even Go gets to add features.

omoikane 4y ago

One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to. I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.

29athrowaway 4y ago
They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help. If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more. C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. If you are using ancient C++, compiler security updates are the least of your security concerns. If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.
- int_19h 4y ago
  > C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will. That doesn't make it a dead codebase. New code still gets written - and it helps when it can be written using newer, better techniques while working nicely with old code. I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP.
  - still_grokking 4y ago
    > I once worked on a codebase that had ancient code from mid-90s with explicit COM AddRef/Release side by side with C++11 lambdas and TMP. Sounds like pure joy.
    - int_19h 4y ago

jcelerier 4y ago

no, i really want reflection and better code generation features for instance ; this would allow me to simplify and remove a lot of useless code. likewise, "deducing this" which made it into C++23 is likely going to allow me to remove at least a few hundred and hopefully a few thousand lines of the codebase I'm working on. And all this means less chances for bugs and more time actually writing features.

still_grokking 4y ago
> i really want reflection and better code generation features for instance I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3: https://docs.scala-lang.org/scala3/reference/metaprogramming/index.html https://docs.scala-lang.org/scala3/reference/metaprogramming... With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).
- jcelerier 4y ago
  Most of what you sent under this link falls under the general idea of reflection, e.g. the quoted macros, and is fairly similar to the kind of things that are being proposed for c++. Of course all the reflection systems proposed for c++ are purely compile-time, no one even proposed runtime reflection I think
  - still_grokking 4y ago
    For most people "reflection" is a synonym to "runtime reflection". In contrast quotes and splices aren't reflection at all! The whole point about them is that they're "black box". You (usually) can't "extract information" form a quote in a safe way (so it's the exact contrary to reflection). That's still something academia is trying to solve (even there are some proposals out)¹. Where can I learn more about the C++ proposals to compare? --- ¹ https://dl.acm.org/doi/10.1145/3136000.3136005 https://dl.acm.org/doi/10.1145/3136000.3136005 ¹ https://dl.acm.org/doi/10.1145/3158101 https://dl.acm.org/doi/10.1145/3158101 And the recent work that underlines the solution included in Scala 3: ¹ https://se.informatik.uni-tuebingen.de/publications/stucki21multistage.pdf https://se.informatik.uni-tuebingen.de/publications/stucki21...