🚀 go-pugleaf

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.

"Phil Staite" wrote:
>You could do something like:
>
>EventManager& getAManager() {
>  static EventManager someManager;
>  return someManager;
>}

Great idea... Thanks!

-sten

On Sun, 07 Nov 2004 20:40:37 -0800, Sten Larsson <stenX@Xstenl.com>
wrote:

>Great idea... Thanks!

beware MT problems...

--
Vladimir Ulchenko aka vavan

On Wed, 10 Nov 2004 14:21:55 +0300, vavan <vavan@santel.ru> wrote:

>On Sun, 07 Nov 2004 20:40:37 -0800, Sten Larsson <stenX@Xstenl.com>
>wrote:
>
>>Great idea... Thanks!
>
>beware MT problems...

Can you please tell me what "MT" is.

Thanks!
.sten

On Wed, 10 Nov 2004 11:55:16 -0800, Sten Larsson <stenX@Xstenl.com>
wrote:
>>beware MT problems...
>
>Can you please tell me what "MT" is.

Multi Threading ?

-sten

Sten Larsson <stenX@Xstenl.com> writes:

> On Wed, 10 Nov 2004 11:55:16 -0800, Sten Larsson <stenX@Xstenl.com>
> wrote:
>>>beware MT problems...
>>
>>Can you please tell me what "MT" is.
>
> Multi Threading ?

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

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)" <chris@uzdavinis.com> wrote in message >
> 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);

On Wed, 10 Nov 2004 20:55:32 -0600, "Phil Staite"
<no.spam@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

--
Vladimir Ulchenko aka vavan

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

Sten Larsson <stenX@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);