singleton template
Nick Keighley
I found this in code I was maintaining
template <class SingletonClass>
SingletonClass* Singleton<SingletonClass>::instance ()
{
static SingletonClass _instance;
return &_instance;
}
there are indications that the constructor is getting called more than
once
in some circumstances (tracing in one of the instantiations of the
template).
Are there potential problems with the use of static data?
--
Nick Keighley
mlimber
There are sometimes, but there's nothing inherently wrong with this
code (you might consider using references instead, however). See
chapter 6 of _Modern C++ Design_ for more than you ever wanted to know
about singletons in C++.
Cheers! --M
Tilman Kuepper
> there are indications that the constructor is getting called more
> than once in some circumstances (tracing in one of the
> instantiations of the template).
>
> Are there potential problems with the use of static data?
I had exactly this problem when using Visual C++ 6.0. But only
in Release mode, not in Debug mode. Perhaps a problem with
the optimizer...?!
The solution was to move the implementation of the instance()
method from the .h to the .cpp file.
Hope it helps...
Tilman
Nick Keighley
comfortable with templates.
For instance something like this:-
class PerformanceDataItemIniFile : public PanelIniFile,
public Singleton< PerformanceDataItemIniFile >
...
worries me it inherits from something that uses itself as a parameter.
--
Nick Keighley
John Carson
news:1151930097.3...@b68g2000cwa.googlegroups.com
Compiler bugs aside, I think this could only be a problem with a
multi-threaded application.
http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx
--
John Carson
mlimber
> mlimber wrote:
> > Nick Keighley wrote:
> > > Hi,
> > >
> > > I found this in code I was maintaining
> > >
> > > template <class SingletonClass>
> > > SingletonClass* Singleton<SingletonClass>::instance ()
> > > {
> > > static SingletonClass _instance;
> > > return &_instance;
> > > }
> > >
> > > there are indications that the constructor is getting called more than
> > > once
> > > in some circumstances (tracing in one of the instantiations of the
> > > template).
> > >
> > > Are there potential problems with the use of static data?
> >
> > There are sometimes, but there's nothing inherently wrong with this
> > code (you might consider using references instead, however). See
> > chapter 6 of _Modern C++ Design_ for more than you ever wanted to know
> > about singletons in C++
> .
> thanks, I keep on meaning to getting around to MCD, but I am not
> comfortable with templates.
You might want to try to look through at least chapter 6 because he
discusses some of the pitfalls with singletons in C++ (including in
multithreading, longevity, etc.) and ways to handle them.
> For instance something like this:-
>
> class PerformanceDataItemIniFile : public PanelIniFile,
>
> public Singleton< PerformanceDataItemIniFile >
> ...
>
> worries me it inherits from something that uses itself as a parameter.
That's the Curiously Recurring Template Pattern (see, e.g.,
http://en.wikipedia.org/wiki/Curiously_Recurring_Template_Pattern) and
can be quite useful. However, with singletons, I would expect to see
something more like this for your template class:
template<class T>
class Singleton
{
public:
static T& Instance();
private:
// Disabled functions
Singleton();
Singleton( const Singleton& );
Singleton& operator=( const Singleton& );
Singleton* operator&();
~Singleton();
};
template<class T>
T& Singleton<T>::Instance()
{
static T myObject;
return myObject;
}
Which is not inherited from but used as a wrapper like this:
class A
{
private:
// Private constructor/destructor disallows creation
// except by friends.
friend class Singleton<A>;
A();
~A();
// Disabled functions for singleton usage
A( const A& );
A& operator=( const A& );
A* operator&();
public:
void DoSomething();
// ...
};
Singleton<A> theA;
void Foo()
{
theA::Instance().DoSomething();
}
Cheers! --M
Nick Keighley
Nick Keighley
oops posted message with no additional text!
by a strange coincidence I'm using VCC 5 and the fault only occurs in
the
Release version...
--
Nick Keighley
Programming should never be boring, because anything
mundane and repetitive should be done by the computer.
~Alan Turing
mlimber
> Hi Nick,
>
> > there are indications that the constructor is getting called more
> > than once in some circumstances (tracing in one of the
> > instantiations of the template).
> >
> > Are there potential problems with the use of static data?
>
> I had exactly this problem when using Visual C++ 6.0. But only
> in Release mode, not in Debug mode. Perhaps a problem with
> the optimizer...?!
Possible but it seems more likely that this is symptomatic of other
latent problems. See "Surviving the Release Version" by Joseph M.
Newcomer:
http://www.flounder.com/debug_release.htm
Particularly, this section:
http://www.flounder.com/debug_release.htm#Compiler%20Bugs%20(again)
> The solution was to move the implementation of the instance()
> method from the .h to the .cpp file.
That's generally a bad idea. Absent the export keyword, for
maintainability the function should be in the header. Duplicating it by
hand in every file that needs it is a maintenance nightmare. (I should
note that one of my compilers complained if I defined the Instance()
function given elsewhere in this thread inline in the class definition,
but moving it outside the class definition but still in the header file
quelled the complaint but kept maintenance the same.)
Cheers! --M
Nick Keighley
> Hi Nick,
oops posted message with no additional text!
> > there are indications that the constructor is getting called more
> > than once in some circumstances (tracing in one of the
> > instantiations of the template).
> >
> > Are there potential problems with the use of static data?
>
> I had exactly this problem when using Visual C++ 6.0. But only
> in Release mode, not in Debug mode. Perhaps a problem with
> the optimizer...?!
by a strange coincidence I'm using VCC 5 and the fault only occurs in
the
Release version...
> The solution was to move the implementation of the instance()
> method from the .h to the .cpp file.
err, it's a template- doesn't it all have to go in the header file?
John Carson
> Tilman Kuepper wrote:
>> Hi Nick,
>>
>> in Release mode, not in Debug mode. Perhaps a problem with
>> the optimizer...?!
>
> by a strange coincidence I'm using VCC 5 and the fault only occurs in
> the
> Release version...
>
>
>> The solution was to move the implementation of the instance()
>> method from the .h to the .cpp file.
>
> err, it's a template- doesn't it all have to go in the header file?
Template definitions need to be visible to the compiler in the translation
unit in which they are used. Putting them in the header file is the easiest
way to ensure this. However, if, for example, a function is only called in
file.cpp, then there is no problem if you define the function in file.cpp.
--
John Carson
Frederick Gotham
> Template definitions need to be visible to the compiler in the
> translation unit in which they are used.
Unless of course we use "export"...
--
Frederick Gotham
Tilman Kuepper
>> The solution was to move the implementation of the instance()
>> method from the .h to the .cpp file.
>
> err, it's a template- doesn't it all have to go in the header file?
In my case it was without templates, so I had no problems to
remove the implementation from the header file. Nevertheless
it may be possible that we both found the same problem in the
compiler/optimizer.
Perhaps you can replace the template by separate classes
for the different Singletons?
You might also try to move the template implementation to
a .cpp file using explicit instantiation.
Good luck,
Tilman
Nick Keighley
> >> The solution was to move the implementation of the instance()
> >> method from the .h to the .cpp file.
> >
> > err, it's a template- doesn't it all have to go in the header file?
>
> In my case it was without templates, so I had no problems to
> remove the implementation from the header file. Nevertheless
> it may be possible that we both found the same problem in the
> compiler/optimizer.
I suspect you might be right
> Perhaps you can replace the template by separate classes
> for the different Singletons?
there are only 324 instantiations of the template...
> You might also try to move the template implementation to
> a .cpp file using explicit instantiation.
>
> Good luck,
one of the websites I was pointed out discusses the problems
of Release/Debug. Turning off optimisation may be the easiest fix
(the bug is showing up on the client/gui side of the system- so
it is probably less in need of optimisation)
--
Nick Keighley
Nick Keighley
> John Carson posted:
> > Template definitions need to be visible to the compiler in the
> > translation unit in which they are used.
>
>
> Unless of course we use "export"...
I have the strangest feeling I'd have a problem with "export"...
What is support like for "export" on current compilers? (I'm not
using a current compiler, yes I know)
--
Nick Keighley
Marcus Kwok
> What is support like for "export" on current compilers? (I'm not
> using a current compiler, yes I know)
As far as I know, only the Comeau compiler officially supports it, and I
think the Intel compiler supports it as a hidden feature (it may need a
special command-line option or something).
--
Marcus Kwok
Replace 'invalid' with 'net' to reply