Emil Dotchevski wrote:
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.
How about a BOOST_SYSTEM_NO_ENUM macro, which suppresses the system specific enum?
Perhaps the enum should be placed in a platform-specific header, for example "boost/system/windows/error_code.hpp"?
Also, how do you feel about replacing the OS-specific enums with plain ints? This way, I can compare error codes directly to the values from <winerror.h> (I understand that enums give us type safety, but unfortunately they can not be incomplete types, which leads to physical coupling and causes the kind of problems I'm hitting with error_code.hpp.)
The change to enums was made at the request of the C++ committee's library working group, and is reflected in the C++0x standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf. I want Boost.System to track the standard as closely as possible. Although the enums take some getting used to, they allow some really useful overloading that cannot be achieved with int's. That overloading (worked out by Chris Kohlhoff) is the key to being able to write both portable and platform-specific code with equal facility. 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. --Beman