Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.

890. Improving<system_error> initialization

Section: 19.5.3[syserr.errcat]Status:C++11Submitter: Beman DawesOpened: 2008-09-14Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [syserr.errcat].

View all issues withC++11 status.

Discussion:

Thestatic const error_category objectsgeneric_category andsystem_category in header<system_error> are currently declared:

const error_category& get_generic_category();const error_category& get_system_category();static const error_category& generic_category = get_generic_category();static const error_category& system_category = get_system_category();

This formulation has several problems:

• Implementation details are exposed, since initialization is specified inthe interface. This over-constrains implementations without offsettinguser benefits. The form of initialization specified may be less thanmaximally efficient on some platforms.
• Use of the objects is more expensive in terms of number of machine levelinstructions. SeeImplementation experience below.
• Depending on the compiler, some cost may be incurred by each translation unitthat includes the header, even if the objects are not used. This is acommon scenario in user code, since the header is included by otherstandard library headers. It should be mentioned that at least onecompilers is able to optimize this cost away, however.

IO streams uses a somewhat different formulation for iostream_category, but still suffer much the same problems.

The original plan was to eliminate these problems by applying the C++0xconstexpr feature. See LWG issue832⁽ⁱ⁾. However, that approach turned outto be unimplementable, since it would require aconstexpr object of aclass with virtual functions, and that is not allowed by the corelanguage.

The proposed resolution was developed as an alternative. It mitigates the above problems by removing initialization from the visible interface, allowing implementations flexibility.

Implementation experience:

Prototype implementations of the current WP interface and proposedresolution interface were tested with recent Codegear, GCC, Intel, and Microsoft compilers on Windows. The code generated by the Microsoft compiler was studied at length; the WP and proposal versions generated very similar code. For both versions the compiler did make use of staticinitialization; apparently the compiler applied an implicitconstexprwhere useful, even in cases whereconstexpr would not be permitted bythe language!

Acknowledgements:

Martin Sebor, Chris Kohlhoff, and John Lakos provided useful ideas and comments on initialization issues.

[San Francisco:]

Martin: prefers not to create more file-scope static objects, and wouldlike to seeget_* functions instead.

[Pre-Summit:]

Beman: The proposed resolution has been reworked to remove the file-scope static objects, per Martin's suggestions. Theget_ prefix has been eliminated from the function names as no longer necessary and to conform with standard library naming practice.

[Post Summit:]

Agreement that this is wise and essential, text provided works and hasbeen implemented. Seems to be widespread consensus. Move to Tentative Ready.

Proposed resolution:

Change 16.4.6.16[value.error.codes] Value of error codes as indicated:

Certain functions in the C++ standard library report errors via astd::error_code (19.4.2.2) object. That object'scategory() member shall returna reference tostd::system_category() for errors originating from the operating system, or a reference to an implementation-defined error_category object for errors originating elsewhere. The implementation shall define the possible values of value() for each of these error categories. [Example: For operating systems that are based on POSIX, implementations are encouraged to define thestd::system_category() values as identical to the POSIXerrno values, with additional values as defined by the operating system's documentation. Implementations for operating systems that are not based on POSIX are encouraged to define values identical to the operating system's values. For errors that do not originate from the operating system, the implementation may provide enums for the associated values --end example]

Change 19.5.3.1[syserr.errcat.overview] Classerror_category overviewerror_category synopsis as indicated:

const error_category&get_generic_category();const error_category&get_system_category();static storage-class-specifier const error_category& generic_category = get_generic_category();static storage-class-specifier const error_category& system_category = get_system_category();

Change 19.5.3.5[syserr.errcat.objects] Error category objects as indicated:

const error_category&get_generic_category();

Returns: A reference to an object of a type derived from classerror_category.

Remarks: The object'sdefault_error_condition andequivalent virtualfunctions shall behave as specified for the classerror_category. Theobject'sname virtual function shall return a pointer to the string"GENERIC".

const error_category&get_system_category();

Returns: A reference to an object of a type derived from classerror_category.

Remarks: The object'sequivalent virtual functions shall behave asspecified for classerror_category. The object'sname virtual functionshall return a pointer to the string"system". The object'sdefault_error_condition virtual function shall behave as follows:

If the argumentev corresponds to a POSIXerrno valueposv, the functionshall returnerror_condition(posv, generic_category()). Otherwise, thefunction shall returnerror_condition(ev, system_category()). Whatconstitutes correspondence for any given operating system isunspecified. [Note: The number of potential system error codes is largeand unbounded, and some may not correspond to any POSIXerrno value.Thus implementations are given latitude in determining correspondence.—end note]

Change 19.5.4.2[syserr.errcode.constructors] Classerror_code constructors as indicated:

error_code();

Effects: Constructs an object of type error_code.

Postconditions:val_ == 0andcat_ == &system_category().

Change 19.5.4.3[syserr.errcode.modifiers] Classerror_code modifiers as indicated:

void clear();

Postconditions:value() == 0 andcategory() == system_category().

Change 19.5.4.5[syserr.errcode.nonmembers] Classerror_code non-member functions as indicated:

error_code make_error_code(errc e);

Returns:error_code(static_cast<int>(e), generic_category()).

Change 19.5.5.2[syserr.errcondition.constructors] Classerror_condition constructors as indicated:

error_condition();

Effects: Constructs an object of typeerror_condition.

Postconditions:val_ == 0 andcat_ == &generic_category().

Change 19.5.5.3[syserr.errcondition.modifiers] Classerror_condition modifiers as indicated:

void clear();

Postconditions:value() == 0 andcategory() == generic_category().

Change 19.5.5.5[syserr.errcondition.nonmembers] Classerror_condition non-member functions as indicated:

error_condition make_error_condition(errc e);

Returns:error_condition(static_cast<int>(e), generic_category()).

Change 31.5[iostreams.base] Iostreams base classes, Header<ios> synopsis as indicated:

concept_map ErrorCodeEnum<io_errc> { };error_code make_error_code(io_errc e);error_condition make_error_condition(io_errc e);storage-class-specifier const error_category& iostream_category();

Change [ios::failure] Class ios_base::failure, paragraph 2 as indicated:

When throwingios_base::failure exceptions, implementations should provide values ofec that identify the specific reason for the failure. [Note: Errors arising from the operating system would typically be reported assystem_category() errors with an error value of the error number reported by the operating system. Errors arising from within the stream library would typically be reported aserror_code(io_errc::stream, iostream_category()). —end note ]

Change 31.5.6[error.reporting] Error reporting as indicated:

error_code make_error_code(io_errc e);

Returns:error_code(static_cast<int>(e), iostream_category()).

error_condition make_error_condition(io_errc e);

Returns:error_condition(static_cast<int>(e), iostream_category()).

storage-class-specifier const error_category& iostream_category();

The implementation shall initialize iostream_category. Its storage-class-specifier may be static or extern. It is unspecified whether initialization is static or dynamic (3.6.2). If initialization is dynamic, it shall occur before completion of the dynamic initialization of the first translation unit dynamically initialized that includes header <system_error>.

Returns: A reference to an object of a type derived from classerror_category.

Remarks: The object's default_error_condition and equivalent virtual functions shall behave as specified for the class error_category. The object's name virtual function shall return a pointer to the string "iostream".