On 28.08.2015 13:42, Mathias Gaunard wrote:
Ion Gaztañaga
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, 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.
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.