3 ms·
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 sta
by psyclobe 4y 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 4y agoWhat does "wholly in C++20" mean? How does "wholly in C++20" differ from "partially in C++20" or just "using C++20"?
- gumby 4y agoNot 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.