5 ms·

I'd be curiously to see how many people actually use modern C++ professionally. I've always been under the impression that adoption of the standard lags behind

I'd be curiously to see how many people actually use modern C++ professionally. I've always been under the impression that adoption of the standard lags behind by like 7 years or so.

jcelerier 5y ago
I generally start using -std=c++XX switches in compilers before the standards are actually released ; I don't remember the last time I've seen a project that wasn't at least c++17
- wyldfire 5y ago
  LLVM itself has only just now green-lit using c++17 [1] so I find myself using c++14 most of the time. [1] https://discourse.llvm.org/t/important-new-toolchain-requirements-to-build-llvm-will-most-likely-be-landing-within-a-week-prepare-your-buildbots/61447 https://discourse.llvm.org/t/important-new-toolchain-require...
  - jcelerier 5y ago
    You are seriously missing out. C++17 has worked fine for years with clang - and I wouldn't ever go back to writing sfinae code since c++20 concepts are there, it's a massive simplification; likewise for structured bindings (for(auto& [k,v] : map)), if constexpr, ...
nly 5y ago
I work with a C++20 code base. By which mean... there is at least one C++20 feature in use, which means it won't compile with anything earlier than GCC 11. This reality is probably the norm anywhere you see C++20 job description.
veilrap 5y ago
My company does a decent job at keeping up with the standard. Getting from C++11 to C++14 was challenging, and C++14 to C++17 took quite a bit of time, but we're on track to be on C++20 later this year.
- rubyist5eva 5y ago
  Do you have a strategy for doing this? Since C++ stays relatively backwards compatible I would imagine there is lots of legacy code that gets untouched but newer features would go into the new stuff - with legacy code getting replaced only for big refactorings?
  - veilrap 5y ago
    Our code tends to be shipped running on top of a relatively up-to-date version of linux. So we tend to go through the pain of testing/refactoring needed to get to the next version of C++ when we upgrade to the next stable version of linux that we're going to support.
latenightcoding 5y ago
that sounds about right, 5 years ago I was pleasantly surprised when large existing C++ code bases were C++11, now it's very common.
duped 5y ago
The last time I used C++20 features (modules) I caused a segfault in GCC. This was in December, iirc it was GCC 11.
- pjmlp 5y ago
  Right now VC++ is the only viable option for C++20 modules, and even it isn't without warts.
  - tialaramex 5y ago
    It is kind of crazy that JTC1 is OK with producing entirely imaginary documents. Do you think the two standards bodies know that the product of WG21 is just pieces of paper with no idea whether they can be or will be implemented? Or is this all far above what anybody senior at ISO or the IEC understands because they aren't programmers? Even at W3C you were expected (when I had anything to do with it) to actually build the prototype before you publish the standard, and obviously the IETF's "Rough Consensus and Running Code" speaks to that way of thinking too. I feel like if ISO 216 claimed you can fold a square 1x1 metre piece of paper in half and preserve the proportions, that wouldn't have survived into a published document. Sure you can write that claim, but you cannot actually make that fold, it's surely amazing that the C++ Committee are not subject to the same consideration and yet here we are.
    - mhh__ 5y ago
      They do reject things based on implementation difficulty too. "Static if considered" rejects it on the basis that the implementations would struggle.
      - Kranar 5y ago
        Not really, it had nothing to do with implementation difficulty and the paper actually states that implementing static if would be fairly easy: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n361... What the paper says is that static if would make it much harder to perform static analysis of source code, not really because it's hard to implement but because the kind of combinatorial explosion introduced by having non-local bifurcating source code branches to analyze makes analysis incredibly slow. C++ did eventually adopt if constexpr, which does not have this problem since the branches are always local.
psyclobe 5y ago
I’ve shipped two projects wholly in c++20 in the past 4 years with modern practices spanning three platforms (win/Lin/OSX). No plans to go back to an older standard.
- Kranar 5y ago
  What does "wholly in C++20" mean? How does "wholly in C++20" differ from "partially in C++20" or just "using C++20"?
  - gumby 5y ago
    Not the author of that comment but I would interpret it to mean all the files were compiled with -std=c++20 (or 2a) Given the quality and extent of c++20 support over the past few years it can’t have meant using a lot of c++20 at least for most of the time. Then again things like fmt and ranges had 3P libraries that influenced the standard (I’ve been using them myself for years) so more is possible than came with the compilers. All that being said I would rate the comment as hyperbole. Had it been phrased something like “I’ve been compiling specifying c++20, and have heavily leant on 17 and some key 20 features” I’d be quite fine with it. Features like coroutines still require a lot of plumbing in order to use; features like that go into a standard so that version n+1 can have the right user abstractions, which can only be developed through experience. TBH I quite enjoy using C++ from the perspective of a language not based on C (at least don’t think of it that way) with an amazing c-compatibility layer only very occasionally needed. For example I worked on a large system compiled with c++17 at a very high level of abstraction, but that had a deep grotty memory management using pointers, malloc and mmap implemented in two files. It was invisible to the people worrying about the high level logic.
jahnu 5y ago
All c++20 here and just waiting for Clang and ultimately Xcode to catch up with MSVC so we can use ranges and pmr
- thraneh 5y ago
  range-v3 is a great library allowing you to bridge the gap: https://github.com/ericniebler/range-v3 https://github.com/ericniebler/range-v3
  - jahnu 5y ago
    Oh nice, it will not require any significant changes for when it does become available!
gotaquestion 5y ago
I see a lot of it in the academic AI world, mostly because as students move from Python (study) to real-world deployments, they need to convert to C++ for performance. Hence, over the past decade I've seen C++ start to look more like a transliteration of Python, and be used that way. The fact that TensorFlow on Python can use GPUs/TPUs is a no-brainer, but that only works in the server center and not in the field.
deleted 5y ago
[deleted]
pavlov 5y ago
I wrote C++ at Facebook last year and got to use C++20 features like ranges. It wasn’t my call, though. Meta has a relatively big C++ infra team that participates in the standards committee, maintains the Folly utility library, and decides how complex new features like coroutines are adopted. On top of that, my code plugged into another team’s system, and they had written their own guidelines on how/if they want to use specific C++ and Folly features. These guardrails were really useful for a C fossil like me with an on-off relationship to C++… It’s not a terrible language anymore, but it’s even harder than before to find the right subset. At least boost can be finally buried.
GuB-42 5y ago
That's about right in my case. 2019 was more or less the years we switched to C++11. Some projects started using C++11 way earlier, and we still have some code we keep C++98, so, 8 years. Anyways, I don't know what you are calling "modern" C++, but for me it is C++11 and up. C++11 to C++20 introduced a few major changes but none as pervasive as C++98 to C++11.
Espressosaurus 5y ago
I've been using C++17 since 2019; C++11 since 2013, and we're starting to scope out upgrading our toolchain to C++20. Depending on where you work at, my experience suggests 2-5 years for adoption.
- BenFrantzDale 5y ago
  We are on the same timeline.
advael 5y ago
I have a habit of modernizing (and functionalizing) C++ codebases in recent jobs I've taken, which tends to fix a lot of memory-related bugs as well as improving performance and readability. When an organization is hidebound in some way, someone has to push to make the change, but it definitely can happen if you can demonstrate the benefits
fassssst 5y ago
Windows uses it extensively for both user land system code and the app platform.
29athrowaway 5y ago
Low level languages give you fine control over memory management. But many companies do not like how the standard library does memory management and they roll their own allocators and libraries that use them.
- gumby 5y ago
  You can usually roll your own allocators and use them the standard library. But one of the nice things about c++ is when you have specialized needs you can write your own implementation of something and it’s just as “first class” as something in std::.
22SAS 5y ago
I work for an HFT firm. We have been using C++20 as well. Mostly C++20 concepts.
patrick451 5y ago
We've been on c++14 for quite a while, and moved everything to c++17 a few months ago.

I'd be curiously to see how many people actually use modern C++ professionally. I've always been under the impression that adoption of the standard lags behind by like 7 years or so.

jcelerier 5y ago

I generally start using -std=c++XX switches in compilers before the standards are actually released ; I don't remember the last time I've seen a project that wasn't at least c++17

wyldfire 5y ago
LLVM itself has only just now green-lit using c++17 [1] so I find myself using c++14 most of the time. [1] https://discourse.llvm.org/t/important-new-toolchain-requirements-to-build-llvm-will-most-likely-be-landing-within-a-week-prepare-your-buildbots/61447 https://discourse.llvm.org/t/important-new-toolchain-require...
- jcelerier 5y ago
  You are seriously missing out. C++17 has worked fine for years with clang - and I wouldn't ever go back to writing sfinae code since c++20 concepts are there, it's a massive simplification; likewise for structured bindings (for(auto& [k,v] : map)), if constexpr, ...

nly 5y ago

I work with a C++20 code base. By which mean... there is at least one C++20 feature in use, which means it won't compile with anything earlier than GCC 11. This reality is probably the norm anywhere you see C++20 job description.

veilrap 5y ago

My company does a decent job at keeping up with the standard. Getting from C++11 to C++14 was challenging, and C++14 to C++17 took quite a bit of time, but we're on track to be on C++20 later this year.

rubyist5eva 5y ago
Do you have a strategy for doing this? Since C++ stays relatively backwards compatible I would imagine there is lots of legacy code that gets untouched but newer features would go into the new stuff - with legacy code getting replaced only for big refactorings?
- veilrap 5y ago
  Our code tends to be shipped running on top of a relatively up-to-date version of linux. So we tend to go through the pain of testing/refactoring needed to get to the next version of C++ when we upgrade to the next stable version of linux that we're going to support.

latenightcoding 5y ago

that sounds about right, 5 years ago I was pleasantly surprised when large existing C++ code bases were C++11, now it's very common.

duped 5y ago

The last time I used C++20 features (modules) I caused a segfault in GCC. This was in December, iirc it was GCC 11.

pjmlp 5y ago
Right now VC++ is the only viable option for C++20 modules, and even it isn't without warts.
- tialaramex 5y ago
  It is kind of crazy that JTC1 is OK with producing entirely imaginary documents. Do you think the two standards bodies know that the product of WG21 is just pieces of paper with no idea whether they can be or will be implemented? Or is this all far above what anybody senior at ISO or the IEC understands because they aren't programmers? Even at W3C you were expected (when I had anything to do with it) to actually build the prototype before you publish the standard, and obviously the IETF's "Rough Consensus and Running Code" speaks to that way of thinking too. I feel like if ISO 216 claimed you can fold a square 1x1 metre piece of paper in half and preserve the proportions, that wouldn't have survived into a published document. Sure you can write that claim, but you cannot actually make that fold, it's surely amazing that the C++ Committee are not subject to the same consideration and yet here we are.
  - mhh__ 5y ago
    They do reject things based on implementation difficulty too. "Static if considered" rejects it on the basis that the implementations would struggle.
    - Kranar 5y ago
      Not really, it had nothing to do with implementation difficulty and the paper actually states that implementing static if would be fairly easy: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n361... What the paper says is that static if would make it much harder to perform static analysis of source code, not really because it's hard to implement but because the kind of combinatorial explosion introduced by having non-local bifurcating source code branches to analyze makes analysis incredibly slow. C++ did eventually adopt if constexpr, which does not have this problem since the branches are always local.

psyclobe 5y ago

I’ve shipped two projects wholly in c++20 in the past 4 years with modern practices spanning three platforms (win/Lin/OSX). No plans to go back to an older standard.

Kranar 5y ago
What does "wholly in C++20" mean? How does "wholly in C++20" differ from "partially in C++20" or just "using C++20"?
- gumby 5y ago
  Not the author of that comment but I would interpret it to mean all the files were compiled with -std=c++20 (or 2a) Given the quality and extent of c++20 support over the past few years it can’t have meant using a lot of c++20 at least for most of the time. Then again things like fmt and ranges had 3P libraries that influenced the standard (I’ve been using them myself for years) so more is possible than came with the compilers. All that being said I would rate the comment as hyperbole. Had it been phrased something like “I’ve been compiling specifying c++20, and have heavily leant on 17 and some key 20 features” I’d be quite fine with it. Features like coroutines still require a lot of plumbing in order to use; features like that go into a standard so that version n+1 can have the right user abstractions, which can only be developed through experience. TBH I quite enjoy using C++ from the perspective of a language not based on C (at least don’t think of it that way) with an amazing c-compatibility layer only very occasionally needed. For example I worked on a large system compiled with c++17 at a very high level of abstraction, but that had a deep grotty memory management using pointers, malloc and mmap implemented in two files. It was invisible to the people worrying about the high level logic.

jahnu 5y ago

All c++20 here and just waiting for Clang and ultimately Xcode to catch up with MSVC so we can use ranges and pmr

thraneh 5y ago
range-v3 is a great library allowing you to bridge the gap: https://github.com/ericniebler/range-v3 https://github.com/ericniebler/range-v3
- jahnu 5y ago
  Oh nice, it will not require any significant changes for when it does become available!

gotaquestion 5y ago

I see a lot of it in the academic AI world, mostly because as students move from Python (study) to real-world deployments, they need to convert to C++ for performance. Hence, over the past decade I've seen C++ start to look more like a transliteration of Python, and be used that way. The fact that TensorFlow on Python can use GPUs/TPUs is a no-brainer, but that only works in the server center and not in the field.

deleted 5y ago

[deleted]

pavlov 5y ago

I wrote C++ at Facebook last year and got to use C++20 features like ranges. It wasn’t my call, though. Meta has a relatively big C++ infra team that participates in the standards committee, maintains the Folly utility library, and decides how complex new features like coroutines are adopted. On top of that, my code plugged into another team’s system, and they had written their own guidelines on how/if they want to use specific C++ and Folly features. These guardrails were really useful for a C fossil like me with an on-off relationship to C++… It’s not a terrible language anymore, but it’s even harder than before to find the right subset. At least boost can be finally buried.

GuB-42 5y ago

That's about right in my case. 2019 was more or less the years we switched to C++11. Some projects started using C++11 way earlier, and we still have some code we keep C++98, so, 8 years. Anyways, I don't know what you are calling "modern" C++, but for me it is C++11 and up. C++11 to C++20 introduced a few major changes but none as pervasive as C++98 to C++11.

Espressosaurus 5y ago

I've been using C++17 since 2019; C++11 since 2013, and we're starting to scope out upgrading our toolchain to C++20. Depending on where you work at, my experience suggests 2-5 years for adoption.

BenFrantzDale 5y ago
We are on the same timeline.

advael 5y ago

I have a habit of modernizing (and functionalizing) C++ codebases in recent jobs I've taken, which tends to fix a lot of memory-related bugs as well as improving performance and readability. When an organization is hidebound in some way, someone has to push to make the change, but it definitely can happen if you can demonstrate the benefits

fassssst 5y ago

Windows uses it extensively for both user land system code and the app platform.

29athrowaway 5y ago

Low level languages give you fine control over memory management. But many companies do not like how the standard library does memory management and they roll their own allocators and libraries that use them.

gumby 5y ago
You can usually roll your own allocators and use them the standard library. But one of the nice things about c++ is when you have specialized needs you can write your own implementation of something and it’s just as “first class” as something in std::.

22SAS 5y ago

I work for an HFT firm. We have been using C++20 as well. Mostly C++20 concepts.

patrick451 5y ago

We've been on c++14 for quite a while, and moved everything to c++17 a few months ago.