Boost.Phoenix should not forward-declare std::unordered_set / map

[Jean-Michaël Celerier <jeanmichael.celerier@…>]

Boost 1.60 introduced the header boost/phoenix/stl/algorithm/detail/std_unordered_set_or_map_fwd.hpp.

When building on Linux with libstdc++ debug mode (-DGLIBCXX_DEBUG) this causes ambiguous references to the forward-declared classes because in libstdc++ side, they now live in the std::debug namespace instead.

The following test cases triggers it :

#include <boost/spirit/include/phoenix.hpp>
#include <unordered_map>

void f()
{
	std::unordered_map<int, float> map;
}

when built with

g++ -std=c++11 -D_GLIBCXX_DEBUG=1 -c problem.cpp

[Braden McDaniel <braden@…>]

There are other problems with this, as well, using gcc/libstdc++ (4.9, at least). For instance, this template specialization fails to compile if the problem Phoenix header gets included:

template <typename T, typename TypeT, typename KeyT, typename HashT, typename KeyEqualT, typename AllocatorT>
class foo<T, std::unordered_map<KeyT, TypeT, HashT, KeyEqualT, AllocatorT> >
{};

For the time being, I'm simply compiling my code with BOOST_PHOENIX_USING_LIBCPP defined, as this disables the forward declarations. But this is obviously undesirable if that macro ever gets used for something that is actually libc++-specific.

[Jean-Michaël Celerier]

Got another similar problem (in boost 1.60) in boost/phoenix/stl/algorithm/detail/is_unordered_set_or_map.hpp . The BOOST_PHOENIX_USING_LIBCPP trick seems to work however.

[Kohei Takahashi]

This should be fixed in 1.62 release (​https://github.com/boostorg/phoenix/pull/33).

[rogeeff@…]

This is still wrong. There is no legal way to forward declare std::unordered_set/std::unordered_map. According to the standard ([namespace.std]), these forward declarations have undefined behavior.

This need to change to

#include <unordered_map> #include <unordered_set>

[Kohei Takahashi]

OK, fwd-decl will be replaced with include by ​https://github.com/boostorg/phoenix/pull/54.