Boost logo

Boost :

From: Jeremy Pack (Jeremy.Pack_at_[hidden])
Date: 2006-08-28 18:55:52

> > The other library is used as a repository for variables of any type.

> > It
> > includes the following (each of the following is optional for each
> > - callbacks when a data value is updated (methods or functions) (not
> > boost::signals, but it probably could)
> > - checks that a data value is consistent (i.e. within the correct
> > when it is updated
> > - mutexes for data access
> > - useable (though not yet completed) in a distributed environment
> Not aware of anything like this, but not sure I'm getting it...maybe
> an
> example would help?

The purpose of this library is to decrease the amount of coupling
between classes.

Suppose that we were modeling the following scenario in software:

In a certain project group, the project leader decides each week the
time of the next meeting and the topics to discuss. Each member of the
team must get this information. Here are a few solutions:

1 - Each team member must ask the project leader to get the details.
2 - Each team member must ask the project leader or another team member
to get the details.
3 - The project leader sends a message to each team member.
4 - The project leader posts the information in a common location (on a
website or bulletin board).

In software, the equivalent would be:

1 - Classes: team_member, project_leader. The project_leader class has
two methods called get_next_meeting_time and get_next_meeting_topics.
The team_member objects must have a reference to the project_leader
object in order to call the functions. (naturally, there are more ways
to implement this - I just mention the way that is most obvious to me)

2 - Same classes, similar to the first, but now each team_member must
also implement the methods get_next_meeting_time and
get_next_meeting_topics. Each may have references to other team_member
objects who can be queried.

3 - The project_leader must have a reference to each team_member.

4 - The project_leader has a reference to a repository, as does each
team_member. The project_leader places the information in the
repository, where the team members can retrieve it.

Naturally, each of these methods has advantages and disadvantages, and
the actual implementation chosen depends on the other particulars of the

My library provides a simple mechanism for implementing option 4. Option
4 certainly has some disadvantages in this situation, but it has one
strong advantage:

The team_members are not dependent on the project_leader - they are
depending on the information in the repository. The situation could be
changed so that a certain team_member, or a higher level manager placed
the information in the repository, and the team_member class would not
need to be modified, as long as the meeting information structure was
the same.

As I've designed it so far, the library has the following features:

-Data in the repository is indexed by strings

-Type-safe (type-safety across shared libraries may not work on all
platforms, because of usage of RTTI. If I work to have this library
reviewed for boost, this will need to be discussed)

-Thread-safety can be built into a variable in the repository (using
boost.threads, variables can make automatic use of mutexes and such)

-Functions or functors can be used to verify that each data item in the
repository stays in a consistent state (for instance, the repository can
check that a number does not leave a certain range).

-A function or list of functions can be called when a value is updated -
this can be used to implement the Observer pattern. Note that this could
be used to provide for distributed repositories.

Also, I didn't mention that the other library for creating plug-ins
depends on this library. Each class that is a plug-in or extension
accepts as a constructor parameter a reference to the repository that it
should pull shared data from. (basically it makes it possible to send
arguments to the constructor without knowing exactly what the
constructor will need - it just pulls needed values from the

Jeremy Pack

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