Singleton syntax for managed code?  
Author Message
LouArnold





PostPosted: Visual C++ Language, Singleton syntax for managed code? Top

Is there an appropriate syntax for a singleton for managed code

The classic, basic singleton is:
--
[code]
class Singleton
{
public:
static Singleton* Instance();
protected:
Singleton();
private:
Singleton(const Singleton&);
static Singleton* xinstance;
};
//implementation:
#include "Singleton.h"
// Implementation
Singleton* Singleton::xinstance = 0;

Singleton::Singleton(){};
Singleton::Singleton(const Singleton&){};

Singleton* Singleton::Instance() {
if (xinstance == 0) {
xinstance = new Singleton;
}
return xinstance;
}
[/code]

How does the aboive change for managed code beyond adding the "ref" keyword before the class declaration


Visual C++12  
 
 
pintu*





PostPosted: Visual C++ Language, Singleton syntax for managed code? Top

Have a look on this
http://www.codeguru.com/forum/showthread.php t=393350&highlight=singelton

Thanx


 
 
LouArnold





PostPosted: Visual C++ Language, Singleton syntax for managed code? Top

I'm not sure what you're trying to tell me by sending me to that URL. I read it and further links and none seem relevent to my question. I'm asking about "managed code"; the point being that managed code has garbage collection among other "things" and I wanted constructs to make it compatible with those "things".

 
 
einaros





PostPosted: Visual C++ Language, Singleton syntax for managed code? Top

There are a number of MSDN and MSFT blog notes on singletons, as well as common problems one run into with them.

Some links, in no particular order (except the last, which is a very important read):

While all of these articles focus mainly on C#, the same principle stands for C++/CLI. Some ^'s and gcnew's, and the language border shouldn't be a problem. Feel free to ask if you run into more problems.



 
 
LouArnold





PostPosted: Visual C++ Language, Singleton syntax for managed code? Top

OK, I read the first two references earlier. The third was interesting.

I assume there is nothing more in terms of .Net compatibility than what is in these three references.
Thanks very much.