Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ Singleton problem...

Reply
Thread Tools

C++ Singleton problem...

 
 
tobias.sturn@vol.at
Guest
Posts: n/a
 
      06-15-2006
Hi!

I have written this template for making a singleton:
#define DECLARE_SINGLETON(classname) \
private: \
static classname* m_pThis; \
classname(); \
class Guard \
{ \
public: \
~Guard() \
{ \
if(classname::m_pThis != 0 ) \
delete classname::m_pThis; \
} \
}; \
friend class Guard; \
public: \
static classname* getInstance();

#define DEFINE_SINGLETON(classname) \
classname* classname::m_pThis=0; \
classname* classname::getInstance() \
{ \
static Guard guard; \
if(m_pThis == 0) \
{ \
m_pThis = new classname(); \
} \
return m_pThis; \
}

Now i have a class which uses these macros but now i still i can write
constructors make them public and i have won nothing...

class Class
{
public:
Class(int a) {/*i have created an object */
Class(char a)...
};;

How could i make it not possible for the user of the template that he
cant override the constructor?

Thanks very much!!

 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      06-16-2006
tobias.sturn wrote:

> Now i have a class which uses these macros but now i still i can write
> constructors make them public and i have won nothing...
>
> class Class
> {
> public:
> Class(int a) {/*i have created an object */
> Class(char a)...
> };;


You can't. The point of classes is to be upgraded and re-used. Deal.

> How could i make it not possible for the user of the template that he
> cant override the constructor?


The mininimal situation worked for me:

class frob {
DECLARE_SINGLETON(frob);
};

DEFINE_SINGLETON(frob);
frob::frob() {}
#include <assert.h>
#include <stdlib.h>

int main()
{
frob * pFrob = frob::getInstance();
assert(NULL != pFrob);
// frob aFrob; // <-- bad
return 0;
}

Now about your style. "Singleton" is the most abused pattern in /Design
Patterns/, and it's the best candidate for time travel to tell the GOF to
take it out. I can think of many situations where a program needs only one
of something, but I can't think of any situation where a program should
never have more than one of something.

Next, you should use unit tests (like my main()), and should pass them after
every edit. This implies that some of your classes should use a mock object
instead of your singleton. So that implies that tests have legitimate
reasons to re-use more than one instance of your singleton, to construct
them with extra data, and to derive from them.

Next, a Singleton is not an excuse for a global variable. Most clients of
your singleton should pass it in by reference. They should not rely on it
floating around in space. So nearly all clients of your singleton should
accept a reference that your tests can mock.

Next, you are abusing macros. You should instead abuse templates. Google for
[c++ singleton template], and get sample code like this:

http://www.codeproject.com/cpp/singleton_template.asp

Next, neither your getInstance() nor the one on that page can return a NULL
pointer, so they should return a reference to the Singleton. Whichever
pattern you go with, make that small fix.

Next, I suspect this is the best implementation for the getter:

static T& Instance()
{
static T aT;
return aT;
};

That is well-defined to construct aT at least before the first time the
function enters, so it fixes the common C++ problem with global variables
constructing out of order, and fixes it without the odious choice of a 'new'
call. Other patterns and situations may easily apply here, too.

After applying any subset of my suggestions, you will have a better program
with less need to restrict your constructors.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
 
 
 
Axter
Guest
Posts: n/a
 
      06-16-2006

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi!
>
> I have written this template for making a singleton:
> #define DECLARE_SINGLETON(classname) \
> private: \
> static classname* m_pThis; \
> classname(); \
> class Guard \
> { \
> public: \
> ~Guard() \
> { \
> if(classname::m_pThis != 0 ) \
> delete classname::m_pThis; \
> } \
> }; \
> friend class Guard; \
> public: \
> static classname* getInstance();
>
> #define DEFINE_SINGLETON(classname) \
> classname* classname::m_pThis=0; \
> classname* classname::getInstance() \
> { \
> static Guard guard; \
> if(m_pThis == 0) \
> { \
> m_pThis = new classname(); \
> } \
> return m_pThis; \
> }
>
> Now i have a class which uses these macros but now i still i can write
> constructors make them public and i have won nothing...
>
> class Class
> {
> public:
> Class(int a) {/*i have created an object */
> Class(char a)...
> };;
>
> How could i make it not possible for the user of the template that he
> cant override the constructor?
>
> Thanks very much!!


With the following Singleton class, you can create a Singleton use one
of two methods.
You can derive from Singleton as the foo example class does below, or
you can create a class like the Widget example class.

template<typename T>
class Singleton
{
protected:
Singleton(){}
~Singleton(){}
Singleton(const Singleton&);
Singleton& operator=(const Singleton&);
public:
class FriendClass
{
public:
FriendClass():m_MyClass(new T()){}
~FriendClass(){delete m_MyClass;}
T* m_MyClass;
};
static T& Instance() {
static FriendClass Instance;
return *Instance.m_MyClass;
}
};

class Widget {
private:
Widget(){}
~Widget(){}
Widget& operator=(const Widget&);
Widget(const Widget&);
public:
friend class Singleton<Widget>::FriendClass;
int m_i;
};


class foo : public Singleton<foo>{
private:
foo(){}
~foo(){}
foo& operator=(const foo&);
foo(const foo&);
public:
friend class FriendClass;
int m_i;
};


int main(int argc, char* argv[])
{
Widget& MyWidget = Singleton<Widget>::Instance();
foo& Myfoo = foo::Instance();

system("pause");
return 0;
}

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      06-16-2006
Axter wrote:

You answered the wrong question. (I do that often enough I'm going to
crack down on you for it.)

> class Widget {
> private:
> Widget(){}
> ~Widget(){}


One can still write 'public: Widget(something)' here, and construct the
Widget without the Singleton wrapper.

--
Phlip
 
Reply With Quote
 
Axter
Guest
Posts: n/a
 
      06-18-2006

Phlip wrote:
> Axter wrote:
>
> You answered the wrong question. (I do that often enough I'm going to
> crack down on you for it.)
>
> > class Widget {
> > private:
> > Widget(){}
> > ~Widget(){}

>
> One can still write 'public: Widget(something)' here, and construct the
> Widget without the Singleton wrapper.
>


Then you would not be creating a Singleton.
Widget is the target Singleton. When you create a Singleton, you want
your constructors to be private.

 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      06-18-2006
Axter wrote:

> Then you would not be creating a Singleton. Widget is the target
> Singleton. When you create a Singleton, you want your constructors to be
> private.


That's the design answer (which I already provided). The technical answer
is you can't prevent Widget from having other constructors.

--
Phlip
 
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