Boost logo

Boost :

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 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at