Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cplusplus.github.io/LWG/issue1108 below:

Issue 1108: thread.req.exception overly constrains implementations

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

Section: 32.2.2 [thread.req.exception] Status: C++11 Submitter: Christopher Kohlhoff Opened: 2009-04-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all issues with C++11 status.

Discussion:

The current formulation of 32.2.2 [thread.req.exception]/2 reads:

The error_category of the error_code reported by such an exception's code() member function is as specified in the error condition Clause.

This constraint on the code's associated error_categor means an implementation must perform a mapping from the system-generated error to a generic_category() error code. The problems with this include:

• The mapping is always performed, even if the resultant value is never used.

• The original error produced by the operating system is lost.

The latter was one of Peter Dimov's main objections (in a private email discussion) to the original error_code-only design, and led to the creation of error_condition in the first place. Specifically, error_code and error_condition are intended to perform the following roles:

• error_code holds the original error produced by the operating system.
• error_condition and the generic category provide a set of well known error constants that error codes may be tested against.

Any mapping determining correspondence of the returned error code to the conditions listed in the error condition clause falls under the "latitude" granted to implementors in 19.5.3.5 [syserr.errcat.objects]. (Although obviously their latitude is restricted a little by the need to match the right error condition when returning an error code from a library function.)

It is important that this error_code/error_condition usage is done correctly for the thread library since it is likely to set the pattern for future TR libraries that interact with the operating system.

[ Batavia (2009-05): ]

Move to Open, and recommend the issue be deferred until after the next Committee Draft is issued.

[ 2009-10 post-Santa Cruz: ]

Move to Tentatively Ready.

Proposed resolution:

Change 32.2.2 [thread.req.exception] p.2:

-2- The error_category (19.5.1.1) of the error_code reported by such an exception's code() member function is as specified in the error condition Clause. The error_code reported by such an exception's code() member function shall compare equal to one of the conditions specified in the function's error condition Clause. [Example: When the thread constructor fails:

ec.category() == implementation-defined // probably system_category
ec == errc::resource_unavailable_try_again // holds true

— end example]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4