4 ms·

It's good that C++ is evolving, but I'm not sure if it evolves in the right way. Basically, consider a ball of meat. The meat is rotting, nobody would eat it a

by kamac 11y ago

It's good that C++ is evolving, but I'm not sure if it evolves in the right way. Basically, consider a ball of meat. The meat is rotting, nobody would eat it anymore, so fresh meat is slapped on it. And the process repeats numerous times, for years. In the end, you'll have a giant ball of meat, that'll look fresh, but once you poke the ball, you'll be hit by the stench of the rotten meat inside. I'd prefer if they started anew, rather than keep slapping fresh meat on the ball.

flohofwoe 11y ago
This looks to me like making C++ more "rusty" which is a good thing IMHO, exactly for the reason that I don't need to bring all my existing code to a new language but instead can make it 'safe' in incremental steps. There are many good reasons to evolve a language instead of inventing a new one, the situation is a little bit like with OpenGL: 'modern OpenGL style' has nothing in common with the original OpenGL, and many ideas have been introduced in past versions which are now considered bad or dead. Still I can take the OpenGL Gears sample (which is who-knows how old) and run it on a modern GL driver. This is both a good and bad thing. The bad is that it is confusing to learn OpenGL if you haven't been following its entire history. Googling OpenGL questions will give you 10 different answers, all correct, but only for a specific time in its history. The good thing is that this approach allows me to bring a large piece of GL code incrementally to modern standards without having to rewrite everything. Of course there are the new fancy 3D APIs (just like there are fancier statically typed, compiled languages compared to C++), but in general, people are underestimating the risks of rewriting a large piece of code (this is still just as true as when it was written 15 years ago: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) What I would like to see in C++ is to have very detailed control over language features and enforce coding guidelines in my own code base. The more fine grained this control, the better. Something like 'don't allow pointer arithmetics', 'don't allow C arrays', 'don't allow multiple inheritance', etc... Going with your example: as soon as the rotten meat layer is reached, the compiler would no longer accept the code unless you specifically allow it with an exception to the 'modern rule-set'. A combination of such rules could result in a 'safe subset' which would have the same compile-times guarantees as Rust, and if the rules are violated, the compiler will complain (I think/hope this is what the presentation is mainly about).
- fauigerzigerk 11y ago
  >What I would like to see in C++ is to have very detailed control over language features and enforce coding guidelines in my own code base. Maybe something similar to JavaScript's "use strict" would be good, including the ability to restrict it to function/class/source file scope.
  - jzwinck 11y ago
    We already have that: `gcc -Wall -Wextra`, and a few more flags for specific things that some projects find too restrictive.
    - fauigerzigerk 11y ago
      Assuming "that" means "very detailed control over language features" I would say no, these flags don't provide that. Only very few flags warn or disable the use of entire language features. Most are warnings against dangerous ways of using some of the features.
      - toth 11y ago
        I believe gp meant Javascript's "use strict" equivalent in C++, which I would say is comparable to the compiler flags.
        fauigerzigerk 11y ago
        "use strict" isn't comparable to warning flags at all, because it changes the behavior of code. I only brought it up because it can be applied selectively within function scope, not specifically for what it does. I think what we need is a way to selectively disable language features. Changing the behavior of existing features is a much more questionable thing to do in my view. The big question is if it's possible to disable some features without affecting how other features must work. It failed miserably for exceptions, but exceptions are a cross cutting sort of concern.
- 11y ago
stinos 11y ago
once you poke the ball, you'll be hit by the stench of the rotten meat inside The whole point of this article seems to be to teach people to by default not poke the ball, unless really really needed, and in such caes do it while wearing a proper mask. Which is not ideal (that would indeed be to start over I guess), but given the current situation probably the best they can do.
- kamac 11y ago
  > The whole point of this article seems to be to teach people to by default not poke the ball And it's sad that they have to teach people not to poke the ball and reveal the inner decay, rather than remove the rotten meat itself.
  - greyman 11y ago
    It's not inner decay. It just more possibilities C++ allows you to do, which can give you more power if you know what you are doing.
  - kryptiskt 11y ago
    All serious languages have unsafe constructs that you can use as an escape hatch, even Haskell or Rust. Keeping the ability to do dangerous stuff in C++ isn't a compromise, it is vital. Building tools that makes it easier to separate the unsafe parts is a good thing, other languages got there first but having the possibility to clean up those billions of lines of C++ is great. Also, it's time to lay off your metaphor, it obscures the issues and trades just on disgust value.
rootlocus 11y ago
I love this metaphor. I've been trying to explain to people that the new c++ is just another layer of features on top of the old language. You can't learn c++ by just learning the last layer added. Modern C++ is just a subset of the language, and nothing prevents the old language from popping up everywhere.

by kamac 11y ago

flohofwoe 11y ago

This looks to me like making C++ more "rusty" which is a good thing IMHO, exactly for the reason that I don't need to bring all my existing code to a new language but instead can make it 'safe' in incremental steps. There are many good reasons to evolve a language instead of inventing a new one, the situation is a little bit like with OpenGL: 'modern OpenGL style' has nothing in common with the original OpenGL, and many ideas have been introduced in past versions which are now considered bad or dead. Still I can take the OpenGL Gears sample (which is who-knows how old) and run it on a modern GL driver. This is both a good and bad thing. The bad is that it is confusing to learn OpenGL if you haven't been following its entire history. Googling OpenGL questions will give you 10 different answers, all correct, but only for a specific time in its history. The good thing is that this approach allows me to bring a large piece of GL code incrementally to modern standards without having to rewrite everything. Of course there are the new fancy 3D APIs (just like there are fancier statically typed, compiled languages compared to C++), but in general, people are underestimating the risks of rewriting a large piece of code (this is still just as true as when it was written 15 years ago: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) What I would like to see in C++ is to have very detailed control over language features and enforce coding guidelines in my own code base. The more fine grained this control, the better. Something like 'don't allow pointer arithmetics', 'don't allow C arrays', 'don't allow multiple inheritance', etc... Going with your example: as soon as the rotten meat layer is reached, the compiler would no longer accept the code unless you specifically allow it with an exception to the 'modern rule-set'. A combination of such rules could result in a 'safe subset' which would have the same compile-times guarantees as Rust, and if the rules are violated, the compiler will complain (I think/hope this is what the presentation is mainly about).

fauigerzigerk 11y ago
>What I would like to see in C++ is to have very detailed control over language features and enforce coding guidelines in my own code base. Maybe something similar to JavaScript's "use strict" would be good, including the ability to restrict it to function/class/source file scope.
- jzwinck 11y ago
  We already have that: `gcc -Wall -Wextra`, and a few more flags for specific things that some projects find too restrictive.
  - fauigerzigerk 11y ago
    Assuming "that" means "very detailed control over language features" I would say no, these flags don't provide that. Only very few flags warn or disable the use of entire language features. Most are warnings against dangerous ways of using some of the features.
    - toth 11y ago
      I believe gp meant Javascript's "use strict" equivalent in C++, which I would say is comparable to the compiler flags.
      - fauigerzigerk 11y ago
        "use strict" isn't comparable to warning flags at all, because it changes the behavior of code. I only brought it up because it can be applied selectively within function scope, not specifically for what it does. I think what we need is a way to selectively disable language features. Changing the behavior of existing features is a much more questionable thing to do in my view. The big question is if it's possible to disable some features without affecting how other features must work. It failed miserably for exceptions, but exceptions are a cross cutting sort of concern.
11y ago

stinos 11y ago

once you poke the ball, you'll be hit by the stench of the rotten meat inside The whole point of this article seems to be to teach people to by default not poke the ball, unless really really needed, and in such caes do it while wearing a proper mask. Which is not ideal (that would indeed be to start over I guess), but given the current situation probably the best they can do.

kamac 11y ago
> The whole point of this article seems to be to teach people to by default not poke the ball And it's sad that they have to teach people not to poke the ball and reveal the inner decay, rather than remove the rotten meat itself.
- greyman 11y ago
  It's not inner decay. It just more possibilities C++ allows you to do, which can give you more power if you know what you are doing.
- kryptiskt 11y ago
  All serious languages have unsafe constructs that you can use as an escape hatch, even Haskell or Rust. Keeping the ability to do dangerous stuff in C++ isn't a compromise, it is vital. Building tools that makes it easier to separate the unsafe parts is a good thing, other languages got there first but having the possibility to clean up those billions of lines of C++ is great. Also, it's time to lay off your metaphor, it obscures the issues and trades just on disgust value.

rootlocus 11y ago

I love this metaphor. I've been trying to explain to people that the new c++ is just another layer of features on top of the old language. You can't learn c++ by just learning the last layer added. Modern C++ is just a subset of the language, and nothing prevents the old language from popping up everywhere.