Re: Association Library?

From: rzako23 (rzako_at_[hidden])
Date: 2002-05-04 23:28:48

Thank you to everyone for your interest and suggestions.

Following are specific responses to recent postings.

Rob Zako

--- In Boost-Users_at_y... #683, Jeff Garland <jeff_at_c...> wrote:

> Read this page :-)
> 
> http://www.boost.org/more/submission_process.htm

Thanks, Jeff!

I believe my next step is to subscribe to the Boost mailing list and
learn more about Boost before I try to add anything myself.

Once I feel confident enough, I will continue a more technical version
of this discussion on that list.

--- In Boost-Users_at_y... #684, Craig Hicks <hicks_at_k...> wrote:

> Actually, such a functionality does exist in Boost.
> That is because an arbitrary many-to-many mapping with per-node
> and per-edge data can be represented by a graph which stores
> per-node and per-edge data.

Yes, Craig, I have looked quite a bit at the Boost Graph Library.
A lot of thought has gone into this library and it is very general.

But I thought that a graph can represent only an association between
a class and itself, not between two distinct classes. Am I missing
something here?

--- In Boost-Users_at_y... #719, Paul Dubuc <pdubuc_at_c...> wrote:

> I liked the non-intrusive feature.  Perhaps better performance could
> be achieved by replacing the multimaps with sorted vectors following
> Scott Meyers' advice in Item 23 of this book "Effective STL".

Paul, I like the non-intrusive feature, too. My point is that whether
or not an association is represented with an intrusive or non-intrusive
data structure should be an implementation detail, not a fundamental
choice.

What I'd like to see is a standard interface (much like the Boost Graph
Library provides a standard interface) for dealing with associations.
I envision this being done by defining an Association concept. Then
different specific classes can realize the Association concept in
different ways. But client code need not know which implementation is
being used, just so long as the client code assumes only the
requirements of the Association.

In particular, the distinction between an intrusive and a non-intrusive
association should be transparent to client code, and should require
modifying but a few lines of code for the involved classes.