From: vladimir josef sykora (vladimir.sykora_at_[hidden])
Date: 2003-02-13 09:18:29
> > I'm using customized-internal properties that do not have 'color'
> > information. Now, algorithms (undirected_dfs() for example) need to map
> > each vertex and edge to its respective color, so in the previous case,
> > maps must be passed as arguments to the algorithms (OTOH, if I were
> > color_maps for both vertex and edge internal properties, the
> > bgl_named_params<> version of the function would do the job, and I
> > care about the mapping.) That's what I meant when I said that having
> > internal properties requires the mapping .
> Understood. You can't attach vertex_color like adjacency_list class
No, because that template parameter was already taken by my custom-property.
> > You're right. Did you overload add_vertex() and/or add_edge() functions
> > receive the 'property' container or a std::back_insert_iterator
> > to the prop. cont.)?
> No, I've made the  method of property map resize the underlying vector
> index is out of range. Quite simple.
That'll be for vertex_map. If one's using std::map<> as the edge-color-map,
no more actions are needed because the value is simply stored in the map if
the key doesn't exist.
> Rereading my sentence, I understand that is was poorly worded. I meant
> should be able to create, for every kind of graph, external property map
> will work without requiring me to manually assign indices.
That'd be nice!
> > >Specifically, for all graphs both vertex_descriptor and
> > > edge_descriptor should be comparable, so that you can use map
> > Can you tell me more about this? AFAIK, vertex_descriptor is of type
> > (vecS) and edge_descriptor is of type ::boost::detail::edge_base<>.
> I meant that
> std::map< typename graph_traits<G>::vertex_descriptor>, int>
> std::map< typename graph_traits<G>::edge_descriptor>, int>
Is here 'int' the index of the vertex/edge container?
> should always work, regardless of the type 'G'. size_t will work now
> inefficient). But edge_base<> is not comparable, so it won't work. I think
> it should have operator<
That would be nice. Then I could create a map like: std::map<typename
graph_traits<G>::edge_descriptor, default_color_type> as an external
edge-color-map, without the need of put() and get() overloading. I think
that's the best solution!
Specifically, if line 688 of boost/boost/graph/detail/adjacency_list.hpp
would have returned :
this->m_source < other.m_source || (!(other.m_source < this->m_source) &&
this->m_target < other.m_target), then edge mapping would have been simpler.
> I think that edge_descriptor should contain edge index inside it. When you
> create new edge, the next free index is allocated from a list of free
> (or num_edges(g) is used). When you delete edge, it's index is added to
> the list of free indices. This design requires one extra int per edge,
> the store of free indices --- the max number of edges graph ever had,
> in the worsts case, but probably quite little in practice.
What's the advantage to have an edge-index stored? The only one that comes
to my mind is to use it as edge-container index; however, if this is the
case, all indeces should be updated every time an edge is added or deleted.
> > > In both cases, you should be able to write
> > >
> > > edge_property_map<G, int>::type pm;
> > >
> > > and have it work. What do you think?
> > AFAIK, that's for internal properties. Please correct me if I'm wrong.
> I don't know what this syntax does now :-) I mean that this or similiar
> should be used to find the type suitable for external property map.
> > > I think that external property maps should be improved, like I
> > above
> > > or it some other way. It hits me quite often.
> > I guess you're refering to the documentation; if that's the case, I
> Documentation hits me too. But I would also like to be able to provide
> external properties for edges easily.
> - Volodya
> Unsubscribe & other changes:
vladimir josef sykora
gmunder str. 37-37a
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk