• Advertisement
Sign in to follow this  

plug system ?

This topic is 3678 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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;
    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
Ok, I just used the incorrect words when I searched for a solution ...
It seems that the "observer" design pattern is exactly what I'm looking for.

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
Sign in to follow this  

  • Advertisement