> "Ole Reinartz" <ole.reinartz@gmx.de> wrote:
> > Foo & Foo::instance()
> > {
> >     static Foo instance;
> >     return instance;
> > }
> >
> > This way your Foo singleton instance will be created the first time
> > Foo::instance() gets called to. It is not guaranteed that it exists before
> > main() gets executed, but it is guaranteed that it exists after someone
>  called
> > for it.

"Tzvetan Mikov" <ceco@jupiter.com> wrote:
> This isn't thread safe, so it is not exactly the same thing as having a
> global object initialized on program startup. This is OK in some situations,
> but could create a terrible, almost untrackable bug in a multithread
> application.

A very simple work-around: the first line of main() should read:
    Foo::instance(); // Create Foo singleton

The assumption is that when main() starts, there is only one thread --
which is always true if main() (or something it calls directly) is
responsible for creating additional threads.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:3CDAD069.5000707@acm.org...
> It certainly doesn't require going to the kernel to synchronise
> between threads on most platforms.

It does in the general case, because blocking a thread must be done in
kernel mode.

> The C++ Standard says nothing about threads, and so makes
> the behaviour of every program which uses them undefined,
> though it may (and really ought to) be defined by an
> implementation which supports multi-threading.
>
> Support for threading is something under consideration for
> a future version of the C++ standard.

It seems to me that the issue here is that, even though the Standard might
not provide thread primitives, it must account for the fact that most C++
programs will be running in a multi-thread environment. As far as I can see,
initializing a static object in a function is one of the few parts of the
language that must address the issue of multi-threading.

regards,
Tzvetan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <M7HC8.22682$C8.8891602@news02.optonline.net>, Hillel Y. Sims
<usenet@phatbasset.com> writes
>Thread-safety for a static local object can be accomplished from user code
>on a non-thread-safe compiler by using an available mutex (pthread_mutex,
>boost::mutex, whatever) to synchronize initialization and access of the
>singleton object on the heap behind a static pointer. However, it is much
>more convenient and portable and likely more efficient when the compiler
>handles it automatically on a mulitthreaded platform, especially if it can
>implement low-level platform-specific optimizations.

Hm... multi-threading is not one of my areas of expertise, but I wonder
if it would be reasonable to require static/global/namespace scope
variables to be initialised 'atomically' as part of future support for
multi-threading.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ole Reinartz" <ole.reinartz@gmx.de> wrote in message
news:3CD13453.83E6C414@gmx.de...
> Foo & Foo::instance()
> {
>     static Foo instance;
>     return instance;
> }
>
> This way your Foo singleton instance will be created the first time
> Foo::instance() gets called to. It is not guaranteed that it exists before
> main() gets executed, but it is guaranteed that it exists after someone
called
> for it.

This isn't thread safe, so it is not exactly the same thing as having a
global object initialized on program startup. This is OK in some situations,
but could create a terrible, almost untrackable bug in a multithread
application.


regards,
Tzvetan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

i have implemented a singelton pattern using a  creator object:
Is this save ?  Is it guaranteed, that this creator object is created at the
program startup ?


class FooCreator
{
public:
    FooCreator()
    {
        Foo::instance = new Foo;
    }

    ~Foo()
    {
        delete Foo::instance;
    }
};


static FooCreator creator;     // IS THIS OK ??????


class Foo
{
public:
    static Foo & instance();

private:
   static Foo *instance;


    friend class FooCreator;
};



Foo & Foo::instance()
{
    return *instance;
}


Greetings,
Marco Siciliano



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hillel Y. Sims" <usenet@phatbasset.com> wrote in message
news:a9HA8.122704$sI3.27259023@news02.optonline.net...
> It's implementation-specific, really -- on the Compaq C++ compiler, for
> example, this construct is properly synchronized and thread-safe. See your
> compiler docs (or do some testing to be sure).

What does the standard say about it (sadly, I don't own a copy) ?
I also wonder how expensive it is to generate implicit synchronization for
this. It seems to me that it would require creating a kernel synchronization
object and keeping it for the duration of the program.

I am pretty sure that no Windows compiler does this, for example.

-tzvetan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]