Re: Reordering of Instructions in a Threaded Context
Re: Reordering of Instructions in a Threaded Context
- Subject: Re: Reordering of Instructions in a Threaded Context
- From: "Lyndsey D. Ferguson" <email@hidden>
- Date: Tue, 1 Mar 2005 15:20:13 -0500
With the singleton pattern, I don't believe you should allow the class
constructor to be public:
class Singleton
{
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* fInstance;
};
in the cpp file:
Singleton* Singleton::fInstance = NULL;
Singleton* Singleton::Instance()
{
if (fInstance == NULL) {
fInstance = new Singleton;
}
return fInstance;
}
And when ever you want to access the singleton, you call it's
Instance() function.
Singleton::Instance()->MemberFunction();
That way, you don't have to worry about whether it has been created or
not.
Lyndsey
On Feb 28, 2005, at 4:19 AM, Andreas Grosam wrote:
This is a general C++ question, hopefully not too OT ;-)
While implementing a thread savvy Singleton pattern, this question
came up:
Suppose the following source lines:
Foo* p = 0;
p = new Foo();
Is it guaranteed that - in any case (e.g. inlined c-tors, aggressive
optimization) - the variable p will be assigned with the result
*after* the object has been completely initialized?
Or, may p be set after the memory has been successfully allocated but
*before* the initialization of the object has been finished (due to
reordering of instructions from the compiler)?
If so, would declaring p as a volatile pointer help?
Foo* volatile p = 0;
Regards
Andreas Grosam _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Lyndsey D. Ferguson
Software Engineer : Platforms Group
Nemetschek North America, Inc.
mailto: email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden