...

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 value): - callbacks when a data value is updated (methods or functions) (not using boost::signals, but it probably could) - checks that a data value is consistent (i.e. within the correct range) 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 problem. 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 repository.) Jeremy Pack