robertlipe
commented
10 months ago std::format !! designated initializers to help our vecs initializers (how many NULLs is that, again?) It's rare that C99 had it first std::endian and std::byteswap to let us finally kill our poorly designed ones. (Outliving Big Endian computers in our market helped...) In other codebases, I've had spans instead of (foo*, size_t) as a non-owning view, like StringView, and it flows nicely In a different project I work on, ranges will be a big deal, but I'm not sure they're that useful to us. Subsetting an array is super fundamental to it, less so to us. std::source_location is something i've wanted in Fatal(), but we dont use FILE, LINE now, so maybe not. using enum cuts down on the repetition of case XcsvStyle::X std::numbers::pi Yawn. It is probably just different enough than ours to regenerate refs. That #define doesn't exactly bother me.
modules. Maybe. I'm still watching them in real code. Hating headers isn't the same as loving modules. Others are excited about concepts. I prefer TMP that doesn't need them. I must live in a simple world.
As a mix of 17 and 20, __has_include ad __has_attribute are handy in a future way. Right now, you can use them unless you ahve a compiler than includes them, though both compilers have included them for a long time. I use it, for example, to include optional "drop in a file and recompile, no source or build edits needed" feature. For us, they're just good to know so we can start sneaking in C++23 or whatever.
On Wed, Nov 1, 2023 at 7:22 AM tsteven4 @.***> wrote:
Should we raise the floor to C++20? Compilers in use:
Assuming we drop toolset v141,version=14.16.27023 which is the lastest toolset for visual studio 2017, and require at least the latest toolsets for visual studio 2019 which would be v142, version 14.29.30133 or any in support toolset for visual studio 2022 which would be >= v143, version 14.32.31326. (14+5=19 on the support features page below).
Ubuntu jammy, has g++ 11.4.0 and clang 14.0.0.
The oldest Xcode we use in CI is currently 12.5.1 on macOS 11, which has apple clang 12.0.5. We could use Xcode 13.2.1, with apple clang 13.0.0 on macOS 11. Compiler/Library feature support
Support is summarized here: https://en.cppreference.com/w/cpp/compiler_support#cpp20 and here https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features Benefits
One features I have wanted for consistency is "Default member initializers for bit-fields", although the impact on our code set is minimal.
What other features would be useful?
— Reply to this email directly, view it on GitHub https://github.com/GPSBabel/gpsbabel/issues/1204, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3ZZMVDU7LFZ4W2ELMTYCI5JBAVCNFSM6AAAAAA6ZGOO4SVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE3TEMRXGQ2DANY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
GPSBabelDeveloper
tsteven4
Should we raise the floor to C++20?
Compilers in use:
Assuming we drop toolset v141,version=14.16.27023 which is the lastest toolset for visual studio 2017, and require at least the latest toolsets for visual studio 2019 which would be v142, version 14.29.30133 or any in support toolset for visual studio 2022 which would be >= v143, version 14.32.31326. (14+5=19 on the support features page below).
Ubuntu jammy, has g++ 11.4.0 and clang 14.0.0.
The oldest Xcode we use in CI is currently 12.5.1 on macOS 11, which has apple clang 12.0.5. We could use Xcode 13.2.1, with apple clang 13.0.0 on macOS 11.
Compiler/Library feature support
Support is summarized here: https://en.cppreference.com/w/cpp/compiler_support#cpp20 and here https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B20_library_features
Benefits
One features I have wanted for consistency is "Default member initializers for bit-fields", although the impact on our code set is minimal.
What other features would be useful?