4 ms·

Well put! Much of the C++ code out there is still C++98 and a lot of the "so called problems" had already been solved by using established code patterns (not G

Well put! Much of the C++ code out there is still C++98 and a lot of the "so called problems" had already been solved by using established code patterns (not GoF). "Modern C++" has added a lot of complexity but not for much benefit; its fanboys always use hand-wavy phrases like "much nicer", "makes programming simple"(!) etc. which mean nothing. After the introduction of STL and explosion in the usage of "Generic Programming" the only thing the language needed was Concurrency support for Synchronous/Asynchronous programming. Instead the ISO committee went off the rails into "modernizing" the language to try to make it like Python/whatever. The result is that experienced C++ developers are very cautious about adopting "Modern C++" while the larger "know little/nothing" crowd are raucously running around making all sorts of unwarranted claims. IMO, today the greatest enemy of the language is the ISO committee itself.

wiseowise 4y ago
You say a lot of words, but have substance. Which “so called problems”? Which “established code patterns?”. Why “it means nothing” and to whom? I can continue.
- rramadass 4y ago
  This is the old trope of asking for proof from one side in a forum where things are discussed freely. I could turn it around and ask you to justify all the new "features" added to say C++11..20. I am here for the rest of time. But to give a few concrete examples; >Which “so called problems”? Apparently "variants" were introduced to solve problems with POD "unions". Mere complexity for not much benefit. Nobody i have worked with ever said "unions" were difficult to use. >Which “established code patterns?” RAII as a solution to People harping about memory problems. I have written entire protocol message libraries just using RAII to avoid memory leaks. >Why “it means nothing” and to whom? When "Modern C++" proponents say everything should be written with the new features using hand-wavy phrases, "it means nothing" to experienced programmers. If we find a feature useful to model a concept and/or express something we will use it; but always weighed against how complex it is to read and maintain. A good example is template meta-programming taken too far. The key reason C++ took off was because it added minimal "Zero-Overhead abstraction" constructs over the baseline "low-level and simple" C core. Suddenly programmers could have their cake and eat it too. The evolution of C++ should have continued in the same spirit but instead in a misguided effort to compete with later and differently designed languages a lot of complexity has been added for not much apparent benefit.
  - jcelerier 4y ago
    > Nobody i have worked with ever said "unions" were difficult to use. I wouldn't trust anyone to write the correct boilerplate for union { std::string s; int v; }; unless they'd do just this all day long
    - rramadass 4y ago
      std::string is not a POD.
      - jcelerier 4y ago
        ... yes? One still needs to put it in sum types sometimes. This is what std::variant solves.
        rramadass 4y ago
        But that is the point; "union" is supposed to be a POD, if not all language guarantees are off.
        jcelerier 4y ago
        > But that is the point; "union" is supposed to be a POD no it's not. it's fine to have non-POD unions - but you have to be careful to call constructors and destructs of non-POD's explicitly. thus, variant which automates that. Also, I didn't talk specifically about unions, but about sum types. There is a need for saying that an object X can be of type A OR type B, no matter the properties of these types.
        rramadass 4y ago
        >it's fine to have non-POD unions Only from C++11 (or is it later?). So a problem was created by relaxing the existing requirements for a "union" to which a solution was proposed by adding a "variant"? Something which had no runtime overhead (but UB) now has runtime overheads. Regarding your point about "sum types", agreed.
germandiago 4y ago
I am not sure you have used C++ that much. Claiming that move semantics, structured bindings, lambdas, designated initializers, non-impliciy self, override for virtual functions marker, [[nodiscard]], coroutines, modules, smart pointers, safer bitcasting, non-ambiguous bytes (std::byte), scoped enums, delegated and inherited constructors, constexpr, consteval and much, much more are not improvements for day-to-day... well, shows me that you must have not used it that much.
- rramadass 4y ago
  Nice list ... but that doesn't mean you understand what you have listed. Your list reads like what a noob "Modern C++" programmer would focus on (keywords and features to get through an interview) rather than any long-term (i have been programming in C++ since early nineties) real work experience. Lots of good C++ based systems have been written before any of the above existed. That proves that they are not "needs" but merely "wants". Only some in the above list are worth adding to the language while others are just noise (as an example keywords like "override"/"default"/"nodiscard" just add to syntactic noise rather than any actual benefit). The members of the ISO C++ committee simply pushed through their pet "wants" for brownie points.
  - jcelerier 4y ago
    When override was introduced it immediately solved a few hidden bugs here so it definitely has value. I'd say that when doing development with inheritance it catches at least a bug or two a month at compile-time. Same for nodiscard, I started using it recently and immediately found bugs. So for me their value is infinite
    - rramadass 4y ago
      As a counter anecdote i have not found any uses for the above and yet my code is running perfectly fine. That just reinforces my point that they are "wants" and not "needs".
      - 4y ago
int_19h 4y ago
> "modernizing" the language to try to make it like Python/whatever. I've been writing C++ code professionally for almost 20 years now, and Python for 10 years. I tried to think of any C++ features post C++98 that would make it "like Python", but I can't think of any. Can you give some specific examples?
- rramadass 4y ago
  We will not go down this path since everything is highly debatable but here is an article: https://preshing.com/20141202/cpp-has-become-more-pythonic/ https://preshing.com/20141202/cpp-has-become-more-pythonic/ It even states: C++ added tuples to the standard library in C++11. The proposal even mentions Python as an inspiration.

wiseowise 4y ago

You say a lot of words, but have substance. Which “so called problems”? Which “established code patterns?”. Why “it means nothing” and to whom? I can continue.

rramadass 4y ago
This is the old trope of asking for proof from one side in a forum where things are discussed freely. I could turn it around and ask you to justify all the new "features" added to say C++11..20. I am here for the rest of time. But to give a few concrete examples; >Which “so called problems”? Apparently "variants" were introduced to solve problems with POD "unions". Mere complexity for not much benefit. Nobody i have worked with ever said "unions" were difficult to use. >Which “established code patterns?” RAII as a solution to People harping about memory problems. I have written entire protocol message libraries just using RAII to avoid memory leaks. >Why “it means nothing” and to whom? When "Modern C++" proponents say everything should be written with the new features using hand-wavy phrases, "it means nothing" to experienced programmers. If we find a feature useful to model a concept and/or express something we will use it; but always weighed against how complex it is to read and maintain. A good example is template meta-programming taken too far. The key reason C++ took off was because it added minimal "Zero-Overhead abstraction" constructs over the baseline "low-level and simple" C core. Suddenly programmers could have their cake and eat it too. The evolution of C++ should have continued in the same spirit but instead in a misguided effort to compete with later and differently designed languages a lot of complexity has been added for not much apparent benefit.
- jcelerier 4y ago
  > Nobody i have worked with ever said "unions" were difficult to use. I wouldn't trust anyone to write the correct boilerplate for union { std::string s; int v; }; unless they'd do just this all day long
  - rramadass 4y ago
    std::string is not a POD.
    - jcelerier 4y ago
      ... yes? One still needs to put it in sum types sometimes. This is what std::variant solves.
      - rramadass 4y ago
        But that is the point; "union" is supposed to be a POD, if not all language guarantees are off.
        jcelerier 4y ago
        > But that is the point; "union" is supposed to be a POD no it's not. it's fine to have non-POD unions - but you have to be careful to call constructors and destructs of non-POD's explicitly. thus, variant which automates that. Also, I didn't talk specifically about unions, but about sum types. There is a need for saying that an object X can be of type A OR type B, no matter the properties of these types.
        rramadass 4y ago
        >it's fine to have non-POD unions Only from C++11 (or is it later?). So a problem was created by relaxing the existing requirements for a "union" to which a solution was proposed by adding a "variant"? Something which had no runtime overhead (but UB) now has runtime overheads. Regarding your point about "sum types", agreed.

germandiago 4y ago

I am not sure you have used C++ that much. Claiming that move semantics, structured bindings, lambdas, designated initializers, non-impliciy self, override for virtual functions marker, [[nodiscard]], coroutines, modules, smart pointers, safer bitcasting, non-ambiguous bytes (std::byte), scoped enums, delegated and inherited constructors, constexpr, consteval and much, much more are not improvements for day-to-day... well, shows me that you must have not used it that much.

rramadass 4y ago
Nice list ... but that doesn't mean you understand what you have listed. Your list reads like what a noob "Modern C++" programmer would focus on (keywords and features to get through an interview) rather than any long-term (i have been programming in C++ since early nineties) real work experience. Lots of good C++ based systems have been written before any of the above existed. That proves that they are not "needs" but merely "wants". Only some in the above list are worth adding to the language while others are just noise (as an example keywords like "override"/"default"/"nodiscard" just add to syntactic noise rather than any actual benefit). The members of the ISO C++ committee simply pushed through their pet "wants" for brownie points.
- jcelerier 4y ago
  When override was introduced it immediately solved a few hidden bugs here so it definitely has value. I'd say that when doing development with inheritance it catches at least a bug or two a month at compile-time. Same for nodiscard, I started using it recently and immediately found bugs. So for me their value is infinite
  - rramadass 4y ago
    As a counter anecdote i have not found any uses for the above and yet my code is running perfectly fine. That just reinforces my point that they are "wants" and not "needs".
    - 4y ago

int_19h 4y ago

> "modernizing" the language to try to make it like Python/whatever. I've been writing C++ code professionally for almost 20 years now, and Python for 10 years. I tried to think of any C++ features post C++98 that would make it "like Python", but I can't think of any. Can you give some specific examples?

rramadass 4y ago
We will not go down this path since everything is highly debatable but here is an article: https://preshing.com/20141202/cpp-has-become-more-pythonic/ https://preshing.com/20141202/cpp-has-become-more-pythonic/ It even states: C++ added tuples to the standard library in C++11. The proposal even mentions Python as an inspiration.