singleton template

[Nick Keighley]

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?
--
Nick Keighley

[mlimber]

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++.

Cheers! --M

[Tilman Kuepper]

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...?!

The solution was to move the implementation of the instance()
method from the .h to the .cpp file.

Hope it helps...
Tilman

[Nick Keighley]

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.

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]

"Nick Keighley" <ni******************@hotmail.comwrote in message
news:11**********************@b68g2000cwa.googlegr oups.com

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?

Compiler bugs aside, I think this could only be a problem with a
multi-threaded application.

http://blogs.msdn.com/oldnewthing/ar.../08/85901.aspx
--
John Carson

[mlimber]

Nick Keighley wrote:

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/Curious...mplate_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<AtheA;

void Foo()
{
theA::Instance().DoSomething();
}

Cheers! --M

[Nick Keighley]

Tilman Kuepper wrote:

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...?!

The solution was to move the implementation of the instance()
method from the .h to the .cpp file.

Hope it helps...
Tilman

[Nick Keighley]

Tilman Kuepper wrote:

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...?!

The solution was to move the implementation of the instance()
method from the .h to the .cpp file.

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]

Tilman Kuepper wrote:

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_releas...0Bugs%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]

Tilman Kuepper wrote:

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?
--
Nick Keighley

Programming should never be boring, because anything
mundane and repetitive should be done by the computer.
~Alan Turing

[John Carson]

"Nick Keighley" <ni******************@hotmail.comwrote in message
news:11**********************@p79g2000cwp.googlegr oups.com

Tilman Kuepper wrote:

>Hi Nick,

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?

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]

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"...
--

Frederick Gotham

[Tilman Kuepper]

Hi Nick,

>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]

Tilman Kuepper wrote:

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]

Frederick Gotham wrote:

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]

Nick Keighley <ni******************@hotmail.comwrote:

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