On 16 Feb 2011, at 13:44, Daniel James wrote:
On 16 February 2011 13:13, Christopher Jefferson <chris@bubblescope.net> 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