Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk