| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"Daniel Kay" |
| Date: |
03 Sep 2006 08:39:47 AM |
| Object: |
Alternative was to implement a Singleton Design Pattern |
Hello,
currently I am reading the book "Effective C++ Third Edition" from Scott
Meyers. While Reading Item 4 (Make sure that objects are initialized
before they're used) I got an idea how to improve the way to implement
the Singlton Design Pattern.
This is the way I used to do it:
Singleton.h
----------
class Singleton {
public:
static Singleton* getInstance() {
if (!m_instance) {
m_instance = new Singleton();
}
return m_instance;
}
private:
Singleton() { }
~Singleton() { }
static Singleton* m_instance;
}
Singleton.cpp
-------------
Singleton* Singleton::m_instance = 0;
This is the way I am planning to do it in future:
Singleton.h
-----------
class Singleton {
public:
static Singleton* getInstance() {
static Singleton instance;
return &instance;
}
private:
Singleton() { }
~Singleton() { }
};
(Source is only showing the concept. I didn't compile it.)
I see the following pros:
- No potentional memory leak when process terminates.
- Less source code required.
- Not necessarely a .cpp file required for the static member.
Are there any cons I am missing?
Thanks for your thoughts,
Daniel Kay
.
|
|
| User: "dasjotre" |
|
| Title: Re: Alternative was to implement a Singleton Design Pattern |
06 Sep 2006 02:02:38 PM |
|
|
Daniel Kay wrote:
I see the following pros:
- No potentional memory leak when process terminates.
- Less source code required.
- Not necessarely a .cpp file required for the static member.
singleton would prefferably be implemented as a template
so this is not realy a benefit
Are there any cons I am missing?
I don't think there is a single implementation that satisfies
all possible requirements.
few cons might arrise
- No control over singleton's liffetime, can't delete it
see http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt
<no link intentional>
- Singleton must have default constructor
- if Singleton's constructor throws you might not be able to recover
- I can do
delete Singleton::getInstance()
invoking undefined behaviour, bether return reference
instead of a pointer
otherwise it's fine :)
.
|
|
|
|
| User: "red floyd" |
|
| Title: Re: Alternative was to implement a Singleton Design Pattern |
03 Sep 2006 04:40:21 PM |
|
|
Daniel Kay wrote:
This is the way I am planning to do it in future:
Singleton.h
-----------
class Singleton {
public:
static Singleton* getInstance() {
static Singleton instance;
return &instance;
}
private:
Singleton() { }
~Singleton() { }
};
(Source is only showing the concept. I didn't compile it.)
I see the following pros:
- No potentional memory leak when process terminates.
- Less source code required.
- Not necessarely a .cpp file required for the static member.
Are there any cons I am missing?
See Alexandrescu's "Modern C++ Design". It discusses singletons in more
detail than you'd ever want to know, and in particular, he discusses
this idiom (he calls it a "Meyers Singleton", since Meyers is the
earliest cite he found it in, I guess).
.
|
|
|
|
|
Related Articles |
|
|
