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 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users