4 ms·

I would argue C++20 is totally fine. MSVC does not yet has a C++23 flag and it will be internally replaced with 'latest', aka some C++26 features, when you use

I would argue C++20 is totally fine. MSVC does not yet has a C++23 flag and it will be internally replaced with 'latest', aka some C++26 features, when you use it. This took us by surprise, because they deprecated some enum conversions and thus our clang-cl CI failed for openCV, with the latest llvm. I still fail to understand why enabling a specific C++ version, automatically means that it is considered stable. At least give use C++23-experimental or something /rant.

pjmlp 2y ago
Writing C++20 code without modules, ranges, or concepts, is like, what is the point. Naturally when code portability doesn't matter, it is another thing. All my C++ side projects are written against C++latest on Visual C++, and make full use of modules and concepts.
- einpoklum 2y ago
  > Writing C++20 code without modules, ranges, or concepts, is like, what is the point. * std::span is in! https://stackoverflow.com/q/45723819/1593077 https://stackoverflow.com/q/45723819/1593077 * Designated initializers (like in C99) * Spaceship operator and default comparison ops * More language constructs can be constexpr'ed * Better structured binding * using on enums * Don't need to say "typename" as much :-) * Bunch of minor improvements to the standard library Note I did not say coroutines. I still don't understand how that boondoggle made it into the language the way that it has.
  - pjmlp 2y ago
    std::span is a trap, gsl::span should be used instead, unless one is willing to enable checked collections on the respective compiler. As for the rest, the point stands regarding portable code across various C++ compilers. I agree on the co-routines, while I know C# co-routines relatively well, and the C++/CX stuff that was used as inspiration for Microsoft's initial proposal, they are a bit of a mess, when key WG21 members also don't fully grasp how they have to be implemented, and we need two hour sessions on C++ conferences to go through "hello world" kind of implementations.
    - deleted 2y ago
      [deleted]
    - vitus 2y ago
      std::span is no more a trap than the rest of C++'s standard library in that regard. Are you also eschewing std::vector and std::string? std::string_view, std::array? I suppose C++26 brings std::span::at, although exceptions are a different can of worms.
      - pjmlp 2y ago
        Some errors are too late to fix, span was originally bounds checked when proposed. Pre-C++98 compiler frameworks used bounds checking by default. And yes, if I am calling the shots, bounds checking are enabled in release builds. Never has been a problem other than performance cargo cult folks. Thankfully governments are making this less of discussion.
        vitus 2y ago
        > And yes, if I am calling the shots, bounds checking are enabled in release builds. No disagreement there. But I'd prefer to turn it on across the board via compiler flag rather than pull in a special library for it and remember to use that library consistently. And if that's the case, I don't see std::span as any more problematic on this front than the rest of the standard library. (Yes, I know, GSL isn't really a special library on Windows. But anywhere else, it is.)
    - protomolecule 2y ago
      >various C++ compilers Which compilers? I'd bet there are compilers that are still stuck at c++98.
    - einpoklum 2y ago
      > std::span is a trap, gsl::span should be used instead It's not a trap if you weren't expecting bounds checking. > we need two hour sessions on C++ conferences to go through "hello world" kind of implementations. After one hour it became clear to me I am going to stay away from that stuff until either it becomes much more usable (unlikely TBH) or someone forces me to use it...
- forrestthewoods 2y ago
  Modules are DOA and won’t happen even by C++32
  - pjmlp 2y ago
    If portability isn't a concern, VC++ with MSBuild, or clang with CMake (without header units), are pretty much quite usable. However I do agree with the feeling for large scale adoption. The way modules and concepts went down, or the way GC API got added only to be removed, or ongoing contracts discussion, has pretty much settled my opinion that WG21 really needs to adopt the same approach as other programming language communities. Papers without working implementations for community feedback shouldn't be accepted at all.
    - bluGill 2y ago
      That is generally the case. Modules had two different proposals with thair own implementation and they choose the one microsoft iplementet after debate which is why msvc had modules from the start.
      - pjmlp 2y ago
        The missing part of that story is that they ended up compromising on a third approach, without build tools support, with the hope everything would be quickly settled after shipping the standard. Apple and Google kept using clang header modules, switched focus to their C++ replacements, and clang transition to C++20 modules languished until a few heroes stepped in to do the work. Meanwhile GCC is still work in progress. And build tools are still a mess, even cmake doesn't have yet a story for header units. As for Microsoft, except for Office, there isn't a single Microsoft product, especially C++ SDKs, that make use of modules in any form. This is quite different from how other programming language ecosystems migrate features from preview into stable.
    - chipdart 2y ago
      > However I do agree with the feeling for large scale adoption. I think that everyone has misguided and naive expectations on how such a radical change would roll out to production software. Changing dpendency management and updating build systems is a hard sell for professional projects delivering production software. It's the most radical change in how you're software is built with zero upside in terms of features. Best case scenario your software works as it always did. Worst case scenario you wasted tons of developement effort to retool and revamp your whole CICD pipeline just to break your project. Hard sell. I mean, why do people think so many projects are still stuck with C++11?
- dxuh 2y ago
  Concepts are well supported and have been for a while and they are so great. Those alone make C++20 worth it. But Coroutines also make it worth it, if you build software that can use them well. Designated initializers change how I write code (for the better - by a lot). And of course std::span.
  - pjmlp 2y ago
    Portable code across various C++ compilers....
- chipdart 2y ago
  > Writing C++20 code without modules, ranges, or concepts, is like, what is the point. The point is, obviously, use other features introduced in C++20 and not have to deal with artificial restrictions when you opt to onboard onto whatever feature you'd like. To me C++20 has more to do with designated initializers than modules, for the very obvious reasons. It's fine if you take a pass at an upgrade and prefer to take the hit of migrating through a bigger delta, but framing this thing as "what is the point" is indeed missing the whole point.
  - pjmlp 2y ago
    Assuming said C++20 features are actually portable across various compilers.
    - chipdart 2y ago
      Do you understand what C++20 means in terms of compiler support? I don't know how anyone can post messages in this thread without understanding that.
- kevin_thibedeau 2y ago
  consteval is worth it alone.

pjmlp 2y ago

Writing C++20 code without modules, ranges, or concepts, is like, what is the point. Naturally when code portability doesn't matter, it is another thing. All my C++ side projects are written against C++latest on Visual C++, and make full use of modules and concepts.

einpoklum 2y ago
> Writing C++20 code without modules, ranges, or concepts, is like, what is the point. * std::span is in! https://stackoverflow.com/q/45723819/1593077 https://stackoverflow.com/q/45723819/1593077 * Designated initializers (like in C99) * Spaceship operator and default comparison ops * More language constructs can be constexpr'ed * Better structured binding * using on enums * Don't need to say "typename" as much :-) * Bunch of minor improvements to the standard library Note I did not say coroutines. I still don't understand how that boondoggle made it into the language the way that it has.
- pjmlp 2y ago
  std::span is a trap, gsl::span should be used instead, unless one is willing to enable checked collections on the respective compiler. As for the rest, the point stands regarding portable code across various C++ compilers. I agree on the co-routines, while I know C# co-routines relatively well, and the C++/CX stuff that was used as inspiration for Microsoft's initial proposal, they are a bit of a mess, when key WG21 members also don't fully grasp how they have to be implemented, and we need two hour sessions on C++ conferences to go through "hello world" kind of implementations.
  - deleted 2y ago
    [deleted]
  - vitus 2y ago
    std::span is no more a trap than the rest of C++'s standard library in that regard. Are you also eschewing std::vector and std::string? std::string_view, std::array? I suppose C++26 brings std::span::at, although exceptions are a different can of worms.
    - pjmlp 2y ago
      Some errors are too late to fix, span was originally bounds checked when proposed. Pre-C++98 compiler frameworks used bounds checking by default. And yes, if I am calling the shots, bounds checking are enabled in release builds. Never has been a problem other than performance cargo cult folks. Thankfully governments are making this less of discussion.
      - vitus 2y ago
        > And yes, if I am calling the shots, bounds checking are enabled in release builds. No disagreement there. But I'd prefer to turn it on across the board via compiler flag rather than pull in a special library for it and remember to use that library consistently. And if that's the case, I don't see std::span as any more problematic on this front than the rest of the standard library. (Yes, I know, GSL isn't really a special library on Windows. But anywhere else, it is.)
  - protomolecule 2y ago
    >various C++ compilers Which compilers? I'd bet there are compilers that are still stuck at c++98.
  - einpoklum 2y ago
    > std::span is a trap, gsl::span should be used instead It's not a trap if you weren't expecting bounds checking. > we need two hour sessions on C++ conferences to go through "hello world" kind of implementations. After one hour it became clear to me I am going to stay away from that stuff until either it becomes much more usable (unlikely TBH) or someone forces me to use it...
forrestthewoods 2y ago
Modules are DOA and won’t happen even by C++32
- pjmlp 2y ago
  If portability isn't a concern, VC++ with MSBuild, or clang with CMake (without header units), are pretty much quite usable. However I do agree with the feeling for large scale adoption. The way modules and concepts went down, or the way GC API got added only to be removed, or ongoing contracts discussion, has pretty much settled my opinion that WG21 really needs to adopt the same approach as other programming language communities. Papers without working implementations for community feedback shouldn't be accepted at all.
  - bluGill 2y ago
    That is generally the case. Modules had two different proposals with thair own implementation and they choose the one microsoft iplementet after debate which is why msvc had modules from the start.
    - pjmlp 2y ago
      The missing part of that story is that they ended up compromising on a third approach, without build tools support, with the hope everything would be quickly settled after shipping the standard. Apple and Google kept using clang header modules, switched focus to their C++ replacements, and clang transition to C++20 modules languished until a few heroes stepped in to do the work. Meanwhile GCC is still work in progress. And build tools are still a mess, even cmake doesn't have yet a story for header units. As for Microsoft, except for Office, there isn't a single Microsoft product, especially C++ SDKs, that make use of modules in any form. This is quite different from how other programming language ecosystems migrate features from preview into stable.
  - chipdart 2y ago
    > However I do agree with the feeling for large scale adoption. I think that everyone has misguided and naive expectations on how such a radical change would roll out to production software. Changing dpendency management and updating build systems is a hard sell for professional projects delivering production software. It's the most radical change in how you're software is built with zero upside in terms of features. Best case scenario your software works as it always did. Worst case scenario you wasted tons of developement effort to retool and revamp your whole CICD pipeline just to break your project. Hard sell. I mean, why do people think so many projects are still stuck with C++11?
dxuh 2y ago
Concepts are well supported and have been for a while and they are so great. Those alone make C++20 worth it. But Coroutines also make it worth it, if you build software that can use them well. Designated initializers change how I write code (for the better - by a lot). And of course std::span.
- pjmlp 2y ago
  Portable code across various C++ compilers....
chipdart 2y ago
> Writing C++20 code without modules, ranges, or concepts, is like, what is the point. The point is, obviously, use other features introduced in C++20 and not have to deal with artificial restrictions when you opt to onboard onto whatever feature you'd like. To me C++20 has more to do with designated initializers than modules, for the very obvious reasons. It's fine if you take a pass at an upgrade and prefer to take the hit of migrating through a bigger delta, but framing this thing as "what is the point" is indeed missing the whole point.
- pjmlp 2y ago
  Assuming said C++20 features are actually portable across various compilers.
  - chipdart 2y ago
    Do you understand what C++20 means in terms of compiler support? I don't know how anyone can post messages in this thread without understanding that.
kevin_thibedeau 2y ago
consteval is worth it alone.