Back to General and Gameplay Programming

Singleton/release build weirdness (VC++ 6)

benjamin bunny · 2003-08-07T13:36:28

I'm using various singleton objects in my engine, all of which are based on the following template: template <class T> class Singleton { public: static T& inst() { static T instance; return instance; } }; Classes derived from have private constructors, to ensure the class is really a singleton. They're declared like this class Foo : public Singleton <Foo> { friend Singleton<Foo>; Foo(); public: ... } This works fine, in debug mode, but when I turn on any optimisations in Visual C++ 6.0, my singleton classes' constructors are called multiple times. It turns out that subsequent calls to inst() after the first call the constructor, even though a static variable is used to instantiate the singleton object. The end result is there are 3 copies of the application, 2 copies of the texture manager, and my program crashes out spectacularly. On further investigation, it appears that although the constructors are called multiple times, the this pointer points to the same block of memory. The problem doesn't occur if I do the same thing without templates. Is this some kind of weird bug with Visual C++'s template support? Has anyone encountered it before? Is VC++ .net likely to fix the problem? ____________________________________________________________ www.elf-stone.com [edited by - benjamin bunny on August 7, 2003 8:08:22 AM]

General and Gameplay Programming Programming

Started by benjamin bunny August 07, 2003 06:20 AM

18 comments, last by benjamin bunny 20 years, 8 months ago

benjamin bunny

838

Author

August 07, 2003 09:52 AM

quote:Original post by fizban75
How about if you try:
..source...

I already tried this approach, but got exactly the same behaviour, strangely enough. Thanks anyway though.

eloso: Thanks for that, but it doesn't work, presumably because the function is in a template.

quote:Original post by Yanroy
...but it seems to me that instead of jumping through hoops to turn off your inlining, you could just define the body of the inst() function in the .cpp file

Yes, that works, but I just like to be able to declare that a class is a Singleton and then use it as such. It seems neater that way.

However, since that isn't possible with VC6.0 I'm forced to abandon the Singleton template altogether. Here's my hacked solution:

//in singleton.h#define SINGLETON_INSTFUNC(type) static type &inst(){static type inst; return inst;}//Foo Singleton declarationclass Foo{  Foo()public:  SINGLETON_INSTFUNC(Foo)}

The end result actually needs less typing than the initial solution, although it isn't exactly elegant.

[edited by - benjamin bunny on August 7, 2003 10:59:41 AM]

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

benjamin bunny

838

Author

August 07, 2003 09:55 AM

... and all this for .5 of a FPS. I quit

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

benjamin bunny

838

Author

August 07, 2003 10:04 AM

quote:Original post by Yanroy
Also, just what purpose does static have when used on a local variable? It is my understanding that static makes variables one-per-translation-unit, but a local gets deallocated at return anyways, so isn''t it redundant?

A static local variable isn''t deallocated at return. It''s essentially a global which can only be accessed by that function, which is initialised the first time the function is called.

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

fizban75

130

August 07, 2003 10:30 AM

quote:
I already tried this approach, but got exactly the same behaviour, strangely enough. Thanks anyway though.

Really? I have a singleton based on this approach that works fine in VC6, even in Release mode. When you tried it, the pointer was a static member of the class and not a local static variable in the function? I could understand you having the same problem in the second case, but not in the first...

paulecoyote

1,065

August 07, 2003 10:39 AM

The original post''s problem is probably caused because the order and of creation and destruction of static variables is not guaranteed.

My solution (as I posted above) DOES use templates, has a singleton manager that ensures things are created and disposed in the correct order, and as a bonus is thread safe. Using the code from that link you can make any class a singleton with only 3 or 4 lines of changes in the original class.

There are cases of singleton creation using statics and the simple way of just returning a new instance to a variable if it''s null IF one thread is swapped out after it''s checked for null, another thread also checks for the null and is clear, then 2 singletons get created but then - of course - you loose track of one of them.

I''m not saying it''s a definitive way of doing things, but at least acknowledge that you took a look at the code! :-)

Anything posted is personal opinion which does not in anyway reflect or represent my employer. Any code and opinion is expressed “as is” and used at your own risk – it does not constitute a legal relationship of any kind.

Odd the Hermit

122

August 07, 2003 10:48 AM

Another templated singleton class (which I use, btw) is proposed in Scott Bilas''s article in Game Programming Gems, which can also be found here with a useful addendum.

-Odd the Hermit

eloso

122

August 07, 2003 10:57 AM

quote:eloso: Thanks for that, but it doesn''t work, presumably because the function is in a template.

Your are right. But the reason is not because the function is in a template but because vc6 is really buggy. Try compiling it with /Ob0 and you''ll see it''s not inlined any more. (like in debug mode)
I know, this is no solution because now none of your functions will be inlined any more, but it works

benjamin bunny

838

Author

August 07, 2003 11:00 AM

quote:Original post by fizban75
quote:
I already tried this approach, but got exactly the same behaviour, strangely enough. Thanks anyway though.

Really? I have a singleton based on this approach that works fine in VC6, even in Release mode. When you tried it, the pointer was a static member of the class and not a local static variable in the function? I could understand you having the same problem in the second case, but not in the first...

Yep. I even tried copying and pasting your code and got the same result.

quote:The original post's problem is probably caused because the order and of creation and destruction of static variables is not guaranteed.

The order has nothing to do with it. A single static variable shouldn't be initialized more than once, regardless of the order.

[edited by - benjamin bunny on August 7, 2003 12:07:34 PM]

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

benjamin bunny

838

Author

August 07, 2003 01:23 PM

Fizban: I just tried your code again, and it worked this time. For some reason VC didn''t build it properly last time. It seems to work now anyway. Problem solved.

Turns out that declaring the inst() method in the classes rather than using a template didn''t work in all cases anyway. The static variable was still contructed multiple times.

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

fizban75

130

August 07, 2003 01:36 PM

quote:
Fizban: I just tried your code again, and it worked this time. For some reason VC didn''t build it properly last time. It seems to work now anyway. Problem solved.

Ah, good to hear. I was a bit suspicious when you first said it didn''t work. ;-)

Singleton/release build weirdness (VC++ 6)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Singleton/release build weirdness (VC++ 6)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines