Singleton and ofPtr

I use a singleton pattern like:

  
#ifndef _H_SINGLETON  
#define _H_SINGLETON  
#include "assert.h"  
#include <cstdlib>  
template <class T>  
class Singleton {  
public:  
	static T* Instance() {  
		if(!m_pInstance) m_pInstance = new T;  
		assert(m_pInstance !=NULL);  
		return m_pInstance;  
	}  
protected:  
	Singleton();  
	~Singleton();  
private:  
	Singleton(Singleton const&);  
	Singleton& operator=(Singleton const&);  
	static T* m_pInstance;  
};  
template <class T> T* Singleton<T>::m_pInstance=NULL;  
#endif  

Which I use like:

  
Class MyClass{  
...  
};  
  
typedef Singleton<MyClass> myClassSingleton;  
static MyClass * myClass = myClassSingleton::Instance();  

I’m wondering if someone can help me with a Singleton pattern based on ofPtr?

I’ve mucked around with this for a while -> tried replacing T* with ofPtr to no avail…and can make an ofPtr of the Singleton instance, but then destruction isn’t clean…

I can see how to do it for a predetermined class, but getting flummoxed by typedef’ing for a template class that is also an ofPtr…

Does that make sense?

a singleton is usually a class that is not going to be destroyed ever so it isn’t necessary to use an ofPtr. Also ofPtr is slightly slower than a * so if you don’t really need it, it doesn’t make sense to use it.

if you wanted to use it though, you need to substitute T* with ofPtr and in the constructor, change line 9 with:

  
  
if(!m_pInstance) m_pInstance = ofPtr<T>(new T);    
  

Just some general info on ofPtr, and shared pointers in general (which I love, btw):

Normal pointers, i.e. Foo* foo; points to some thing that’s living in memory somewhere. No one knows who owns it, who frees it, where it came from, and who needs it. They’re old school, super fast, very handy, and the source of most of the bugs that have made me want to stab myself. In your case you’re making a singleton, you know where the only pointer is going to live and where to delete it, there’s no need to worry about someone else deleting it.

ofPtr is a shared pointer, which means that it’s stack-allocated object wrapping a pointer. When the last shared pointer for an object in memory is destructed, the wrapped pointer will also be deleted. The great thing about a shared pointer is that it allows you a lot of the advantages of a pointer without a lot of the downsides, but with some of it’s own downsides: slower to use, some people hate them, they can be a serious pain in multi-threaded code.

Actually, it’s probably better to read this: http://ootips.org/yonat/4dev/smart-pointers.html than anything I could write.

nice read joshua, thx for that. :slight_smile:

@Joshua: nice explanation :slight_smile:

@Arturo: I tried it that way round, ie:

  
#ifndef _H_SINGLETON  
#define _H_SINGLETON  
#include "assert.h"  
#include <cstdlib>  
#include "ofTypes.h"  
template <class T>  
class Singleton {  
public:  
	static ofPtr<T> Instance() {  
		if(!m_pInstance) m_pInstance = ofPtr<T>(new T);  
		assert(m_pInstance !=NULL);  
		return m_pInstance;  
	}  
protected:  
	Singleton();  
	~Singleton();  
private:  
	Singleton(Singleton const&);  
	Singleton& operator=(Singleton const&);  
	static ofPtr<T> m_pInstance;  
};  
template <class T> ofPtr<T> Singleton<T>::m_pInstance=NULL;  
#endif  
  
...  
  
Class MyClass {  
...  
};  
  
typedef Singleton<MyClass> MyClassContextSingleton;  
static ofPtr<MyClass> openNIContext = MyClassContextSingleton::Instance();  
  

But the compiler chokes on the line

  
template <class T> ofPtr<T> Singleton<T>::m_pInstance=NULL;  

with

  
conversion from 'int' to non-scalar type 'ofPtr<MyClass>' requested  

Regarding it’s use I usually use a singleton pattern for the Model part of MVC (Model-View-Controller) style application design (and happily create/destroy it myself). But for some of the openNI stuff I’m doing (where I need a singleton) I thought it might be good to use a smart-pointer-singleton, so releasing the ‘global’ context does not need to be manually called in an onExit() method…found some good debate about this concept at http://www.cplusplus.com/forum/general/37113/

Interested to know to what degree shared-pointers are slower than a normal pointer…do you have any references or ideas of ways to test the performance difference? Or is it so slight it doesn’t matter?

Ok I guess it should have been obvious, but changing:

  
template <class T> ofPtr<T> Singleton<T>::m_pInstance=NULL;   

to

  
template <class T> ofPtr<T> Singleton<T>::m_pInstance;   

fixes the error…but it makes me nervous as this means m_pInstance is ‘undefined’ rather than set to NULL…which maybe could cause problems down the track?

I suppose I could to set it to NULL in the constructor, like:

  
Singleton(){m_pInstance = NULL;};  

Hopefully this is safe. It certainly appears to be working.

it is safe since ofPtr is an object and is internally initialized to NULL by default in it’s constructor.

As to why it’s slower than a plain pointer, a smart pointer has an atomic counter, to account for how many instances are in use. Atomic means that the operation of increasing and decreasing the counter needs to be done without being interrupted by any thread. In some systems there’s specific OS operations to indicate the CPU that it has to change the value of the counter in an atomic fashion but it could even involve locking a mutex. This only happens when there’s a copy of the ofPtr, for example when you pass it as a parameter to another function so most of the times the difference with using a raw pointer is unnoticeable.

Also since incrementing the counter means some kind of locking, in multithreadead contexts you should take that into account to not have dead locking issues.