Subject: Re: [boost] [system] Header-only Boost.System by default ?
From: Mike Gresens (mike.gresens_at_[hidden])
Date: 2017-10-10 19:40:29
So, what would happen if boost::system uses aliases to std if we have a
modern >= C++11 compiler?!
We would have no dependency to libboost_system.so
So it's like a header only library.
Linking to libstdc++ (or libc++, ...) is always necessary - so no issue.
That would be really cool.
E.g. using boost::beast with boost::asio, but no runtime dependency to
Am 10.10.2017 um 21:30 schrieb Andrey Semashev via Boost:
> On 10/10/17 22:27, Mike Gresens via Boost wrote:
>> Am 10.10.2017 um 10:21 schrieb Groke, Paul via Boost:
>>>> -----Original Message-----
>>>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey
>>>> Semashev via Boost
>>>> Sent: Dienstag, 10. Oktober 2017 09:32
>>>> Subject: Re: [boost] [system] Header-only Boost.System by default ?
>>>> It will have the same address as long as get_basic_error_category()
>>>> is called
>>>> within the same module (dll, so, exe, etc.) If this function is
>>>> compiled in
>>>> different modules then there will be multiple instances of the
>>>> category with
>>>> different addresses.
>>>> On Linux and probably other Unix-like systems this can be solved by
>>>> exporting the category instance, which is the default. I don't
>>>> think this can be
>>>> done on Windows - you'd have to export get_basic_error_category for
>>>> instead and it will make this code less friendly to header-only
>>> And even if the "same address" thing was solvable (which I think it
>>> is, although not pretty and it would require interface changes),
>>> there is the problem with unloading DLLs/SOs. You'd have to pin
>>> every module that contains error categories. Which IMO is a side
>>> effect that you really don't expect and want, especially from a
>>> header-only library.
>> How does libstdc++ (>= C++11) solve these problems?
> libstdc++ is not header-only, you link with libstdc++.so.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk