Re: [Boost-users] Boost Graph: why can't get() take a const argument?

Subject: Re: [Boost-users] Boost Graph: why can't get() take a const argument?
From: Geoff Hilton (geoff.hilton_at_[hidden])
Date: 2010-05-04 10:57:38

On 04/05/2010 10:38 AM, Geoff Hilton wrote:
> On 03/05/2010 7:33 PM, Trevor Harmon wrote:
>> Hi,
>>
>> I have a question about line 54 of the canonical_ordering example:
>>
>> graph g(6);
>> ...
>> property_map<graph, edge_index_t>::type e_index = get(edge_index, g);
>>
>> If I'm reading the Boost source code correctly, the get function's graph
>> argument is declared const. This makes sense intuitively because, well,
>> why would the graph need to be modified in order to retrieve a property?
>> So the graph parameter passed to get() could be made const, correct?
>> Like this:
>>
>> graph g(6);
>> ...
>> const graph g2 = g;
>> property_map<graph, edge_index_t>::type e_index = get(edge_index, g2);
>>
>> However, the above change gives a compiler error:
>>
>> conversion from
>> ‘boost::adj_list_edge_property_map<boost::undirected_tag, int, const
>> int&, size_t, const boost::property<boost::edge_index_t, int,
>> boost::no_property>, boost::edge_index_t>’ to non-scalar type
>> ‘boost::adj_list_edge_property_map<boost::undirected_tag, int, int&,
>> size_t, boost::property<boost::edge_index_t, int, boost::no_property>,
>> boost::edge_index_t>’ requested
>>
>> Can anyone explain why? Thank you,
>>
>> Trevor
>
>
> I've run into this myself (and asked about it in this list somewhere as
> well), the short answer is that it's easier to simply pass in a
> non-const graph. I can't remember the long answer, but I believe it has
> to do with the implementation of property_map<..>::type and const_type
> and the property (eg. edge_index_t) template parameter. Note though that
> I could (and may well) be wrong.
>
> Geoff

I've double-checked and found the thread I was thinking of, search for 
messages containing the subject "[BGL] Bundled properties and property 
maps" that'll get you the thread, as well as "[BGL] A bug in const 
bundle_property_map or in Readable Property Map Concept?" though 
according to Andrew the issue in question was fixed in 1.40, so you 
might have found something new unless you're using a prior incarnation.