Re: question on static member for class template
Alberto Ganesh Barbati wrote:
Greg Herlihy ha scritto:
James Kanze wrote:
Chimanrao wrote:
#include <iostream>
#include <string>
struct type_record
{
type_record(const std::string& str)
{
std::cout << str << "\n";
}
};
template <typename T>
class helper
{
private: // nothing uses the following member
static type_record reg;
};
In order to trigger an instatiation, it is necessary to use the
object in some way. Perhaps by adding a constructor to helper:
helper() { ® }
(Even this won't suffice in the exact code above, but in almost
all real cases, it should be enough.)
In this case this trick it's not necessary, because the OP is using
explicit instantiation of the class template.
I didn't see an explicit instantiation of helper<char>, which is
the class for which the constructor of the static object is
missing. Unless the template is designed to be used exclusively
with static initialization, he really should take whatever steps
needed to ensure that the parts he needs do get instantiated.
Most of the time, no special action is necessary. If you
declare a static member, you also use it in the various
functions of the class, and when any one of these functions is
instantiated, it triggers instantiation of the static member.
There are a few exceptions, however---if the static member
exists just so that it's constructor can register something, for
example. In such cases, an artificial reference, as above, can
be used.
Greg is right about one thing, however: such a line of code can
cause more than a little confusion in a reader. I'd suggest a
very clear comment as to why the line of code is there.
Explicit instantiation will always instantiate all class
members, including static data members (?14.7.2/7).
Which is why he saw the output for the constructors of the
static member of the explicitely instantiated instances.
(Unless I've missed something---very possible, when templates
are concerned---, the code still has undefined behavior, because
he never defines the static member, only declares it. Is there
a special rule that applies here?)
To instantiate a template class object explicitly, it is best to use
the syntax that the C++ language has defined for this very purpose.
Explicit instantiation of a complete class - or of an individual member
- does not require that the instantiated object (or member) also be
"used" somewhere in the program.
Here is the explicit instantiation of helper<char>::ref:
template type_record helper<char>::reg;
The actual syntax is:
template<> type_record helper<char>::reg ;
.. But that's not the point. This causes the object to be
instantiated even if the class is never used. The goal is that
helper<char>::reg will be instantiated if, and only if,
helper<char> is instantiated somewhere else. The problem is
that the class is a template, and that the author of the class
does not want to specify explicitly the instantiations, and in
fact cannot, since the class can also be instantiated over user
defined types which the author of the class has never heard of.
And of course, the author of the class doesn't want to impose on
every user that he write such a statement.
In the OP's case, this is redundant. As I said before, the static data
member shall already be instantiated by the explicit instantiation of
the class.
No it didn't.
James Kanze's trick is useful to force the instantiation of the static
data member even if the class is *implicitly* instantiated. In this case
you suggestion doesn't help.
However, I agree that a statement like "®" is a bit too cryptic
(imagine an HTML expert surprised to see a registered trademark in C++
code :-D). Moreover, the absence of side-effects might tempt aggressive
compiler to optimize the statement away.
Actually, it is my hope that the compiler optimize it away:-).
I don't really want any code generated for it. But the language
rules still hold---even if the compiler optimizes the statement
away, the statement will have triggered the instantiation of the
definition, which is all we wanted.
As for being too cryptic, I agree that a comment would be in
order. And I certainly won't insist on that particular way of
writing the reference; if you have a better suggestion, I'm all
for it. It was just the first thing that came to my head as a
means of using the object without actually using it.
Maybe wrapping the idiom inside a function could make it more
readable and avoid the problem. For example:
volatile void* ptr;
template <class T>
inline void force_instantiation_of(T& x) { ptr = &x; }
You don't need the volatile, and you don't need the pointer.
Compiler optimizations are not allowed to change the semantics
of the program, except in a very few, special cases (and this
isn't one of them).
I actually like the idea, but the function could be simply:
template< typename T >
inline void force_instantiation_of( T& ) {}
Calling the function is a reference to the object, and so
triggers the instantiation. No more is needed.
template <typename T>
class helper
{
public:
~helper() { force_instantiation_of(reg); }
private:
static type_record reg;
};
Notice that force_instantiation_of has a side effect so it can't be
optimized away. However this force_instantiation_of has a non-null cost.
Whether the actual function is opimized away or not is
irrelevant. The semantics of the program must be the same as if
it were not optimized away. My version of the function
shouldn't have any run-time cost, as long as the compiler
doesn't have inlining completely turned off. (My initial
version shouldn't have any run-time cost, even if all
optimizations, including inlining, are turned off.)
Maybe we could propose a library function that does just that:
force an object to marked as "used" (in the sense that the
linker can't strip it away) without actually doing nothing.
What do you think?
Why not? Although I'm not sure it's important enough to warrent
being in the standard.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]