Home arrow C++ arrow Page 2 - The Singleton Pattern Revisited

The Singleton Pattern Revisited

A reader wrote in some time after we ran a short series on the Singleton pattern with some questions. These included how to construct a singleton when the class has a non-trivial constructor with arguments that are calculated at run-time, and how to use the singleton in a multi-threaded environment. If you were wondering about these issues as well, keep reading.

Author Info:
By: J. Nakamura
Rating: 4 stars4 stars4 stars4 stars4 stars / 19
May 02, 2005
  1. · The Singleton Pattern Revisited
  2. · The creation of a Singleton
  3. · Policy-based Class Design
  4. · Tweaking the Singleton Class with Policies
  5. · Singleton's Thread Safety

print this article

The Singleton Pattern Revisited - The creation of a Singleton
(Page 2 of 5 )

Please read the other two articles about the Singleton Pattern if you havenít already: http://www.devarticles.com/c/a/Cplusplus/C-plus-
 and http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-In-Theory-The-
. This article will deal with the generic Singleton implementation as it was presented in the second article. I find this implementation to be the most useful; the other code examples in the previous articles just serve to create a better understanding of how and why we want to use singletons.

The question the reader raised also concerned this code. How can we successfully create a singleton when the constructor for the object contained in that singleton needs parameters that are determined dynamically at run-time? First, here is a quick recap of that generic Singleton implementation:

#ifndef __SINGLETON_H

#define __SINGLETON_H

template <class T> struct CreateLeaking {

static T* Create() { return new T; }


template <class T> struct CreateMeyers {

static T* Create() {

static T _instance;

return &_instance;



template < class T,

template<class> class CreationPolicy=CreateMeyers >

class Singleton {


static T& Instance() {

if (!m_pInstance)


return *m_pInstance;




Singleton(); // hidden

Singleton(Singleton const&); // hidden

Singleton& operator=(Singleton const&); // hidden

static T* m_pInstance;


template <class T, template <class> class C>

T* Singleton<T,C>::m_pInstance=0;

#endif // __SINGLETON_H

This class is very useful because it truly promotes code reuse, in the sense that any class you already have can be made a SingletonÖ or can it?

The code above is not sufficient when the class you want to make a singleton doesnít supply a default constructor, but one that needs parameters instead. You can see that the compiler will complain when the Create() function in either policy class wants to construct it without providing the necessary parameters. How do we convey that information to the right constructor then?

Donít add a default constructor to the class you want to use as a Singleton. This defies the point of creating a generic Singleton class in the first place, and it might not always be possible to change the code! Letís take a closer look at this creation policy thing first.

blog comments powered by Disqus

- Intel Threading Building Blocks
- Threading Building Blocks with C++
- Video Memory Programming in Text Mode
- More Tricks to Gain Speed in Programming Con...
- Easy and Efficient Programming for Contests
- Preparing For Programming Contests
- Programming Contests: Why Bother?
- Polymorphism in C++
- Overview of Virtual Functions
- Inheritance in C++
- Extending the Basic Streams in C++
- Using Stringstreams in C++
- Custom Stream Manipulation in C++
- General Stream Manipulation in C++
- Serialize Your Class into Streams in C++

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials