Ion Gaztañaga
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.