[BGL] property tag classes and "num"
From http://www.boost.org/libs/graph/doc/using_adjacency_list.html#sec:adjacency-...: | Custom Edge Properties | | Creating your own property types and properties is easy; just define a | tag class for your new property. The property tag class will need to | define num with a unique integer ID, and kind which should be either | edge_property_tag, vertex_property_tag, or graph_property_tag. | | struct flow_t { | typedef edge_property_tag kind; | }; | | struct capacity_t { | typedef edge_property_tag kind; | }; It works with structs like this. Am I missing something, or where is "num"?
On Monday 29 May 2006 05:20, Jens Müller wrote:
Am I missing something, or where is "num"?
No, you're not missing anything. I think that part of the documentation is a
relic from an older version of BGL. If you look in graph/properties.hpp, the
property tags are defined like
namespace boost {
enum edge_weight_t { edge_weight };
template<>
struct property_kind
Daniel Mitchell schrieb:
On Monday 29 May 2006 05:20, Jens Müller wrote:
Am I missing something, or where is "num"?
No, you're not missing anything. I think that part of the documentation is a relic from an older version of BGL. If you look in graph/properties.hpp, the property tags are defined like
namespace boost { enum edge_weight_t { edge_weight };
template<> struct property_kind
{ typedef edge_property_tag type; }; } As you can see, there's no reference to "num."
OK ... I used something like I quoted from the docs (struct with only a type), and then used a default-constructed value (my_property_t()) to access the map. Is that "worse style" than the one currently employed in the lib? Is constructing/passing a struct with no data members more efficient than it is with an enum, or is there no difference?
On Monday 29 May 2006 13:42, Jens Müller wrote:
I used something like I quoted from the docs (struct with only a type), and then used a default-constructed value (my_property_t()) to access the map.
Is that "worse style" than the one currently employed in the lib?
I guess that's a matter of opinion. Personally, I don't see it as worse style.
Is constructing/passing a struct with no data members more efficient than it is with an enum, or is there no difference?
I don't know, but I would bet that the difference--it it exists at all--is negligible. Ideally the compiler will elide the struct/enum object altogether, since it's only the type that's important. D.
Daniel Mitchell schrieb:
Is constructing/passing a struct with no data members more efficient than it is with an enum, or is there no difference?
I don't know, but I would bet that the difference--it it exists at all--is negligible. Ideally the compiler will elide the struct/enum object altogether, since it's only the type that's important.
Yeah, shortly after my post I realized that optimizing away the value is quite trivially achieved - if the function is inlined, the value is dead anyway, if it isn't, the compiler might still find out by interprocedural analysis. Thanks a lot!
participants (2)
-
Daniel Mitchell -
Jens Müller