4 ms·

Luckily most C++ developers don't immediately jump on and begin using backwards incompatible features. The C++ community is still only recently generally requir

Luckily most C++ developers don't immediately jump on and begin using backwards incompatible features. The C++ community is still only recently generally requiring C++11. And that's great. Introduce new features but don't immediately use them in practice. Some other languages and their communities could really learn from this.

jcelerier 2y ago
> The C++ community is still only recently generally requiring C++11. this doesn't match what I see. The Jetbrains 2023 survey reported that 80% of C++ in use was >= C++17. Qt, one of the most common C++ UI framework, has been requiring C++17 for five years and support C++20 types in its API.
- superkuh 2y ago
  Ah, Jetbrains must be touching a different part of the elephant. My related experience is with compiling C++ programs meant for human people to run on their own home computers. I imagine internal company dev projects like Jetbrains would cover don't care nearly so much about compatibility. Also I note that 25%+ of the Jetbrains 2023 survey use C++11 or older. And 50% of Jetbrains survey devs say "No, I don't plan to move to another C++ standard" from C++11. So it's likely that 25% will stay high.
  - devnullbrain 2y ago
    C++14 minimum is the standard
    - mrlonglong 2y ago
      I agree. We recently moved to C++14 because we wanted shared_ptr<> and make_shared<>. Made our lives immensely easier.
  - IshKebab 2y ago
    Nah it's not just Jetbrains. C++17 is the bare minimum at this point. It's even the default in GCC.
juliangmp 2y ago
C++ has many ugly parts to it, but I wouldn't call sticking with a 14 year old language "great". There's plenty of things that are really damn good, for example - std::span - std::string_view - std::source_location - if constexpr ...
kstrauser 2y ago
I feel exactly the opposite. If a language adds a new feature that's useful to me, and it helps me write better code, I'm going to use it. Perhaps not on the first day it comes out, but definitely the next time I need its functionality. And why not? That's why the feature was added in the first place. There's the chance that its newness means it's not thoroughly tested yet. In any language with a reasonable development process, I'd open a bug report and then figure out a workaround until it's fixed. But I'd expect the interval between "feature is released" and "feature works as documented, modulo the usual long tail of edge cases" to be on the order of weeks or months, not decades. Like, I can't imagine only now upgrading to Python 2.7 (which was current in 2011). I wouldn't expect every shop to be on 3.13 already, but neither would I scowl at a dev who wanted to use something new from a 2-year-old version.
- superkuh 2y ago
  I agree with you from the developer point of view. But you should consider the point of view that other people might want to compile your software. Python is a great example of a software community that has enormous trouble due to always changing the languae and using new features. It's pretty much infeasible to run a python program on your system python these days. Every single python program requires it's entire own custom python in a container.
  - kstrauser 2y ago
    I'm only sympathetic to a point. If I distributed C++ code to paying customers who wanted to compile it locally, I'd surely take their needs into account. For anything I was releasing as FOSS, deal with it. For instance, my nearby server is running Debian 12/Bookworm with GCC 12. According to https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html, that supports nearly all of C++20. If you can't be bothered to upgrade to your system every few years, I'm not going to make more than 0 effort to cater to your ancient compilers. In Python terms, today I wouldn't break a sweat to manage unsupported Python versions (https://devguide.python.org/versions/ https://devguide.python.org/versions/). If my stuff runs on an old Python 3.8 system, right on! I wouldn't deliberately break it or anything. But if something came along in 3.9 that makes my life more pleasant, I wouldn't hesitate to use it. I also vehemently disagree with your Python characterization. There are any number of common, well-supported ways to easily install arbitrary versions on your system, including pyenv and uv. I have multiple versions installed on the laptop I'm typing this on. I do zero development inside containers: all my work runs directly on the host. And yet, none of them conflict with each other at all.
deleted 2y ago
[deleted]
pjmlp 2y ago
In general C++17 is the common standard most C++ projects refer to. Additionally between C++11 and C++14, it is a mistake to use C++11 instead of C++14, as the later is basically the set of features that missed C++11, especially relevant in smart pointers machinery.

jcelerier 2y ago

> The C++ community is still only recently generally requiring C++11. this doesn't match what I see. The Jetbrains 2023 survey reported that 80% of C++ in use was >= C++17. Qt, one of the most common C++ UI framework, has been requiring C++17 for five years and support C++20 types in its API.

superkuh 2y ago
Ah, Jetbrains must be touching a different part of the elephant. My related experience is with compiling C++ programs meant for human people to run on their own home computers. I imagine internal company dev projects like Jetbrains would cover don't care nearly so much about compatibility. Also I note that 25%+ of the Jetbrains 2023 survey use C++11 or older. And 50% of Jetbrains survey devs say "No, I don't plan to move to another C++ standard" from C++11. So it's likely that 25% will stay high.
- devnullbrain 2y ago
  C++14 minimum is the standard
  - mrlonglong 2y ago
    I agree. We recently moved to C++14 because we wanted shared_ptr<> and make_shared<>. Made our lives immensely easier.
- IshKebab 2y ago
  Nah it's not just Jetbrains. C++17 is the bare minimum at this point. It's even the default in GCC.

juliangmp 2y ago

C++ has many ugly parts to it, but I wouldn't call sticking with a 14 year old language "great". There's plenty of things that are really damn good, for example - std::span - std::string_view - std::source_location - if constexpr ...

kstrauser 2y ago

I feel exactly the opposite. If a language adds a new feature that's useful to me, and it helps me write better code, I'm going to use it. Perhaps not on the first day it comes out, but definitely the next time I need its functionality. And why not? That's why the feature was added in the first place. There's the chance that its newness means it's not thoroughly tested yet. In any language with a reasonable development process, I'd open a bug report and then figure out a workaround until it's fixed. But I'd expect the interval between "feature is released" and "feature works as documented, modulo the usual long tail of edge cases" to be on the order of weeks or months, not decades. Like, I can't imagine only now upgrading to Python 2.7 (which was current in 2011). I wouldn't expect every shop to be on 3.13 already, but neither would I scowl at a dev who wanted to use something new from a 2-year-old version.

superkuh 2y ago
I agree with you from the developer point of view. But you should consider the point of view that other people might want to compile your software. Python is a great example of a software community that has enormous trouble due to always changing the languae and using new features. It's pretty much infeasible to run a python program on your system python these days. Every single python program requires it's entire own custom python in a container.
- kstrauser 2y ago
  I'm only sympathetic to a point. If I distributed C++ code to paying customers who wanted to compile it locally, I'd surely take their needs into account. For anything I was releasing as FOSS, deal with it. For instance, my nearby server is running Debian 12/Bookworm with GCC 12. According to https://gcc.gnu.org/projects/cxx-status.html https://gcc.gnu.org/projects/cxx-status.html, that supports nearly all of C++20. If you can't be bothered to upgrade to your system every few years, I'm not going to make more than 0 effort to cater to your ancient compilers. In Python terms, today I wouldn't break a sweat to manage unsupported Python versions (https://devguide.python.org/versions/ https://devguide.python.org/versions/). If my stuff runs on an old Python 3.8 system, right on! I wouldn't deliberately break it or anything. But if something came along in 3.9 that makes my life more pleasant, I wouldn't hesitate to use it. I also vehemently disagree with your Python characterization. There are any number of common, well-supported ways to easily install arbitrary versions on your system, including pyenv and uv. I have multiple versions installed on the laptop I'm typing this on. I do zero development inside containers: all my work runs directly on the host. And yet, none of them conflict with each other at all.

deleted 2y ago

[deleted]

pjmlp 2y ago

In general C++17 is the common standard most C++ projects refer to. Additionally between C++11 and C++14, it is a mistake to use C++11 instead of C++14, as the later is basically the set of features that missed C++11, especially relevant in smart pointers machinery.