Re: [boost] Feature macro for putting things in the std namespace

Subject: Re: [boost] Feature macro for putting things in the std namespace
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-08-28 07:06:18

On 28.08.2015 13:42, Mathias Gaunard wrote:
> Ion Gaztañaga <igaztanaga <at> gmail.com> writes:
>
>
>> I think many boosters will be against Boost.Container practice, but I
>> would prefer fixing this supporting more standard libraries, just
>> including headers looking for forward declarations is really
>> heavyweight. A new standard library or new name versioning is not
>> something that happens every day.
>
> As I said, the standard library in question has different symbols in
> different namespaces, it is not just versioning.
> allocator, less, char_traits, insert_iterator are in ::std::native_std,
> and put into std through 'using', but pair is directly in ::std.
> The exact behaviour possibly depends on a variety of settings as well,
> for example the symbols might be iin ::std::native_std::version_id, so
> the actual logic to deduce which symbol is defined where is not trivial.
>
> Since this is allowed by the C++ standard, I think Boost should follow
> the safe route here, and simply have a fallback where it includes the
> right headers if it doesn't know the location of each symbol.
>
> After all it's just a compile-time optimization, it's all nice and good
> if you want to have that optimization for libstdc++ and libc++, but it
> would be better to have the library at least work with other standard-
> conforming standard libraries rather than break because of some non-
> essential optimization.
>
> I actually found another thread about this subject from 2011,
> <http://lists.boost.org/Archives/boost/2011/02/177218.php>
>
> The person suggested a BOOST_NO_FWD_STD_DECLARATION feature macro as
> well, but that wasn't implemented.
>
> I know of the following:
>   - most of Ion's libraries (intrusive, interprocess, container), do some
> std forward declaring
>   - there is a boost/detail/container_fwd.hpp, used by boost hash, which
> also forwards standard containers, though it can be disabled with
> BOOST_DETAIL_NO_CONTAINER_FWD.
>   - flyweight uses the following logic: if libc++, include headers,
> otherwise, forward-declare.
>
>> Of course, it would be even better if we could add a std forward
>> declaration library or utility to Boost that could be even updated
> with
>> standard library maintainers that want to contribute.
>
> That would be good, but that's more work, and we're likely to get tied
> up in the details due to the different needs of the various boost
> authors, as happened in the previous thread.
>
> Therefore I suggest a feature macro that, if not defined, means that the
> library author should include the header rather than try to forward
> declare, and enforce that the various headers that do forward
> declarations respect it.

I think BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE, as you described it, would 
be mostly useless in the modern C++. libc++ already uses inline 
namespace and I suspect libstdc++ with gcc 5+ is also using some 
namespace versioning (I didn't check though). So most of the time the 
macro won't be defined.

Then if a library author is willing to support STL implementations with 
namespace versioning he will have to act despite that 
BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE is not defined and still rely on 
STL-specific macros to detect the implementation. This is no better than 
what is done currently.

I agree that a better solution would be a standard forwarding library. 
boost/detail/container_fwd.hpp and other libraries could then be ported 
to it. This library then could fall back to including the STL headers 
and have the equivalent of BOOST_DETAIL_NO_CONTAINER_FWD.

If this is too much of a work for you then I think it's better to 
maintain the status quo, i.e. patch the affected places to include 
awareness of the BSL.