On Oct 29, 2005, at 3:57 PM, Adam D. Bradley wrote: > Then we should probably fix the docs in cssysdef.h, which call it a > global without blushing: > /**\def CS_IMPLEMENT_STATIC_VAR(getterFunc,Type,initParam,kill_how) > * Create a global variable thats created on demand. Create a Getter > function Done. > Reasonable enough. I'm going to guess that there's no easy way to > get a pointer to the "current" iObjectRegistry without having to > pass it around as an argument (what does "current" mean, anyway)... > so I suppose I'll need to add a csEventNameRegistry::Initialize > (iObjectRegistry *) to get this all set up properly. The architecture was designed such that it should be possible to create multiple "instances" of the entire CS environment, with each environment hanging off of an iObjectRegistry (which you can view as the root of a tree out of which the CS environment grows). For this reason, there is no single, global iObjectRegistry. Instead, you either pass around iObjectRegistry pointers, or store a pointer in your objects at or near the time they are created. This is also the reason that we eschew global and module-static variables; since they usually interfere with the ability to have multiple CS environments (each hanging off its own iObjectRegistry). A better approach is to store your "static" or "global" or "shared" data in some object which is referenced by the iObjectRegistry.
I was hoping this kind of thing would be caught in the several drafts of the patch I sent to the list :-)
Okay, I think I see a way to make the name registries work without having to have iObjectRegistry* passed around to every place an event name is referenced, but this delays my check-in by a few more days...
Adam
|
-- Adam D. Bradley <[EMAIL PROTECTED]> Boston University Dept. of Computer Science |
signature.asc
Description: This is a digitally signed message part
