Re: [boost] [system] Problem with error_code.hpp dependency on winerror.h

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-10-31 19:50:04

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