Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?

Subject: Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2010-03-04 15:30:56

On Thu, 4 Mar 2010, Steven Watanabe wrote:

> AMDG
>
> Jeremiah Willcock wrote:
>> 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.
>
> Do you know which BGL overload of get is triggering this?
> IMHO, the graph library should not globally reserve a common
> name like get.  Variant's overloads are well behaved, (they
> should never match anything except a variant and will not
> cause an error when they don't match.)

There are a lot of BGL overloads of get; it is intended to be found by 
ADL, and there's (at least) one definition for each graph type.  The graph 
library's get has been around for a while.  It is not globally reserved, 
at least not technically; it only applies to known graph and property map 
types, just like variant's.  The problem is that variant's get takes 
explicit template arguments and that seems to make the overloading work 
incorrectly.  I suspect that the error in this thread, for example, is 
coming from the boost::get version for two_bit_color_map; that function is 
restricted to work on only that property map type but instantiating its 
signature appears to be failing without SFINAE because of the explicit 
template argument.  I think this is something that's fixed in C++0x but 
that doesn't help us now.  Your workaround might fix the common cases 
though (since the compiler seems to differentiate functions based on the 
number of template arguments given); for some reason, the extra template 
argument in ::key_type is important in that definition of get.  It will be 
annoying to have to work around this issue repeatedly, though.

-- Jeremiah Willcock