What you describe here is the opposite of what is stated in the lib.As far as I understand the author's intention by declaring a global variable static: introdcution of an own copy of this var in each compilation unit.
I suggested a workaround with anon namespace. What you suggest by introducing a static var in a class template is not the same, because it actually creates an instance of static variable per template class. I assume the global var in each compilation unit was required due to some threading issues (or access issues), because the order or initialization global variables in compilation units is not defined. Therefore, initializing a static var in one compilation and then using it in another (from global scope) might result in accessing an undefined variable. Schwarz Counter paradigm might help. But first we should know what was the intention of such a use case, before doing suggestions ;)
Regards,
Ovanes
On Wed, Jul 14, 2010 at 1:13 PM, Hite, Christopher
<Christopher.Hite@partner.commerzbank.com> wrote:
> I think it is not the same as defining a global static variable.
Global
> static variable will have internal linkage and therefore be visible
inside
> the compilation unit where defined only. Between the compilation units
these
> variables will be different.
No the fancy trick works. I've seen it used in XSD-tree's code which is
completly a header only. They put all their globals in a template class
with a single parameter char. MyClass<char>::variable has to be the
same in all compilation scopes. The standard says so. So the linker
has to eliminate duplicate symbols.
> IMO C++ like approach would be to introduce an
> anonymous namespace in header files and define global variables there.
> Defining static vars in the template class will result in a static
variable
> per class template instantiation. Which is not exactly the same, as
intended
> here.
Anonymous namespaces in headers are bad; as are declaring things static
in headers. It makes the compiler generate seperate objects per
compilation scope, which isn't what you want.
The compiler warning is right. If I include this header in 20
compilation scopes I shouldn't have 20 copies of these constants (just
refs) in my binary.
At least the stuff in boost/system/error_code.hpp could easily be moved
to a cxx. Boost::system is not a header only library.
Chris