Re: Opinions on introduction of string_view in Core

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-19 06:26:43

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.

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.

(FWIW, I agree that boost::string_view should be that type, but I'm not 
fond of the contortions being proposed to avoid changing the current 
one.  And I especially don't like the idea of trying to alias 
boost::core::string_view as boost::string_view while the one in 
Boost.Utility still exists; while that won't in itself cause ODR 
problems, it will cause aggravating compile errors if both end up 
included, which is highly probable.  The current Boost.Core 
implementation doesn't appear to be doing that, but it sounded like it 
was being suggested.)

It's not too bad if all methods that return string_view also take a 
string_view as argument; it's most problematic for those that need to 
return string_view with no arguments.

Also, before you suggest template duck-typing for arguments so that you 
can avoid implementing every method twice: templates are problematic 
when you want to allow implicit conversions (such as from std::string 
and constant strings), so you're likely to need even more overloads that 
way.  And pre-Concept template metaprogramming to make those overloads 
actually work is frequently inscrutable and fragile.