On Thu, 4 Mar 2010, Maxime van Noppen wrote:

On 03/04/2010 08:06 PM, Jeremiah Willcock wrote:

This is the same issue as variant actually -- the boost::get thing.  The
info object that is causing trouble in char.hpp contains a variant that
it's trying to get a field from.  It's too bad that a later library
(variant) reused a name from an earlier one (graph), but it's probably
too late to do anything about either one.

This seems quite critical to me. As the times goes, more and more boost
libraries might use variant and therefore become incompatible with
Boost.Graph. Wouldn't it be better to break backward compatibility for a
given release and solve this issue ? The backward compatibility is
already broken : our codebase compiles fine in Boost 1.39 and doesn't in
Boost 1.41 because of this issue.

I guess I don't know how many programs use boost::get from BGL as opposed to just get.  Users are supposed to use ADL to find get, at least in generic code, but it would still have to be in boost because that's where the graph types are.  Remember that BGL's get is part of a concept so it needs to be accessible using an unqualified name when called on a built-in graph type.  I don't see any obviously good ways to do this -- changing Variant would break more code but the fix would be simpler (since it's probably just a search-and-replace for boost::get< and get< since people won't use those syntaxes with BGL).  For BGL, it might be possible to move the built-in property names (and references to them would need to be fixed up), but that's a hack just to get an additional associated namespace for the built-in definitions of get().  The other fix would be to move the graph types, but that would require user code changes as well; there would also need to be a rule that graph types could not go in boost:: anymore. I added [variant] into the subject line so we can get the Variant developers in here and try to get this worked out -- it is going to be an increasing problem as you said.