Sign in to follow this  
paic

plug system ?

Recommended Posts

Hi, I don't know if the term is correctly chosen, but I need to create a sort of "plug" system. What I mean is that in some classes, I want some member variables to be able to be "watched" by another part of the program. BUT I also need the "watcher" to know when the "watched" instance is destroyed ... for example :
class Material
{
    // ...

    Color diffuse;
};

// in another part of the program, I'd like to do something like :
Material * material = new Material;
Plug < Color > diffuse = material->GetPlug("diffuse");

// I'd like to be able to do the following :
// - Use diffuse like a Color via -> operator overriding, or anything else.
//   And if material->diffuse is changed, then diffuse will also change.
// - Know if the watched variable still is valid.
if (diffuse.Valid())
    std::cout << diffuse->R << std::endl;
else
    std::cout << "watched member variable doesn't exist anymore" << std::endl;


I'm pretty sure someone already solved that problem and a solution exists, but the one I'm currently using is not good (it has bugs if you destroy the Plug instance before the Material instance for instance) and I can't find anyway to achieve my goal ... Maybe one of the boost library could be of use ? or a design pattern ? Thx for any help ! [Edited by - paic on February 22, 2008 9:18:30 AM]

Share this post


Link to post
Share on other sites
You will however soon find that this carries large overhead, since you need to have these two mutually watchable.

A watches B. When A is destroyed, it needs to notify all Bs.

But at same time, A needs to be aware of when B stops watching, so that it can remove it from update list.

Thus, for each property you want watched, you'll need 2 sets of mutual references, which may mean considerable memory footprint (2x set of vectors means 32 + 2x n bytes overhead per property).

Things get even worse once you try to make this usable, when you realize you may need a large number of interfaces, or implied inheritance.

There's also a typical speed vs. memory overhead. If these updates will be frequent, you need the notification to be fast. You could however have a single notifier, through which all notification registration goes through. That does require you to search through lists on every update.

Last problem is that while you're iterating through the update lists, you may inadvertently modify the list you're iterating over.

From implementation perspective, set is most natural data structure, but list is most reliable implementation-wise.

Simply put - lots of gotchas.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this