Actually, the user *can* use the enum without <winerror.h>.
I see this in error_code.hpp:
namespace windows_error { enum windows_error_code { success = 0, // These names and values are based on Windows winerror.h invalid_function = ERROR_INVALID_FUNCTION, file_not_found = ERROR_FILE_NOT_FOUND, path_not_found = ERROR_PATH_NOT_FOUND, .... } }
I don't understand how this enum can be compiled without including <winerror.h>.
The <boost/error_code.hpp> header already includes <winerror.h>, so the user doesn't have to include it.
Seems like there is some kind of misunderstanding. :) My original problem was triggered by the fact that "boost/error_code.hpp" *attempts* to include <winerror.h>, and on my Windows system <winerror.h> is not accessible "just like that" (I am including "boost/error_code.hpp" in a CPP file which, although being built using MSVC on Windows, does not see the platform SDK because it's platform independent.)
I'll go ahead and put in the BOOST_SYSTEM_NO_ENUM #ifndef. That will at least allow users to avoid the system-specific enums if they wish. But the enums provide a really nice facility for dealing with system-specific errors, so I don't recommend using BOOST_SYSTEM_NO_ENUM except in unusual circumstances.
I wouldn't call compiling platform-independent cpp files on Windows "unusual circumstance". -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode