envire / envire-envire_core

Core part for the Environment Representation library
BSD 2-Clause "Simplified" License
7 stars 13 forks source link

Access control of GraphBase::_map - how can this work? #46

Closed HWiese1980 closed 5 years ago

HWiese1980 commented 5 years ago

https://github.com/envire/envire-envire_core/blob/b4f2f97d7040179f8ff96b5111519e5fa7ed7db6/src/graph/Graph.hpp#L315

In this line there's the field _map which is marked protected, however in boost::labeled_graph this field is marked private ever since at least Boost 1.46 (if not even older versions). Compiling my code together with this does not work. I'm getting

error: ‘boost::labeled_graph<boost::directed_graph<envire::core::Frame, envire::core::Transform, envire::core::Environment>, std::__cxx11::basic_string<char>, boost::defaultS>::map_type boost::labeled_graph<boost::directed_graph<envire::core::Frame, envire::core::Transform, envire::core::Environment>, std::__cxx11::basic_string<char>, boost::defaultS>::_map’ is private
     map_type _map;

How has this ever worked?

arneboe commented 5 years ago

This is a more complex problem, I ll try to explain as best as I remember.

There is a bug in labeld_graph. When removing vertices by label the label is not removed from the label map (see https://svn.boost.org/trac/boost/ticket/9493). We work around this bug by manually removing the label from _map.. To gain access to _map we do the following in GraphTypes.hpp.

  #define private protected
  #include <boost/graph/labeled_graph.hpp>
  #undef private

Thus as long as you include GraphTypes.hpp first, everything should work as expected. Can you post the complete compile error including the include chain? Maybe the chain is broken somewhere and labeled_graph is included before GraphTypes.'

This is a nasty workaround and I was hoping that the bug in boost was fixed but so far the bug has not been fixed.

HWiese1980 commented 5 years ago

Witchcraft!!! :-D

Okay, I see. I'm at home already, I hope that I can double-check tomorrow.

Is the bug still present in Boost 1.69 though?

arneboe commented 5 years ago

As far as I see the bug is still present in the current boost version. Maybe we should just fix it and create a PR?

arneboe commented 5 years ago

I opened an Issue on the boost graph github: https://github.com/boostorg/graph/issues/167

HWiese1980 commented 5 years ago

Okay... I'm curious to see what's coming out of this. :+1:

I'll close this issue as it's clearly not our fault.

... oh, and because the workaround (header loading order) works.

anadon commented 5 years ago

I'll check it out. Thanks for letting us know.

arneboe commented 5 years ago

Wow, that's a nice surprise. Thanks for taking a look