boost::system::(...)_category defined but not used

Question

I'm currently getting compiler warnings that resemble the warning I gave in the question title. Warnings such as....

warning: 'boost::system::generic_category' defined but not used

warning: 'boost::system::posix_category' defined but not used

warning: 'boost::system::errno_ecat' defined but not used

warning: 'boost::system::native_ecat' defined but not used

As far as I know the program isn't being affected in any way. However, I don't like warnings hanging around, but I have no idea what these warnings are trying to tell me besides that something defined and related to boost is hanging around somewhere not being used. However, everything that I've defined, I've used. The boost libraries I'm using are the random library and the filesystem library.

When I check the source of the warning it brings up Boost's error_category.hpp file and highlights some static consts that are commented as either "predefined error categories" or "deprecated synonyms". Maybe the problem has something to do with my error handling (or lack of) when using the library?

Can anyone give some insight regarding why these warnings are popping up? Am I completely missing something?

P.S. Warnings are at max level.

Answer 1

I agree with @Charles Salvia, but wanted to add that at least as of Boost 1.44.0, these definitions are now wrapped -- to be excluded as deprecated. So if you aren't using them, just include the following lines before you include the header file:

#ifndef BOOST_SYSTEM_NO_DEPRECATED
#define BOOST_SYSTEM_NO_DEPRECATED 1
#endif

Answer 2

This relates to the error_code library in the Boost.System library. Boost error_codes contain two attributes: values and categories. In order to make error_codes extensible so that library users can design their own error categories, the boost designers needed some way to represent a unique error code category. A simple ID number wouldn't suffice, because this could result in two projects using conflicting ID numbers for custom error categories.

So basically, what they did was to use memory addresses, in the form of static objects that inherit from the base class error_category. These variables don't actually do anything except to serve as unique identifiers of a certain error category. Because they are essentially static dummy objects with unique addresses in memory, you can easily create your own custom error categories which won't interfere with other error category "IDs." See here for more information.

I suppose that what you're seeing is a side-effect of this design decision. Since these variables are never actually used in your program, the compiler is generating warnings. Suffice it to say, I don't think you're doing anything wrong.