Boost logo

Boost :

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-07-10 09:57:30


On Jul 10, 2005, at 8:50 AM, David Abrahams wrote:
> Douglas Gregor <doug.gregor_at_[hidden]> writes:
>> The real color map will be built like this:
>>
>> typename graph_traits<Graph>::vertices_size_type n =
>> num_vertices(graph);
>> std::vector<default_color_type> color_vec(n);
>> iterator_property_map<
>> typename std::vector<default_color_type>::iterator, IndexMap
>>> default_color_map(color_vec.begin(), index_map);
>>
>> The really tough part is that color_vec needs to stick around, so it
>> can't be buried in a function object somewhere.
>
> Well, you can have it in a function object, as long as there's a way
> to retrieve it, or the function object outlives the function call.
> But more to the point, shouldn't it be part of the color_map itself?
> There's no rule that the color_map has to be a simple vector, is
> there?

No, color_map can be any property map from vertices to color values. We
just tend to build them as vectors because it's a convenient storage
mechanism.

>> An equivalent (but slightly simpler) alternative is to use:
>>
>> typename graph_traits<Graph>::vertices_size_type n =
>> num_vertices(graph);
>> vector_property_map<default_color_type, IndexMap>(n, index_map);
>
> Yes, that looks simpler, because it avoids the issue of holding onto a
> separate color_vec. Is there some downside?

There's a little more overhead to a vector_property_map than an
iterator_property_map<vector iterator, ...>, because the
vector_property_map goes through a shared_ptr. I don't know if it has a
measurable effect.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk