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

Subject: Re: [boost] Feature macro for putting things in the std namespace
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2015-08-28 10:06:17

Andrey Semashev <andrey.semashev <at> gmail.com> writes:

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

As soon as it happens, some Boost code here and there will break and 
need to be changed, since libc++ is currently the only stdlib out of the 
10 supported ones that do it, and is special-cased in various places.

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

The point of the feature macro would be to make it slightly easier on 
the library developer, which will not have to enumerate all library 
implementations that support forward-declaring things in the std 
namespace, namely:
 - libstdc++ up to a certain version
 - stlport
 - Comeau
 - Roguewave
 - SGI
 - Metrowerks
 - VACPP
 - Modena
 - Dinkumware

Any other library would either have to be special cased or to include 
headers directly.

While this is a hack and not a defect, it's supported by 90% of the 
supported libraries, so having a feature macro makes sense to me.
I think it should be a BOOST_HAS_, rather than a BOOST_NO_, since it's 
not a defect, but a "feature".

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

This can be done in the longer term, but I think a feature macro is an 
easier way to solve the problem in the short term.