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: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-04 16:33:58

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.

>   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.

In Christ,
Steven Watanabe