Singleton: type name is not allowed

S

srimks11

Dear All.

I am looking for small help on Singleton concept.

I had defined a singleton class as below -

---A.h---
class A
{
public:
static A* Instance();
protected:
A ();
private:
static A* A_instance;
};

---A.cc----
A* A::A_instance = 0;

A* A::Instance()
{
if(A_instance == 0)
{
A_instance = new A;
}
return A_instance;
}

A::A()
{
}
----

Now I wish to perform sole instance for below statement (i) using
above Singleton Instance() API call, originialy NonP is basically a
class.

NonP *nb = new NonP[524288];
-----(i)

I am aware about the syntax which should be somewhat as below -

NonP *nb = NonP[524288]::Instance();
--

But doing so, I get error message as -

"type name is not allowed"

Could anyone give the correct semantics for above (i)

~BR
 
A

abhay.burli

Dear All. [...]
Now I wish to perform sole instance for below statement (i) using
above Singleton Instance() API call,  originialy NonP is basically a
class.

Do you want a generic Singleton class that you can use to create
singletons in your App?
If Yes, you can construct one on the following lines that i am using
on *WINDOWS* platform; you can modify it using preprocessor for
different platforms (Ex. to use POSIX APIs) or just ignore the
locks!.

-->header "Singleton.h"
/
*******************************************************************************
NOTE: THIS IS NOT A MEYER'S IMPLEMENTATION OF SINGLETON. THAT VERSION
THOUGH
PERFECTLY O.K. HAS U.B. IF TWO STATIC OBJECTS S1 AND S2 ARE USED IN
THE
INITIALIZATION. S1 IS THE SINGELTON AND USES S2 WHICH IS JUST ANOTHER
STATIC
OBJECT FOR INITIALIZATION. BUT S1 GETS INITIALIZED FIRST FOLLOWED BY
S2. THE
DESTRUCTION OF S2 HAPPENS BEFORE S1, THUS IF S1 USES S2 ANYWHERE AFTER
S2's
DESTRUCTION WE HAVE A POTENTIALLY UNSOLVABLE PROBLEM IN C++. SO HEAP
ALLOCATED
SINGLETONS ARE GENERALLY PREFERRED. EVEN IF S2 WERE DECLARED FIRST TO
CONTROL
THE ORDER OF INITIALIZATION, IT MAY NOT WORK IN MULTI-THREADED
ENVIRONMENTS
LEADING TO SUBTLE/NASTY BUGS. HENCE THIS IMPLEMENTATION.
********************************************************************************/

// header that defines a generic singleton
#ifndef __SINGLETON_H__
#include <Windows.h>

// we first need the synchronization mechanism in C++ as it does not
have
// built-in multi-threading runtime and atomic locks
class CriticalSection{
public:
explicit CriticalSection(){
InitializeCriticalSection(&cs);
}
~CriticalSection(){
DeleteCriticalSection(&cs);
}
inline
void Enter(){
EnterCriticalSection(&cs);
}
inline
void Leave(){
LeaveCriticalSection(&cs);
}
private:
// prevent copying and use of free
void free(size_t siz);
CriticalSection& operator =(const CriticalSection& ); // no
assignment
CriticalSection(const CriticalSection& );// copy ctor

CRITICAL_SECTION cs;
};

// wrapper for locking
class Lock
{
public:
Lock(CriticalSection& aCS):CS(aCS) {
CS.Enter();
}
~Lock() {
CS.Leave();
}
private:
CriticalSection& CS;
};

// create the Singleton class using templates
template<class T>
class TSingleton{
public:
static T& getInstance(); // the global access method
protected: // no direct instantiation but can be subclassed
explicit TSingleton(){
}
virtual ~TSingleton(){
}
private:
// no copying business
TSingleton& operator =(const TSingleton& );
TSingleton(const TSingleton& );
// no freeing also
void free(size_t siz);
// create a friendly class that manages the singleton access
class AutomaticInstance;
friend class AutomaticInstance;
class AutomaticInstance
{
public:
AutomaticInstance():p(NULL) {}
~AutomaticInstance() {delete p;}
void set(T* ap) {p=ap;}
T* get() const {return p;}
private:
T* volatile p; // avoid compiler optimizations
};
static AutomaticInstance TheInstancePointer;
static CriticalSection InstanceCreationCritical;
};

// this is the heart of singleton implementation.
// it creates the ONE AND ONLY instance
template<class T>
T& TSingleton<T>::getInstance(){
if(!TheInstancePointer.get()){ // if the instance does not already
exist
Lock cslock(InstanceCreationCritical); // enter CS for synched
access
if(!TheInstancePointer.get()) // necessary check !!
TheInstancePointer.set(new T);
// Lock released here -- by its dtor
}
return *(TheInstancePointer.get());
}

// define the static variables
template<class T>
typename TSingleton<T>::AutomaticInstance
TSingleton<T>::TheInstancePointer;
template<class T>
CriticalSection TSingleton<T>::InstanceCreationCritical;

#define __SINGLETON_H__
#endif

-->The implementation file Main.cpp

#include "Singleton.h"
#include <iostream>

class MySingleton : private TSingleton<MySingleton> {
friend class TSingleton<MySingleton>;
public:
using TSingleton<MySingleton>::getInstance; // make the instance
getter visible ...
void Hello() {
std::cout<<"[Hello]\n";
}
protected:
MySingleton() {}
};

int main(){
MySingleton &m = MySingleton::getInstance();
m.Hello();
// check if different addresses are returned ??
if (&MySingleton::getInstance() != &MySingleton::getInstance())
std::cout<<"[OOPS! FAKE SINGLETON]";

return 0;
}

NOTE: This solution may not be perfect, there are many ways of
implementing singletons, ...

HTH
Abhay
 
C

Codeplug

> Do you want a generic Singleton class that you can use to create
> singletons in your App?
> If Yes, you can construct one on the following lines that i am using
> on *WINDOWS* platform; you can modify it using preprocessor for
> different platforms (Ex. to use POSIX APIs) or just ignore the
> locks!.
Your "double check locking" is broken on all windows compilers, except
for MSVC version 14 or higher - which (unfortunately) added
multi-threaded semantics to the volatile keyword. Otherwise, "volatile"
has absolutely nothing to do with multi-threaded programming.

For reference, here's my version of a thread-safe, efficient singleton
for Windows and Posix platforms (when such a beast is truly needed):
http://www.codeguru.com/forum/showpost.php?p=1804120&postcount=18

gg
 
A

abhay.burli

Your "double check locking" is broken on all windows compilers, except
for MSVC version 14 or higher - which (unfortunately) added
multi-threaded semantics to the volatile keyword. Otherwise, "volatile"
has absolutely nothing to do with multi-threaded programming.

Yeah indeed. I have read http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf,
and that is why i said this code may not be a perfect implementation.
But looks like i have been lucky so far with this code :)
For reference, here's my version of a thread-safe, efficient singleton
for Windows and Posix platforms (when such a beast is truly needed):http://www.codeguru.com/forum/showpost.php?p=1804120&postcount=18

Thanks for the same.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top