Re: [boost] [config] request for BOOST_NO_FWD_STD_DECLARATION

Subject: Re: [boost] [config] request for BOOST_NO_FWD_STD_DECLARATION
From: Christopher Jefferson (chris_at_[hidden])
Date: 2011-02-16 09:36:02

On 16 Feb 2011, at 13:44, Daniel James wrote:

> On 16 February 2011 13:13, Christopher Jefferson <chris_at_[hidden]> wrote:
>> 
>> I would be happy with that, except I note that (for example) boost fusion currently unconditionally forward declares std::pair, and every compiler in the regression test (except clang with libc++) passes the std_pair test. Therefore the macro would have to be added to every other compiler, else they would become less efficent.
> 
> Codegear fails the test. Bit you can't extrapolate from std::pair to
> the containers, since they often have alternative implementations
> (e.g. gcc's debug and parallel versions). My plan is to change
> container_fwd to not forward declare by default, and add a test to
> check for setups where it's possible to forward declare but I'm not
> doing it.
> 
> Foward declaring std::pair is usually a little pointless anyway, since
> config includes utility for most libraries. I know I do it, I only
> just realised.

Problems I am currently aware of:

detail/container_fwd.hpp has a huge list of special cases already. These could be folded into a new macro definition

boost/interprocess/containers/container/container_fwd.hpp has forward definitions for a few standard library types, currently unconditionally.
boost/interprocess/interprocess_fwd.hpp has the same forward declarations.

boost/fusion/adapted/std_pair.hpp forward defines std::pair.

There are a bunch of other abuses of std in boost (mainly injecting names into std), but they are a different problem, and not currently causing any issues.

So, the obvious steps are:

introduce BOOST_ALLOW_FORWARD_STD (?) and use it to wrap all the above includes.

Looking at the current top of container_fwd.hpp:

#if defined(BOOST_DETAIL_NO_CONTAINER_FWD) \
    || ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) \
        && (defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PARALLEL))) \
    || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \
    || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \
    || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) 

Note that BOOST_DETAIL_NO_CONTAINER_FWD seems to be a macro for testing, not one to be set.

Probably push all those current bits into the appropriate compiler / library headers.

This would mean that we would stop the forward declarations in fusion and interprocess whenever any of the above macros are defined, but that might be a good idea anyway.

I'm happy to try to put together the necessary config changes for this, I just wanted to discuss it because it is poking at a large range of compilers and libraries, not just a few #ifdefs for libc++ anymore.

Chris