473,401 Members | 2,125 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,401 software developers and data experts.

Singleton question

JFR
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"?

Jul 23 '05 #1
10 1482
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.

Jul 23 '05 #2
"JFR" <jf*******@gmail.com> 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.
Jul 23 '05 #3
Torsten Mueller skrev:
"JFR" <jf*******@gmail.com> 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.

Jul 23 '05 #4
JFR
> 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.

Jul 23 '05 #5
JFR
> 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?

Jul 23 '05 #6
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!
Jul 23 '05 #7
Pelle Beckman <he******@chello.se> 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.
Jul 23 '05 #8
"JFR" <jf*******@gmail.com> 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.
Jul 23 '05 #9
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.
Jul 23 '05 #10
Lionel wrote:
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.


Actually, I possibly didn't read your post carefully enough,
particularly your discussion of protected instead of private. I would
agree on that!
Jul 23 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Richard A. DeVenezia | last post by:
foo() generates elements with event handlers that invoke foo function properties. Is this an abhorrent or misthought pattern ? It allows just the one occurence of identifier /foo/ to be changed...
4
by: Eric | last post by:
Perhaps this question has been posed before (I'd be surprised if it hasn't) but I just gotta know... Is it possible to combine the Singleton and Factory Method design patterns in the same class?...
10
by: ferdinand.stefanus | last post by:
Hi Could someone tell me what's the difference between these two singleton implementations: First implementation: class Singleton { public:
1
by: Stephen Brown | last post by:
I posted a question yesterday about a Singleton I have, using the standard dotNet pattern, that seems to get recreated several times a day. I turned on my performance counters (thanks to Mickey...
21
by: Sharon | last post by:
I wish to build a framework for our developers that will include a singleton pattern. But it can not be a base class because it has a private constructor and therefore can be inherit. I thought...
14
by: Paul Bromley | last post by:
Forgive my ignorance on this one as I am trying to use a Singleton class. I need to use this to have one instance of my Class running and I think I understand how to do this. My question however is...
2
by: Kevin Newman | last post by:
I have been playing around with a couple of ways to add inheritance to a JavaScript singleton pattern. As far as I'm aware, using an anonymous constructor to create a singleton does not allow any...
6
by: toton | last post by:
Hi, If I have a singleton class based on dynamic initialization (with new ) , is it considered a memory leak? Anything in C++ standard says about it ? And little off - topic question , If the...
3
by: wizwx | last post by:
There are two typical implementations of a singleton. The first one is to use a static pointer class Singleton { static Singleton * pSingleton; public: Singleton * instance() {...
2
by: Bob Johnson | last post by:
Just wondering the extent to which some of you are implementing classes as Singletons. I'm working on a brand new project and, early on, identified some obvious candidates. By "obvoius candidates"...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.