Le 2021-10-19 08:26, Gavin Lambert via Boost a écrit :
On 19/10/2021 18:42, Julien Blanc wrote:
I'm sorry but i'm gonna raise that suggestion. While I agree it does not solve the general use case, it looks to me like an acceptable solution for boost.json. IIRC boost.json is advertised as a nearly header-only library, where you have to include an hpp file once in your project. So ABI mismatch should not hold there (by the way, i just checked that it is the way it is packaged on my debian stable, no binary for json is included).
Header-only does not avoid ABI ODR problems. It just moves where they occur (which in some ways makes them a lot worse than built libraries).
I'm with Peter on that one: just throwing in a preprocessor-conditioned typedef is not a reasonable solution.
I'm certainly biased toward our own use cases. Maintaining a medium sized (<1Mloc) that needs to compile with compilers as old as gcc4.8 as well as new compilers such as gcc11, and several boost versions, we already have our base library filled with things such as: #if __cplusplus >= 201703L using filesystem = std::filesystem; #else using filesystem = boost::variant; #endif And then our code works on the compile time selected type. They're usually close enough so that it works (and if it doesn't, we write the required helper functions). The fact that we're always compiling the whole target (embedded world) certainly helps avoiding ABI issues. I don't know how widespread doing this is. But i would be surprised if it were really uncommon.
Preprocessor-conditioned overloads *do* work for arguments (though is an additional implementation burden since you would have to provide multiple implementations of the same thing), but doesn't help for return types, since sadly the return type does not participate in name mangling or overload resolution. While not impossible to have ABI-preserving alternative methods varying by return type, having one well-defined return type is really the best solution for that.
I'm not sure i was being clear here. I'm not talking about overloads, but about replacements. Something like #if __cplusplus >= 201703L using string_view = std::string_view #else using string_view = boost::string_view #endif The interfaces are close enough so that there shouldn't be a need to implement things twice in boost::json, which would always use boost::json::string_view. You either got the c++14 boost::string_view api, or the c++17 std::string_view api, but never both. As a user, i fully supports what Vinnie said: users want to use stl types as much as possible, not their boost equivalents. Every time a boost library forces its users to use boostified versions for little or no reasons, it is somewhat hostile to users. So a long term goal should be to remove these, not add more... Regards, Julien