Prev: 'const' and compiler optimization
Next: copy constructor and assignment
From: Kris Prad on 14 Dec 2009 00:46
I want to setup a singleton, without 'static' initialization. My
motive is to control the life time of the Singleton, bounded by its
scope, something I cannot do with the statics.

Not this way. This uses static:

Single* Get()
{
Static Single s; // do not want static
Return &s;
}

Instead, I am doing this (please ignore thread safety issues)
Single* g_Single = NULL; // global singleton ptr
struct Single
{

Single()
{
if (!g_Single)
{
g_Single = this;
}
else
{
throw string("Single is a singleton");
}
}
~Single()
{
g_Single = NULL;
}
};

Is this ugly or acceptable?

Kris


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 14 Dec 2009 07:29
Kris Prad wrote:
> I want to setup a singleton, without 'static' initialization. My
> motive is to control the life time of the Singleton, bounded by its
> scope, something I cannot do with the statics.
>
> Not this way. This uses static:
>
> Single* Get()
> {
> Static Single s; // do not want static
> Return &s;
> }
>
> Instead, I am doing this (please ignore thread safety issues)
> Single* g_Single = NULL; // global singleton ptr
> struct Single
> {
>
> Single()
> {
> if (!g_Single)
> {
> g_Single = this;
> }
> else
> {
> throw string("Single is a singleton");
> }
> }
> ~Single()
> {
> g_Single = NULL;
> }
> };
>
> Is this ugly or acceptable?
>
> Kris
>
>

What is wrong with this:

class Single {
public:
Single(){
if(exists) throw("You can only have one object of type Single");
exists = true;
// do rest
}
~Single() { exists = false }
// rest of interface
private:
static bool exists;
// rest of private interface etc.
};

bool Single::exists(false);

The trouble with your use of a global variable is that it could be
accidentally modified and the compiler will not be able to help you.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Kirill_Lykov on 14 Dec 2009 23:11
On Dec 14, 11:46 pm, Kris Prad <krisp...(a)yahoo.co.uk> wrote:
> I want to setup a singleton, without 'static' initialization. My
> motive is to control the life time of the Singleton, bounded by its
> scope, something I cannot do with the statics.
>
> Not this way. This uses static:
>
> Single* Get()
> {
> Static Single s; // do not want static
> Return &s;
>
> }
>
> Instead, I am doing this (please ignore thread safety issues)
> Single* g_Single = NULL; // global singleton ptr
> struct Single
> {
>
> Single()
> {
> if (!g_Single)
> {
> g_Single = this;
> }
> else
> {
> throw string("Single is a singleton");
> }
> }
> ~Single()
> {
> g_Single = NULL;
> }
>
> };
>
> Is this ugly or acceptable?
>
> Kris
>

Well, you should understand the difference between Singleton patterns
and global variable. What you have described is not a singleton.
if you want to control lifetime of you variable you may use Meyers
singleton. Nevertheless, I recommend you to avoid using both
singletons and global variables, for additional details read
"Refactoring to Patterns" by Joshua Kerievsky, chapter 6. Inline
singleton.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andrew on 14 Dec 2009 23:13
On 15 Dec, 00:29, Francis Glassborow
<francis.glassbo...(a)btinternet.com> wrote:
> Kris Prad wrote:
> > I want to setup a singleton, without 'static' initialization.

> What is wrong with this:
>
> class Single {
> public:
> Single(){
> if(exists) throw("You can only have one object of type Single");
> exists = true;
> // do rest
> }
> ~Single() { exists = false }
> // rest of interface
> private:
> static bool exists;
> // rest of private interface etc.
>
> };
>
> bool Single::exists(false);

This allows a Single (which is a singleton) to be created whilst
avoiding statics. But it doesn't show a Single actually being created.
I think the OP is also concerned with the lifetime of the singleton,
i.e who creates it and when does it get destroyed.

For complex systems that use many singletons where initialisation
order is important, a singleton manager is sometimes used. The manager
is usually instantiated in main, then register functions called for
the various singletons that are needed. Singleton destruction occurs
in reverse order of registration. FWIW, ACE has such a singleton
manager.

Regards,

Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Kris Prad on 16 Dec 2009 20:32
On Dec 15, 4:13 pm, Andrew <marlow.and...(a)googlemail.com> wrote:
> On 15 Dec, 00:29, Francis Glassborow
>
>
>
>
>
> <francis.glassbo...(a)btinternet.com> wrote:
> > Kris Prad wrote:
> > > I want to setup a singleton, without 'static' initialization.
> > What is wrong with this:
>
> > class Single {
> > public:
> > Single(){
> > if(exists) throw("You can only have one object of type Single");
> > exists = true;
> > // do rest
> > }
> > ~Single() { exists = false }
> > // rest of interface
> > private:
> > static bool exists;
> > // rest of private interface etc.
>
> > };
>
> > bool Single::exists(false);
>
> This allows a Single (which is a singleton) to be created whilst
> avoiding statics. But it doesn't show a Single actually being created.
> I think the OP is also concerned with the lifetime of the singleton,
> i.e who creates it and when does it get destroyed.
>


This is more a 'scoped' singleton rather than a global singleton. The
usage is something like this.


{
Single logger1("logFile1"); // log messages to a file
...
< do something>
}

{
Single logger2("logFile2"); // log to another file
...
< do something else>

{
Single logger3("logFile3)"); // throws, but ok if logger2 does
not exist
....
}
}

The actual usage is more complex, but this is the intent.



Kris

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 |  Next  |  Last
Pages: 1 2
Prev: 'const' and compiler optimization
Next: copy constructor and assignment