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.
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.)
Most (all?) msdn documentation pages say to include <windows.h> to access a part of the win32 api even if it is declared in a different header. I know that when targeting Windows Mobile 5 with VS2005 you get a horde of error messages if you try to include headers like <winuser.h> directly. Couldn't the definitions be changed to something like namespace windows_error { enum windows_error_code { success = 0, // These names and values are based on Windows winerror.h invalid_function = 1, //ERROR_INVALID_FUNCTION ... } } A bit more fragile but removes the dependency on winerror.h Or is this too evil? Thanks, Michael Marcin