Event Manager
Event Receiver
I want event receivers to register themselves at the event manager
when created.
However, that requires the Event Manager to be crated before the event
receivers are created.
I anticipate ONE global Event Manager object, though it would be
preferrable if it is possible to use multiple event managers. But for
now, I anticipate Event Receivers to access one global Event Manager.
The solution that I'm thinking of is to access the Event Manager
instance through a function call - i.e.
EventManager()->Register(this);
Where the EventManager() function will dynamically create the instance
when needed.
(I will probably use this model for TForms too - speed up start time
by creating them when needed, and potentially delete them when
closed.)
Any thoughts?
Thanks!
-sten
EventManager& getAManager() {
static EventManager someManager;
return someManager;
}
The nice thing here is that someObject is only created when needed, the
first time the function is called.
Great idea... Thanks!
-sten
>Great idea... Thanks!
beware MT problems...
--
Vladimir Ulchenko aka vavan
>On Sun, 07 Nov 2004 20:40:37 -0800, Sten Larsson <st...@Xstenl.com>
>wrote:
>
>>Great idea... Thanks!
>
>beware MT problems...
Can you please tell me what "MT" is.
Thanks!
.sten
Multi Threading ?
-sten
Yes. Static local variables of functions are not protected, and are
constructed the first invocation. If two threads both call the same
function at the same time, then the single static member could be
constructed multiple times. If that's not bad enough, at program
shutdown, it could get multiply destroyed, depending on how that gets
setup, which may (should) crash your program.
--
Chris (TeamB);
Of course, to make it thread safe you'd need some kind of lock to control
access. Of course, that lock would have to be created and initialized
before anyone tried to use it... Hmm, kind of the same problem the OP was
looking at...
That kind of thing is best done by the main thread *before* it kicks off any
additional threads.
"Chris Uzdavinis (TeamB)" <ch...@uzdavinis.com> wrote in message >
>Yep, never intended to be thread-safe.
>
>Of course, to make it thread safe you'd need some kind of lock to control
>access. Of course, that lock would have to be created and initialized
>before anyone tried to use it... Hmm, kind of the same problem the OP was
>looking at...
which is discussed _many_ times in comp.programming.threads :)
>That kind of thing is best done by the main thread *before* it kicks off any
>additional threads.
agreed
Yes - I know... I just want to use some trick to guarantee that
objects exist when I need them too. As far as I remember, with these
global objects:
string a;
string b;
There is really no way of knowing if a or b is created first (by
reading the C++ standard), and this pretty much happens before the
main thread kicks in (well, at least before main() is called.
Creating the objec using "new" instead of a local static wouldn't
really improve things... right? I'm sure it would be a different error
behaviour instead.
Thanks!.
-sten
> Yes - I know... I just want to use some trick to guarantee that
> objects exist when I need them too. As far as I remember, with these
> global objects:
>
> string a;
> string b;
>
> There is really no way of knowing if a or b is created first (by
> reading the C++ standard), and this pretty much happens before the
> main thread kicks in (well, at least before main() is called.
If they are declared in the same source file, then their
initialization order is guaranteed to be in order of declaration. If
they're declared in different source files that are later linked
together, then the order of initialization is indeterminate.
> Creating the objec using "new" instead of a local static wouldn't
> really improve things... right? I'm sure it would be a different error
> behaviour instead.
Actually it can help. The much-maligned "singleton" pattern can help
with order-of-initialization problems, by creating the object on an
as-needed basis. Thus, if we're creating singleton A and it uses
singleton B in its constructor, then creation A waits for the creation
of B to complete, and then A's construction continues, and so on.
One big problem of singleton pattern is cyclic dependencies, and if
you have a maze of different variables all initialized in different
files who all make use of each other, most likely it'll still fail,
because one singleton may make use of another singleton that is still
in the process of constructing, but that would cause another instance
to begin constructing, potentially creating an infinite recursive loop
until the program crashes. Cyclic-dependencies are not a problem
specific to singletons at all, though. It's just that singletons do
not help solve that problem.
Another problem with singletons is initialization in multi-threaded
applications is nearly impossible to do safely if you allow threads to
begin running before main (such as spawning them from the constructor
of a global variable.) Double-checked locking attempts to help solve
the initialization problem in multiple threads in an efficient manner,
but has been shown to not work as well as desired.
--
Chris (TeamB);