Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Singleton question

Reply
Thread Tools

Singleton question

 
 
JFR
Guest
Posts: n/a
 
      06-30-2005
i found this code sample on the net that i wanted to use:




class CUniqueObject
{
private:
CUniqueObject( void ) : m_iValue(0) { }
~CUniqueObject( void ) { }


public:
void SetValue( int iValue ) { m_iValue = iValue; }
int GetValue( void ) { return m_iValue; }

static CUniqueObject *GetInstance( void )
{
if( m_pSingleton == 0 )
{
std::cout << "creating singleton." << std::endl;
m_pSingleton = new CUniqueObject;
}
else
{
std::cout << "singleton already created!" << std::endl;
}

return m_pSingleton;
}

static void Kill( void )
{
if( m_pSingleton != 0 )
{
delete m_pSingleton;
m_pSingleton = 0;
}
}


private:
int m_iValue;
static CUniqueObject *m_pSingleton;
};


CUniqueObject *CUniqueObject::m_pSingleton = 0;


int main( int argc, char *argv[] )
{

CUniqueObject *pObj1, *pObj2;
pObj1 = CUniqueObject::GetInstance();
pObj2 = CUniqueObject::GetInstance();
pObj1->SetValue( 11 );
std::cout << "pObj1::m_iValue = " << pObj1->GetValue() << std::endl;
std::cout << "pObj2::m_iValue = " << pObj2->GetValue() << std::endl;
pObj1->Kill();

return 0;
}


when i run the above code and debug it, the pObj1 shows that it
contains 2 things, a m_iValue and a m_pSingleton. However, the
m_pSingleton contains a CUniqueObject* which in turns also contains a
m_iValue and a m_pSingleton, and this goes on and on. I can expand the
object trees in the debugger infinitely.
At first i thought there was a problem with the code, but i think it's
just the debugger's way of showing objects.

Is this behavior "normal"?

 
Reply With Quote
 
 
 
 
Rolf Magnus
Guest
Posts: n/a
 
      06-30-2005
JFR wrote:

> i found this code sample on the net that i wanted to use:
>
>
>
>
> class CUniqueObject
> {
> private:
> CUniqueObject( void ) : m_iValue(0) { }
> ~CUniqueObject( void ) { }


There should also be (deliberately not implemented):

CUniqueObject(CUniqueObject&);
void operator=(CUniqueObject);

to avoid accidental copies of the object.

> public:
> void SetValue( int iValue ) { m_iValue = iValue; }
> int GetValue( void ) { return m_iValue; }
>
> static CUniqueObject *GetInstance( void )
> {
> if( m_pSingleton == 0 )
> {
> std::cout << "creating singleton." << std::endl;
> m_pSingleton = new CUniqueObject;
> }
> else
> {
> std::cout << "singleton already created!" << std::endl;
> }
>
> return m_pSingleton;
> }
>
> static void Kill( void )
> {
> if( m_pSingleton != 0 )
> {
> delete m_pSingleton;
> m_pSingleton = 0;
> }
> }
>
>
> private:
> int m_iValue;
> static CUniqueObject *m_pSingleton;
> };
>
>
> CUniqueObject *CUniqueObject::m_pSingleton = 0;
>
>
> int main( int argc, char *argv[] )
> {
>
> CUniqueObject *pObj1, *pObj2;
> pObj1 = CUniqueObject::GetInstance();
> pObj2 = CUniqueObject::GetInstance();
> pObj1->SetValue( 11 );
> std::cout << "pObj1::m_iValue = " << pObj1->GetValue() << std::endl;
> std::cout << "pObj2::m_iValue = " << pObj2->GetValue() << std::endl;
> pObj1->Kill();
>
> return 0;
> }
>
>
> when i run the above code and debug it, the pObj1 shows that it
> contains 2 things, a m_iValue and a m_pSingleton. However, the
> m_pSingleton contains a CUniqueObject* which in turns also contains a
> m_iValue and a m_pSingleton, and this goes on and on. I can expand the
> object trees in the debugger infinitely.
> At first i thought there was a problem with the code, but i think it's
> just the debugger's way of showing objects.


Yes, it is. The object only contains m_iValue. m_pSingleton is a static
member, which means it's only there once for the whole class and not for
every instance of it.

> Is this behavior "normal"?


The debugger should be more precise.

 
Reply With Quote
 
 
 
 
Torsten Mueller
Guest
Posts: n/a
 
      06-30-2005
"JFR" <(E-Mail Removed)> schrieb:

> when i run the above code and debug it, the pObj1 shows that it
> contains 2 things, a m_iValue and a m_pSingleton. However, the
> m_pSingleton contains a CUniqueObject* which in turns also contains
> a m_iValue and a m_pSingleton, and this goes on and on. I can expand
> the object trees in the debugger infinitely. At first i thought
> there was a problem with the code, but i think it's just the
> debugger's way of showing objects.
>
> Is this behavior "normal"?


Yes, it is. It's just the expected behaviour of the debugger handling
variables containing pointers to itself.

BTW: I've never been a friend of constructions like this class you
used. For some reasons:

a) Private constructors forbid the creation of sub-classes. This can
cause serious problems if anyone tries to recycle this class for
later use.

b) Methods like GetInstance() cause several problems:

- They hide the way an object is created. A programmer does never
know, is the object created now or has it been created long before
and should he delete it or is it deleted automatically, is it
created on the heap at all and so on. This methods forbid several
ways to create an instance. One time I found the following methods
of several classes in the same class library: GetInstance(),
GetObject(), CreateObject() and NewObject(). One of them used
reference counting on creation. Which one was it?

- GetInstance() does not allow to call a specific constructor. In this
case several different methods would be needed. Indeed programmers
do implement initialization methods rather and call them after
calling GetInstance(). This leads to a two-step-construction in the
best case. In worst case they "initialize" the existing singleton
again and again. We could ask if a singleton is really the right
concept here.

What the hell is evil on "new"?

void foo ()
{
MyClass* pMyClass=new MyClass("bla",1.234);
// ...
delete pMyClass;
}

And why not use a local instance of a class on the stack for a local
purpose?

void foo ()
{
MyClass c("bla",1.234); // make it just static to
// get a singleton!
// ...
}

In my experience the singleton pattern is normally enforced by people
having found this just a really gorgeous idea and not knowing real
problems.

T.M.
 
Reply With Quote
 
Pelle Beckman
Guest
Posts: n/a
 
      07-01-2005
Torsten Mueller skrev:
> "JFR" <(E-Mail Removed)> schrieb:
>
>
>>when i run the above code and debug it, the pObj1 shows that it
>>contains 2 things, a m_iValue and a m_pSingleton. However, the
>>m_pSingleton contains a CUniqueObject* which in turns also contains
>>a m_iValue and a m_pSingleton, and this goes on and on. I can expand
>>the object trees in the debugger infinitely. At first i thought
>>there was a problem with the code, but i think it's just the
>>debugger's way of showing objects.
>>
>>Is this behavior "normal"?

>
>
> Yes, it is. It's just the expected behaviour of the debugger handling
> variables containing pointers to itself.
>
> BTW: I've never been a friend of constructions like this class you
> used. For some reasons:
>
> a) Private constructors forbid the creation of sub-classes. This can
> cause serious problems if anyone tries to recycle this class for
> later use.


I get you point, but is this really a problem?
Is anyone likely to inherit a class that is directly
implemented as a singleton?
Singleton _templates_ on the other hand...

I'm just curious, not picking a fight.
>
> b) Methods like GetInstance() cause several problems:
>
> - They hide the way an object is created. A programmer does never
> know, is the object created now or has it been created long before
> and should he delete it or is it deleted automatically, is it
> created on the heap at all and so on. This methods forbid several
> ways to create an instance. One time I found the following methods
> of several classes in the same class library: GetInstance(),
> GetObject(), CreateObject() and NewObject(). One of them used
> reference counting on creation. Which one was it?
>
> - GetInstance() does not allow to call a specific constructor. In this
> case several different methods would be needed. Indeed programmers
> do implement initialization methods rather and call them after
> calling GetInstance(). This leads to a two-step-construction in the
> best case. In worst case they "initialize" the existing singleton
> again and again. We could ask if a singleton is really the right
> concept here.
>
> What the hell is evil on "new"?
>
> void foo ()
> {
> MyClass* pMyClass=new MyClass("bla",1.234);
> // ...
> delete pMyClass;
> }
>
> And why not use a local instance of a class on the stack for a local
> purpose?
>
> void foo ()
> {
> MyClass c("bla",1.234); // make it just static to
> // get a singleton!
> // ...
> }
>
> In my experience the singleton pattern is normally enforced by people
> having found this just a really gorgeous idea and not knowing real
> problems.
>
> T.M.

 
Reply With Quote
 
JFR
Guest
Posts: n/a
 
      07-02-2005
> In my experience the singleton pattern is normally enforced by people
> having found this just a really gorgeous idea and not knowing real
> problems.
>
> T.M.


Mybe you're right. I just needed a class with global scope to do some
macromanagement of the (complex) application state and resources. I
want to make clean code that is gonna be extensible and
straightforward. The singleton pattern seemed to me like the perfect
tool. Since I learned about patterns a short while back, I probably
suffer from pattern obsession disorder, but it's fine since my code is
purely an exercice in practice. I only hope that if i made bad design
choices, I'm going to notice them, even if it's much later on, just so
i dont make the same mistake twice.

 
Reply With Quote
 
JFR
Guest
Posts: n/a
 
      07-02-2005
> I get you point, but is this really a problem?
> Is anyone likely to inherit a class that is directly
> implemented as a singleton?
> Singleton _templates_ on the other hand...


The original code snippet is posted isnt the one i use. I of course
have no use for a pure singleton class, so i used a templated one that
goes as follows:



template <typename T> class CSingleton
{
protected:
CSingleton( void ) { }
~CSingleton( void ) { std::cout << "destroying singleton." <<
std::endl; }


public:
static T *GetInstance( void )
{
if( m_pSingleton == 0 )
{
std::cout << "creating singleton." << std::endl;
m_pSingleton = new T;
}
else
{
std::cout << "singleton already created!" << std::endl;
}

return ((T *)m_pSingleton);
}

static void Kill( void )
{
if( m_pSingleton != 0 )
{
delete m_pSingleton;
m_pSingleton = 0;
}
}


private:
static T *m_pSingleton;

};

template <typename T> T *CSingleton<T>::m_pSingleton = 0;





anyone see some potential improvements on this code and care to
discuss it?

 
Reply With Quote
 
Pelle Beckman
Guest
Posts: n/a
 
      07-02-2005
JFR skrev:
>>In my experience the singleton pattern is normally enforced by people
>>having found this just a really gorgeous idea and not knowing real
>>problems.
>>
>>T.M.

>
>
> Mybe you're right. I just needed a class with global scope to do some
> macromanagement of the (complex) application state and resources. I
> want to make clean code that is gonna be extensible and
> straightforward. The singleton pattern seemed to me like the perfect
> tool. Since I learned about patterns a short while back, I probably
> suffer from pattern obsession disorder, but it's fine since my code is
> purely an exercice in practice. I only hope that if i made bad design
> choices, I'm going to notice them, even if it's much later on, just so
> i dont make the same mistake twice.
>


Pattern Obsession Disorder is a wonderful new word!
 
Reply With Quote
 
Torsten Mueller
Guest
Posts: n/a
 
      07-04-2005
Pelle Beckman <(E-Mail Removed)> schrieb:

> > a) Private constructors forbid the creation of sub-classes. This
> > can cause serious problems if anyone tries to recycle this class
> > for later use.

>
> I get you point, but is this really a problem?


It can be, yes. I got a library from someone implementing a beautiful
class with private constructors and even a private destructor. I just
wanted to extend a method by one line of my own code, all the rest and
also the singleton state of the object should remain as it was. I
couldn't do this without changing the original class.

In my opinion the keyword "private" is always (!) bad style.
"protected" solves the task much better without the disadvantages.

T.M.
 
Reply With Quote
 
Torsten Mueller
Guest
Posts: n/a
 
      07-04-2005
"JFR" <(E-Mail Removed)> schrieb:

> > In my experience the singleton pattern is normally enforced by
> > people having found this just a really gorgeous idea and not
> > knowing real problems.

>
> Mybe you're right. I just needed a class with global scope to do
> some macromanagement of the (complex) application state and
> resources. I want to make clean code that is gonna be extensible and
> straightforward.


Sure! But this code is the opposite of extensible.

Look, nobody will forbid you to create a single instance of a class
for global use. But this class does not need private constructors and
this stuff at all. Just use a normal class for this.

T.M.
 
Reply With Quote
 
Lionel
Guest
Posts: n/a
 
      07-04-2005
Torsten Mueller wrote:
> In my experience the singleton pattern is normally enforced by people
> having found this just a really gorgeous idea and not knowing real
> problems.


I have had some very good uses for the Singleton pattern in the past.
Admittedly they were in Java which does have some consequences.

I can't think of a situation where you would use the Singleton pattern
and would want to have subclasses, that just sounds crazy IMHO. The idea
generally is that you only want one instance of some set of data that is
operated on by everyone, this way it stays consistent.

I have also never gone looking to just apply a design patter for the fun
of it, I have always started with a problem and just discovered that a
particular pattern is suitable for purpose.

Lionel.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Singleton methods without the singleton class Charles Oliver Nutter Ruby 4 03-22-2010 10:46 PM
Singleton object vs. enhancing singleton class Paul McMahon Ruby 3 06-09-2008 06:05 AM
Singleton Modules rather than Singleton Classes Trans Ruby 12 09-14-2007 06:45 AM
Singleton - Whether Cloneable overrides Singleton Proton Projects - Moin Java 4 03-27-2007 02:59 AM
Singleton classes and Singleton pattern Wilhelm Ruby 1 10-11-2006 01:08 PM



Advertisments