Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

object create order

0 views
Skip to first unread message

Sten Larsson

unread,
Nov 6, 2004, 3:41:42 PM11/6/04
to
I have two classes:

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

Phil Staite

unread,
Nov 7, 2004, 8:03:23 PM11/7/04
to

You could do something like:

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.

Sten Larsson

unread,
Nov 7, 2004, 11:40:37 PM11/7/04
to
"Phil Staite" wrote:
>You could do something like:
>
>EventManager& getAManager() {
> static EventManager someManager;
> return someManager;
>}

Great idea... Thanks!

-sten

vavan

unread,
Nov 10, 2004, 6:21:55 AM11/10/04
to
On Sun, 07 Nov 2004 20:40:37 -0800, Sten Larsson <st...@Xstenl.com>
wrote:

>Great idea... Thanks!

beware MT problems...

--
Vladimir Ulchenko aka vavan

Sten Larsson

unread,
Nov 10, 2004, 2:55:16 PM11/10/04
to
On Wed, 10 Nov 2004 14:21:55 +0300, vavan <va...@santel.ru> wrote:

>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

Sten Larsson

unread,
Nov 10, 2004, 3:07:13 PM11/10/04
to
On Wed, 10 Nov 2004 11:55:16 -0800, Sten Larsson <st...@Xstenl.com>
wrote:

>>beware MT problems...
>
>Can you please tell me what "MT" is.

Multi Threading ?

-sten

Chris Uzdavinis

unread,
Nov 10, 2004, 5:43:21 PM11/10/04
to
Sten Larsson <st...@Xstenl.com> writes:

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);

Phil Staite

unread,
Nov 10, 2004, 9:55:32 PM11/10/04
to
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...

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 >

vavan

unread,
Nov 11, 2004, 2:18:16 AM11/11/04
to
On Wed, 10 Nov 2004 20:55:32 -0600, "Phil Staite"
<no....@not.a.chance> wrote:

>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 :)

see for example
http://groups.google.com/groups?hl=en&lr=&frame=right&rnum=21&thl=1270562856,1270562636,1270370451,1270368296,1270066062,1269815773,1269388368,1269119233,1268850512,1268850348,1268566741,1268260155&seekm=c29b5e33.0201301230.23319507%40posting.google.com#link26

>That kind of thing is best done by the main thread *before* it kicks off any
>additional threads.

agreed

Sten Larsson

unread,
Nov 11, 2004, 3:22:03 AM11/11/04
to
Chris Uzdavinis (TeamB) wrote:
>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.

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

Chris Uzdavinis

unread,
Nov 11, 2004, 6:44:35 AM11/11/04
to
Sten Larsson <st...@Xstenl.com> writes:

> 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);

0 new messages