Re: Opinions on introduction of string_view in Core

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2021-10-19 07:54:25

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