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;
plug system ?
Author
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 :
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]
Author
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.
It seems that the "observer" design pattern is exactly what I'm looking for.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
