Re: Multiple definition and specialization of static data member
Wu Yongwei wrote:
I posted the following message days ago to comp.std.c++, and got an
helpful answer from Alberto Ganesh Barbati. However, I would like to
hear more comments from you gurus here, esp. whether the behaviour of
MSVC 8 is standard conforming, best with quotations from the Standard.
-------------------------------
I encountered a problem in a header file like the following:
template <typename DataType>
class FMC
{
public:
static DataType Epsilon;
private:
FMC() {}
};
template <typename DataType>
DataType FMC<DataType>::Epsilon = static_cast<DataType>(0.000001);
This is the definition of Epsilon, a static data member of the class
template FMC. Placing this definition in a header file is likely to
prove problematic and for the reasons described. Essentially every
source file that instantiates Epsilon will also define it - leading to
a multiply-defined symbol error at link time.
template <>
double FMC<double>::Epsilon = static_cast<double>(0.0000000001);
This statement is an explicit specialization for Epsilon when FMC is
instantiated with the type double. Note that the presence of an
initializer for Epsilon makes this statement a definition - and not a
declaration - of the explicit specialization. Once again, placing a
definition in a header file is bound to to lead a multiply-defined
symbol error if more than one file references FMC<double>::Epsilon.
When multiple .cpp files include this header file, GCC 3.4.4 (or some
earlier version) will complain:
...: multiple definition of `FMC<double>::Epsilon'
...
To make GCC work, I have to reorganize the header file as follows:
- In header file
template <typename DataType>
class FMC
{
public:
static DataType Epsilon;
private:
FMC() {}
};
template <typename DataType>
DataType FMC<DataType>::Epsilon = static_cast<DataType>(0.000001);
Well, this definition staying in the header file can mean only one
thing: and that is that we probably have not seen the last of the
multiply-defined symbol error.
template <>
double FMC<double>::Epsilon;
This line in contrast has changed - and changed for the better.
Removing the initializer has transformed an explicit specialization
definition into an explicit specialization declaration. And the
declaration has the opposite affect of the definition. It inhibits the
instantiation of the FMC<double>::Epsilon in source files that
reference it - unless that source file has FMC<double>::Epsilon's
definition. So moving the definition of the explicit specialization
into a source file ensures that the program defines the static data
member only once - no matter how many source files actually reference
it.
- In another .cpp file
#include "fmc.h"
template <>
double FMC<double>::Epsilon = static_cast<double>(0.0000000001);
However, then MSVC 8 will choke and declare that the definition in the
.cpp file is a redefinition. It works with the original version.
My question is, which way is the standard-conforming way? and which
compiler is standard conformant on this issue?
Before we can judge the compilers, we need to get the program into a
working state. And the structure of this program as we last left it,
has only a very limited fix for the Epsilon's multiple definition
problem. In fact it only works in one particular Epsilon - the Epsilon
for FMC<double>.
So as matters stand, if the program tries to instantiate FMC with a
type other than double, and then references that template's Epsilon in
more than once source file - than the exact same problem would happen
again. And in fact I would bet it is exactly this re-emergence that
explains why MSVC 8 failed to compile. Especially since the error as
you originally posted in comp.std.c++ mentioned FMC<float> explicitly -
which is exactly the kind of type that we know would trigger the error
reported.
The all-around fix is to move Epsilon's general template definition out
of the header file completely and into one of the source files. The
general class template Epsilon is already declared by FMC's class
template declaration; so all that the program has left to do is to
define it - and to define it once and one time only. And moving the
definition into a source file will achieve precisely that effect.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]