From: Michael Marcin (mmarcin_at_[hidden])
Date: 2007-11-03 15:32:16


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