5 ms·

Which C++? I know of classic C++ (98), then C++11 which I've used, but now there's C++14, C++17. C++20(?) which all seem to have very different features... I'm

Which C++? I know of classic C++ (98), then C++11 which I've used, but now there's C++14, C++17. C++20(?) which all seem to have very different features... I'm glad C++ is improving, but eh it's as tricky as HTML5/ES5 to keep up to date on.

RcouF1uZ4gsC 6y ago
This is where C++’s fanatical commitment to backwards compatibility really helps. You can bring your C++98 code and compile it with the latest compiler in C++20 mode and it should still work. This allows you to upgrade (and learn) incrementally. You can slowly incorporate new features into an old code base.
- Rochus 6y ago
  That's one of the best features of the language; I would rather call it "reasonable and conscientious" than "fanatical".
  - CyberDildonics 6y ago
    They meant fanatical in the sense that they are dedicated, not unreasonable.
- leetcrew 6y ago
  it's a double edged sword though. after a while, you end up with some parts of the code written in c++98 style, some that uses odd c++0x extensions, a bunch of c++11 style code, and then c++14/c++17 features sprinkled around in the newest code (or sometimes refactored into older paradigms). to be an effective developer for an older codebase, you need to understand a lot of history surrounding the feature sets to understand design decisions from the past.
  - jeffbee 6y ago
    It takes discipline and tooling to effectively eradicate older idioms from your code, but it is worth doing. Regarding tooling, check out ClangMR https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41342.pdf https://static.googleusercontent.com/media/research.google.c...
  - bluGill 6y ago
    What is your alternative? Do the great rewrite every few years to the latest fads? Some have done that successfully, but it is expensive to get right and many more have failed. In general, if it ain't broke don't break it is a great use of resources, which keeps your company in business (thus you making steady paycheck and going home to your family at night). Fix/update the parts that need updating because they change and let the working stuff keep working. I will give a nod to the other poster who pointed out automatic tools. They are often worth running on everything, but they only fix a fraction of the things that a sane developer with 20/20 hindsight starting over would do differently.
  - dragontamer 6y ago
    I mean, is it harder than writing code in C++98 style, then suddenly having to deal with C++ and Rust combinations from 2015 onwards? I'd say C++98 + C++17 is easier to deal with than C++98 + Rust.
- jacoblambda 6y ago
  This unfortunately isn't really quite entirely true any more. There are a number of depreciations in C++17 and up that prevent older C++ code from working out of the box. Keep in mind that these are largely relatively useless or now replaced features so any incompatibilities should be both few and far between and relatively easy to fix.
  - rfoo 6y ago
    And you can always compile your old codes with older C++ standards, codes compiled in C++11 / C++14 / C++17 are mostly ABI compatible so they can be (relatively safely) linked together.
- SomeoneFromCA 6y ago
  This enables easy porting of good old C code, to C++.
jdsully 6y ago
"I think that the new C++20 standard might be one of the main causes for this," TIOBE CEO Paul Jansen said in the latest report.
- jeffbee 6y ago
  C++20 wasn't even ratified until earlier this month. I seriously doubt that most industry programmers are using it, or even have access to C++20 toolchains. My new job is to port a company forward to C++11, FML.
  - SloopJon 6y ago
    Right, but TIOBE doesn't measure usage. It measures popularity by way of search engines. As people blog about their favorite new feature of C++20, it drives interest.
    - jeffbee 6y ago
      Actually I did not know that. I thought it was some kind of field survey. How did they do it in the 80s?
      - SloopJon 6y ago
        The FAQ says that their dataset only goes back until June of 2001, so I imagine the methodology for the prior years in the Very Long Term History section was somewhat different. The claim at the top of the page is that "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." However, the details show that it really is just a single search term across a variety of search engines. Maybe they used to have an intern read the classifieds at the back of the Communications of the ACM or something.
- disown 6y ago
  Perhaps it is because school is starting ( physically or online ) and many high schools/colleges teach C/C++? I wonder if there is a slight bump in C++ use every september?
pjmlp 6y ago
Just like anything else, does anyone understands every single feature available in Java 15, C# 9 or F# 5 or the respective runtimes, including the several implementations across multiple vendors?
vlovich123 6y ago
Which Rust? Which Swift? Which Python? Which Java? Which C#? All languages evolve & change, not just HMTL5/ES5. I worked at Apple when Swift was first rolled out & the language today is very different & unrecognizable to me from the one that exists today. The original code won't even compile today (not necessarily terrible if the automated conversion tools are 100% perfect). Java is on a ~1yr cadence for the past 3 years (used to be 2 before that except for Java 7, 8 & 9 which had a longer lead time & likely not coincidentally is the time period that saw tremendous growth in C#) Swift is on a ~1 yr cadence with major language changes still happening. Upgrades are managed by automatic tooling. Will be interesting to see if Apple can sustain this long-term (every problem gets magnified a lot with time if you're growing). Rust is on a ~~1 yr cadence although they've come up with an interesting way to land major language changes & improvements into the language (release process rather & I can't recall if they use automated tooling).~~* The problem of evolving languages isn't being ignored but it's a hard challenge. However, any language designer who ignores new up & coming concepts in language design is relegated to repeat the mistakes of C++ and Java which stagnated for long periods & let other languages capture large amounts of market share. Market share = how healthy the ecosystem for that language is & whether new projects get started in it. So if you just try to solve that problem first you'll end up never getting off the ground because you won't have an ecosystem around you to drive investment of time & money from users of that language. I think you're just seeing the reorientation to a faster release cadence in the industry. Rather than waiting many years to deliver on larger features (Python3, Perl5), there's a more regular process to continuously ship smaller subsets of them in a usable form to get feedback, amortize the cost of adoption, & address any issues sooner. This also makes you more competitive in terms of users adopting your language for new projects. This obviously does have an externality cost as there can be less QA & bake time for code. Those can be mitigated with automation. Design defects can be addressed sooner & those are valuable because they're the pain-points for your user base. I wish C++ actually delivered faster but given that there's 3 mainline compilers & a bunch of ancilliary ones, it's going to stagnate & die in favor of Swift or Rust which only have 1 shared reference compiler that everyone uses. It's also why projects like PyPy never grow beyond a small niche if you make that kind of choice. I'm on the side of Swift and Rust models - in C/C++ to support different platforms I need different compilers. This means in any non-trivial project I have to add different per-compiler workarounds to language interpretation or feature set (even clang's attempts to pretend to be GCC or MSVC don't work out well & you end up having to adjust your project to actually be aware of it). * EDIT: Corrected below. Rust is on a 6-week cadence with a 3-year roll-up of the supporting material & an interesting way to support mixing and matching code from different versions.
coliveira 6y ago
Unlike other languages du jour, C++ keeps backward compatibility, so it really doesn't matter. You just need the latest compiler to have access to all these "flavors" of C++.
- saagarjha 6y ago
  It matters if you’re working with it…

RcouF1uZ4gsC 6y ago

This is where C++’s fanatical commitment to backwards compatibility really helps. You can bring your C++98 code and compile it with the latest compiler in C++20 mode and it should still work. This allows you to upgrade (and learn) incrementally. You can slowly incorporate new features into an old code base.

Rochus 6y ago
That's one of the best features of the language; I would rather call it "reasonable and conscientious" than "fanatical".
- CyberDildonics 6y ago
  They meant fanatical in the sense that they are dedicated, not unreasonable.
leetcrew 6y ago
it's a double edged sword though. after a while, you end up with some parts of the code written in c++98 style, some that uses odd c++0x extensions, a bunch of c++11 style code, and then c++14/c++17 features sprinkled around in the newest code (or sometimes refactored into older paradigms). to be an effective developer for an older codebase, you need to understand a lot of history surrounding the feature sets to understand design decisions from the past.
- jeffbee 6y ago
  It takes discipline and tooling to effectively eradicate older idioms from your code, but it is worth doing. Regarding tooling, check out ClangMR https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41342.pdf https://static.googleusercontent.com/media/research.google.c...
- bluGill 6y ago
  What is your alternative? Do the great rewrite every few years to the latest fads? Some have done that successfully, but it is expensive to get right and many more have failed. In general, if it ain't broke don't break it is a great use of resources, which keeps your company in business (thus you making steady paycheck and going home to your family at night). Fix/update the parts that need updating because they change and let the working stuff keep working. I will give a nod to the other poster who pointed out automatic tools. They are often worth running on everything, but they only fix a fraction of the things that a sane developer with 20/20 hindsight starting over would do differently.
- dragontamer 6y ago
  I mean, is it harder than writing code in C++98 style, then suddenly having to deal with C++ and Rust combinations from 2015 onwards? I'd say C++98 + C++17 is easier to deal with than C++98 + Rust.
jacoblambda 6y ago
This unfortunately isn't really quite entirely true any more. There are a number of depreciations in C++17 and up that prevent older C++ code from working out of the box. Keep in mind that these are largely relatively useless or now replaced features so any incompatibilities should be both few and far between and relatively easy to fix.
- rfoo 6y ago
  And you can always compile your old codes with older C++ standards, codes compiled in C++11 / C++14 / C++17 are mostly ABI compatible so they can be (relatively safely) linked together.
SomeoneFromCA 6y ago
This enables easy porting of good old C code, to C++.

jdsully 6y ago

"I think that the new C++20 standard might be one of the main causes for this," TIOBE CEO Paul Jansen said in the latest report.

jeffbee 6y ago
C++20 wasn't even ratified until earlier this month. I seriously doubt that most industry programmers are using it, or even have access to C++20 toolchains. My new job is to port a company forward to C++11, FML.
- SloopJon 6y ago
  Right, but TIOBE doesn't measure usage. It measures popularity by way of search engines. As people blog about their favorite new feature of C++20, it drives interest.
  - jeffbee 6y ago
    Actually I did not know that. I thought it was some kind of field survey. How did they do it in the 80s?
    - SloopJon 6y ago
      The FAQ says that their dataset only goes back until June of 2001, so I imagine the methodology for the prior years in the Very Long Term History section was somewhat different. The claim at the top of the page is that "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." However, the details show that it really is just a single search term across a variety of search engines. Maybe they used to have an intern read the classifieds at the back of the Communications of the ACM or something.
disown 6y ago
Perhaps it is because school is starting ( physically or online ) and many high schools/colleges teach C/C++? I wonder if there is a slight bump in C++ use every september?

pjmlp 6y ago

Just like anything else, does anyone understands every single feature available in Java 15, C# 9 or F# 5 or the respective runtimes, including the several implementations across multiple vendors?

vlovich123 6y ago

Which Rust? Which Swift? Which Python? Which Java? Which C#? All languages evolve & change, not just HMTL5/ES5. I worked at Apple when Swift was first rolled out & the language today is very different & unrecognizable to me from the one that exists today. The original code won't even compile today (not necessarily terrible if the automated conversion tools are 100% perfect). Java is on a ~1yr cadence for the past 3 years (used to be 2 before that except for Java 7, 8 & 9 which had a longer lead time & likely not coincidentally is the time period that saw tremendous growth in C#) Swift is on a ~1 yr cadence with major language changes still happening. Upgrades are managed by automatic tooling. Will be interesting to see if Apple can sustain this long-term (every problem gets magnified a lot with time if you're growing). Rust is on a ~~1 yr cadence although they've come up with an interesting way to land major language changes & improvements into the language (release process rather & I can't recall if they use automated tooling).~~* The problem of evolving languages isn't being ignored but it's a hard challenge. However, any language designer who ignores new up & coming concepts in language design is relegated to repeat the mistakes of C++ and Java which stagnated for long periods & let other languages capture large amounts of market share. Market share = how healthy the ecosystem for that language is & whether new projects get started in it. So if you just try to solve that problem first you'll end up never getting off the ground because you won't have an ecosystem around you to drive investment of time & money from users of that language. I think you're just seeing the reorientation to a faster release cadence in the industry. Rather than waiting many years to deliver on larger features (Python3, Perl5), there's a more regular process to continuously ship smaller subsets of them in a usable form to get feedback, amortize the cost of adoption, & address any issues sooner. This also makes you more competitive in terms of users adopting your language for new projects. This obviously does have an externality cost as there can be less QA & bake time for code. Those can be mitigated with automation. Design defects can be addressed sooner & those are valuable because they're the pain-points for your user base. I wish C++ actually delivered faster but given that there's 3 mainline compilers & a bunch of ancilliary ones, it's going to stagnate & die in favor of Swift or Rust which only have 1 shared reference compiler that everyone uses. It's also why projects like PyPy never grow beyond a small niche if you make that kind of choice. I'm on the side of Swift and Rust models - in C/C++ to support different platforms I need different compilers. This means in any non-trivial project I have to add different per-compiler workarounds to language interpretation or feature set (even clang's attempts to pretend to be GCC or MSVC don't work out well & you end up having to adjust your project to actually be aware of it). * EDIT: Corrected below. Rust is on a 6-week cadence with a 3-year roll-up of the supporting material & an interesting way to support mixing and matching code from different versions.

coliveira 6y ago

Unlike other languages du jour, C++ keeps backward compatibility, so it really doesn't matter. You just need the latest compiler to have access to all these "flavors" of C++.

saagarjha 6y ago
It matters if you’re working with it…