On Thu, 14 Jan 2010, Maxime van Noppen wrote:

Hi,

I recently upgraded the boost version used four our project from boost 1.39 to boost 1.41 and encountered a very strange compilation error. I managed to reduce the problem to this minimal test case :

----------var.cc--------------- #include #include

int main() { boost::variant v;

boost::get<int>(v); } ----------------------------

This doesn't compile on Linux 64bits with gcc 4.4.2 20091208 and produces this error message :

----------------------------

...

In file included from /usr/include/boost/graph/graph_concepts.hpp:17, from /usr/include/boost/graph/breadth_first_search.hpp:21, from var.cc:2: /usr/include/boost/property_map/property_map.hpp: In instantiation of ‘boost::property_traits<int>’: /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from ‘boost::two_bit_color_map<int>’ var.cc:8: instantiated from here /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is not a class, struct, or union type /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is not a class, struct, or union type /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is not a class, struct, or union type /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is not a class, struct, or union type

---

Could there be a conflict between boost.variant and boost.graph or did I miss something ?

Yes, there is a conflict like you said. Both libraries define boost::get, and Variant's non-deducible template parameter makes the normal overload resolution mechanisms in C++ fail. I do not have a good workaround for that; BGL's get might be safe to have in a nested namespace since it's not supposed to be called qualified AFAIK, but people are likely to be calling it that way. -- Jeremiah Willcock