C++ 20

[Woazboat]

What's the status for moving from C++17 to C++20?

Is it planned to do so eventually? Are there any blockers?

[mmd-osm]

I haven't really thought about this in detail. I'd say it depends a bit on the libaries we're using. libpqxx as an example announced that the next 8.x version requires C++20. However, it might take some time until this shows up as a package in the Debian releases we're using. That doesn't mean that earlier versions wouldn't work with C++20, but that needs some testing of course.

Were you looking for some specific features which would make our lifes easier with C++20 today? One candidate could be https://en.cppreference.com/w/cpp/utility/format to remove the fmt dependency. Anything else maybe?

[Woazboat]

Replacing the fmt lib with std::format would be one benefit, but C++20 also has some other nice features such as ranges, better constexpr, better metaprogramming features, coroutines, etc...

https://oleksandrkvl.github.io/2021/04/02/cpp-20-overview.html

At this point it's also been out long enough that support is solid and all the bugs have been ironed out.

[Woazboat]

Also things like this #280 (comment)

[tomhughes]

You need gcc 13 to get std::format though so Ubuntu 22.04 won't be able to use it even if you use C++20 mode.

I'd forget about coroutines as well - they're more theoretical than practical in C++20.

[Woazboat]

Vanilla coroutines in c++20 are unfortunately not very usable, yes.
Anyway, there are no downsides to migrating as far as I can see and it'll be needed at some point in the future anyway.

[Woazboat]

Okay, found blocker # 1

The libpqxx packages version < 7.9.0 as shipped in Debian (and very likely Ubuntu as well) are built with C++17 and cannot be linked with programs built with C++20

jtv/libpqxx#732

[tomhughes]

That's odd - there's no ABI break in libstdc++ for C++20 at all. The last ABI break was for std::string and std::list in C++11.

Looking at that ticket it looks like there is indeed something using the pre-C++11 std::string ABI for some reason - technically switching that ABI is not tied to the C++ version as such but I'm not sure when Debian/Ubuntu switched the default though Fedora did it long ago.

[mmd-osm]

Another (potential) use case for C++20:

Based on https://stackoverflow.com/questions/75066606/indentation-aware-raw-string-literals we could remove leading spaces in the raw string literals used in SQL statements: https://godbolt.org/z/5ovaq8E91 or https://godbolt.org/z/5je94K4ve (with space instead of newline).

Benefit would be much less clutter in db statement logs while preserving formatting in the source code. Symbol names in nm look a bit crazy, though.

Also, the resulting string would be almost exactly the same as in https://github.com/zerebubuth/openstreetmap-cgimap/blob/master/src/backend/apidb/readonly_pgsql_selection.cpp#L214 today, but you could write the SQL statement as raw string without all the quoting chars and escaping everywhere.

Ok, I really wanted to try this out. Not so sure if it's a good fit for CGImap due to the added complexity.

[pnorman]

Is the latest post in the right place? It seems disconnected for from C++20

[mmd-osm]

Yes, it's related to C++20. Once you switch to something pre C++20 in Compiler Explorer, it will no longer compile. I added a comment now to make that a bit clearer.

[Woazboat]

Okay, found blocker # 1

The libpqxx packages version < 7.9.0 as shipped in Debian (and very likely Ubuntu as well) are built with C++17 and cannot be linked with programs built with C++20

jtv/libpqxx#732

I looked into this a bit more to understand what's actually going on there. It's not actually a libstdc++ ABI break issue, the code is already using the post C++11 ABI version.

Function definitions in libpqxx < v7.9.0 include headers are defined incorrectly in a way that causes them to vary depending on available language features / C++ standard version. This causes a mismatch between the compiled code in the installed shared library binaries and the development headers.

For C++ standard versions after C++ 20, pqxx exceptions in except.hxx / except.cxx have an additional std::source_location constructor parameter and class member that are not present for older C++ versions. The libpqxx shared library binaries distributed in Debian and Ubuntu are compiled with an older C++ standard version, so the compiled code does not have the additional std::source_location member / constructor parameter.
However, the development headers distributed alongside the shared library are not fixed to the C++ version the library was compiled with and have different function / class declarations depending on the C++ standard version that is used to compile the code that includes these headers. This causes a mismatch between the declarations in the header files and the actual pre-compiled code in the shared library binary when compiling with C++ 20. The code using the library sees the function declarations with the additional std::source_location parameters, but the library actually only contains the versions without the additional parameter.