Boost logo

Boost :

From: Provisional Dissonance (prosonance_at_[hidden])
Date: 2004-04-02 06:48:28

>Yea, but first the original poster should indicate if
this is what he's
>looking for -- I never needed this myself.

What I was looking for, really, was dialog on existing
design strategies. It sounds like your issues with
property maps mirror my confusion with the library
design, though. While I can fully appreciate the
desire to write generic code, it feels like BGL has
pushed the complexity of creating and enforcing
coupling between the generic
graph/node/visitor/algorithm/etc onto the client. At
a basic conceptual level, I think of a graph as a data
structure composed of nodes and edges. If I'm
modeling a family tree, I expect the nodes to be
objects of some family-member class. C++ exposes many
robust and elegant methods for modeling the
family-member - why should I, as a client, have to use
property-maps at all? If the node's "index" is
related to the object, why would it not be a natural
member of the node-type's class? If, instead, it is a
synthesized construct for communication between a
graph and the algorithm operating over it, why should
the client be responsible for its maintenance instead
of the framework? What are the advantages of this
approach? What are the disadvantages of simplifying
things for the client? This is the type of design
issue that I intended to question with my initial


Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway

Boost list run by bdawes at, gregod at, cpdaniel at, john at