Boost logo

Boost :

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>> 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,
> <>
> 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
> - 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at