Annoying compiler warnings in asio/error.hpp
/fs/tools/L1/boost_1_43_0/boost/asio/error.hpp: At global scope: /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:353: warning: 'boost::asio::error::system_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:355: warning: 'boost::asio::error::netdb_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:357: warning: 'boost::asio::error::addrinfo_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:359: warning: 'boost::asio::error::misc_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:361: warning: 'boost::asio::error::ssl_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:208: warning: 'boost::system::system_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:209: warning: 'boost::system::generic_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:214: warning: 'boost::system::posix_category' defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:215: warning: 'boost::system::errno_ecat' defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:216: warning: 'boost::system::native_ecat' defined but not used Code defines static variables in header which is bad form. static const boost::system::error_category& system_category = boost::asio::error::get_system_category(); In gcc the warning could be disabled with -Wno-unused-variable, but that disables valuable warnings. Are these variables really needed? They theoretically create a word per compilation scope. A cleaner alternative would be to just call the function where needed. If you really need to define global variables in a header only library, you can define static members of a template class. It's a fancy trick (not sure if it has a name). Perhaps there are portablity issues with it. Chris
Chris, please see my answer below.
If you really need to define global variables in a header only library, you can define static members of a template class. It's a fancy trick (not sure if it has a name). Perhaps there are portablity issues with it.
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. 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. Regards, Ovanes
On Tue, Jul 13, 2010 at 2:39 AM, Hite, Christopher
/fs/tools/L1/boost_1_43_0/boost/asio/error.hpp: At global scope: /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:353: warning: ‘boost::asio::error::system_category’ defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:355: warning: ‘boost::asio::error::netdb_category’ defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:357: warning: ‘boost::asio::error::addrinfo_category’ defined but not used
/fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:359: warning: ‘boost::asio::error::misc_category’ defined but not used /fs/tools/L1/boost_1_43_0/boost/asio/error.hpp:361: warning: ‘boost::asio::error::ssl_category’ defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:208: warning: ‘boost::system::system_category’ defined but not used
/fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:209: warning: ‘boost::system::generic_category’ defined but not used
/fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:214: warning: ‘boost::system::posix_category’ defined but not used
/fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:215: warning: ‘boost::system::errno_ecat’ defined but not used /fs/tools/L1/boost_1_43_0/boost/system/error_code.hpp:216: warning: ‘boost::system::native_ecat’ defined but not used
Code defines static variables in header which is bad form.
static const boost::system::error_category& system_category = boost::asio::error::get_system_category();
In gcc the warning could be disabled with -Wno-unused-variable, but that disables valuable warnings.
It might be a good idea then to file a bug report with GCC requesting that the two warnings be separated.
If you really need to define global variables in a header only library, you can define static members of a template class. It's a fancy trick (not sure if it has a name). Perhaps there are portablity issues with it.
I'm sure there are plenty of creative ways to obfuscate your code. Ideas, anyone? :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
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
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
participants (3)
-
Emil Dotchevski -
Hite, Christopher -
Ovanes Markarian