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 16:49:51

On Thu, 4 Mar 2010, Steven Watanabe wrote:

> Jeremiah Willcock wrote:
>> On Thu, 4 Mar 2010, Steven Watanabe wrote:
>> 
>>> AMDG
>>> 
>>> Jeremiah Willcock wrote:
>>>> 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.
>>> 
>>> SFINAE doesn't apply for this overload of get.
>> 
>> OK -- I see that it's really the reference to the member type key_type 
>> that's causing the class to be instantiated, which is not a SFINAE error.
>> 
>>>> 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.
>>> 
>>> Property maps that use put_get_helper seem to be okay.
>> 
>> Yes -- that uses two template parameters.
>
> Actually with
> template <class PropertyMap, class Reference, class K>
> inline Reference
> get(const put_get_helper<Reference, PropertyMap>& pa, const K& k)
> You should never get an error, since there are no templates that
> the compiler could errantly try to instantiate.

Yes -- I think the member type is the issue.

>>   There are only a few other places that need to be changed:
>> 
>> one_bit_color_map.hpp (a copy of the two-bit one)
>> csr_vertex_local_map in distributed/compressed_sparse_row_graph.hpp
>> the Stanford GraphBase interface
>> A few property maps in distributed/adjacency_list.hpp
>> 
>> Should I just go ahead and do those?  I do not know if your key_type thing 
>> will work in some of the other places -- the compiler seems sensitive to 
>> that.
>
> I'm somewhat nervous about my patch, since it was just a quick hack
> to see what was possible.  I'd much rather adjust the definition
> of get so that it can't cause an error just by being the the overload set.

I looked at changing the key_type in get to something that would SFINAE 
out and there isn't one: the farthest I could go is 
property_traits<IndexMap>::value_type (key_type in the code is a bug), and 
that class will fail to instantiate (non-SFINAE) on bad index map types. 
That can be specialized, so I can't fall back to the default definition of 
value_type inside it.  I don't see a general-purpose solution to problem 
right now.

-- Jeremiah Willcock