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

[HWiese1980]

envire-envire_core/src/graph/Graph.hpp

Line 315 in b4f2f97

using GraphBase<FRAME_PROP, EDGE_PROP>::_map;

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]

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]

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]

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]

I opened an Issue on the boost graph github:
boostorg/graph#167

[HWiese1980]

Okay... I'm curious to see what's coming out of this. 👍

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

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

[anadon]

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

[arneboe]

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