Static member variables in template class.

[Graham Dumpleton]

When you have a template class with a static member variable, ie.,

template<typename T>
class handle
{
public:
static void* id() { return &id_; }
private:
static int id_;
};

template<typename T> int handle<T>::id_ = 0;

the compiler is supposed to ensure that for "each" typename T, there
is one and only one copy of the static "id_" variable.

In practice however, how widely is this implemented properly?

I know that in the past some compilers wouldn't event create the
space for the static "id_" variable and it was necessary to explicitly
define them in one spot. For example, it would have been necessary
to enumerate for all T of interest, something like:

int unique<int>::id_ = 0;
int unique<float>::id_ = 0;

Are things better now than they used to be? Are there any modern
compilers which still have strange caveats like this?

What I am hoping to be able to do is to use the address of that static
variable as a unique marker for a type. That is:

template<typename T> void* id1() { return handle<T>::id(); }

cout << "marker<int> = " << id1<int>() << endl;

There is also a simpler version one could write:

template<typename T> void* id2() { static int i = 0; return &i; }

But how portable are such constructs across currently available and
not so current compilers? Can use of shared libraries/dlls complicate
the issue?

Thanks in advance.

 

[Rolf Magnus]

When you have a template class with a static member variable, ie.,

template<typename T>
class handle
{
public:
static void* id() { return &id_; }
private:
static int id_;
};

template<typename T> int handle<T>::id_ = 0;

the compiler is supposed to ensure that for "each" typename T, there
is one and only one copy of the static "id_" variable.

In practice however, how widely is this implemented properly?

I know that gcc 2.95 doesn't do it properly, but 3.0 and up does. I
can't tell anything about other compilers.

 

[David Baraff]

Currently on darwin (and I saw this on windows at one point) you'll
get a separate instance per shared library. On linux with g++, it
works as you would hope (and possibly expect).

The trick to making this work is to make the static member variable be
a pointer and be prepared to separately initialize each copy to point
to the same single object. For example, the first time you go to
access this static member variable pointer, be prepared for it to be
NULL, and then rather than calling new, go to some centralized library
routine which is responsible for seeing if you're the first one to
access the underlying object you really want. If so, it gets new'd up
and handed back to you, and you make *your* version of the static
member teamplte pointer point at this new object. Otherwise, you're
not the first, so you don't do a new, but you still get back a pointer
and set the static tempalte member pointer to point to the object.

As the C++ lawyers will tell you, "if it involves shared libraries,
it's outside the C++ standard."

Which effectively means just about everything is outside the standard
these days...

 

[Graham Dumpleton]

Currently on darwin (and I saw this on windows at one point) you'll
get a separate instance per shared library. On linux with g++, it
works as you would hope (and possibly expect).

The trick to making this work is to make the static member variable be
a pointer and be prepared to separately initialize each copy to point
to the same single object. For example, the first time you go to
access this static member variable pointer, be prepared for it to be
NULL, and then rather than calling new, go to some centralized library
routine which is responsible for seeing if you're the first one to
access the underlying object you really want. If so, it gets new'd up
and handed back to you, and you make *your* version of the static
member teamplte pointer point at this new object. Otherwise, you're
not the first, so you don't do a new, but you still get back a pointer
and set the static tempalte member pointer to point to the object.

Unfortunately one doesn't have a string or otherwise to use as the
key in allocating the handle in the centralised repository. This is
because I am trying to have that be automatically bound to the type
of the parameter to the template without special user intervention
to supply a string which identifies the type. If the user was required
to supply the string, wouldn't need the template at all for what I had
in mind.

Anyway, in terms of what I was trying to achieve, I have come across
other problems and so have to do it a totally different and more
verbose way after all.

Thanks though, it confirms my suspicion that it may not have been
portable.

As the C++ lawyers will tell you, "if it involves shared libraries,
it's outside the C++ standard."

Which effectively means just about everything is outside the standard
these days...

And we better make sure we don't top post either. ;-)

 

[David Baraff]

key in allocating the handle in the centralised repository. This is
because I am trying to have that be automatically bound to the type
of the parameter to the template without special user intervention
to supply a string which identifies the type. If the user was required
to supply the string, wouldn't need the template at all for what I had
in mind.

template <typename T>
struct Cache {
static Data* _ptr;

static Data* GetData() {
if (!_ptr) _ptr =
CentralizedRegistry::GetOrCreateData(typeid(T));
return _ptr;
}
};

The routine CentralizedRegistry::GetOrCreateData() uses the passed in
type_info as a key, and either retrieves a previously created Data*,
or creates one for the first time and stores it under the specified
key. Either way, a Data* is returned. For each type T, the routine
is called at most once per shared library.