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

1358. Add <chrono> and <ratio> to freestanding implementations

Section: 16.4.2.5 [compliance] Status: NAD Submitter: BSI Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [compliance].

View all issues with NAD status.

Discussion:

Addresses GB-55

The <thread> header uses duration types, found in the <chrono> header, and which rely on the ratio types declared in the <ratio> header.

[ Extracts from lengthy Rapperswil discussion: ]

There is a concern that this issue is a misunderstanding of the actual requirements of a free-standing implementation to support the <thread> header. In general, a free-standanding implementation will provide an empty header, specifically so that a user can test for the absence of the _ _ STDCPP_THREADS _ _ macro. This idiom as used as there is no portable way to test for the lack of a header.

At this point, it was suggested the NB comment is trying to solve the wrong problem, and that _ _ STDCPP_THREADS _ _ should be a pre-defined macro in clause 16 that can be tested before including <thread>. That would remove the need to add additional headers to the free-standanding requirements.

It is worth noting that Japan requested <ratio> as a free-standing header in their CD1 comments. No-one seemed keen to require clocks of a free-standing implementation though.

Detlef volunteers to look at a way to redraft 17.6.1.3 p3.

[ Original resolution proposed by NB comment: ]

Add the <chrono> and <ratio> headers to the freestanding requirements.

It might be necessary to address scaled-down expectations of clock support in a freestanding environment, much like <thread>.

[2011-02-25: Alberto drafts wording]

[2011-03-06: Daniel observes:]

Accepting the proposal n3256 would solve this issue.

[2011-03-24 Madrid meeting]

Freestanding no longer requires <thread> header

Rationale:

We are not adding new headers to freestanding at this point.

Proposed resolution:

1. Add a new entry in Table 14 — C++ library headers:

   Table 14 — C++ library headers

   …

   <iterator>

   <library_support>

   <limits>

   …

2. Remove the last row 32.4 [thread.threads] <threads> from Table 16 — C++ headers for freestanding implementations and insert a new one instead (To the editor: For the actual target Clause please see the comment in bullet 5 of this proposed resolution):

   Table 16 — C++ headers for freestanding implementations

   Subclause	Header(s)
   …
   32.4 [thread.threads] Threads	<thread>
   ?? Library support	<library_support>

3. Modify paragraph 16.4.2.5 [compliance] p. 3:

   3 The supplied version of the header <cstdlib> shall declare at least the functions abort, atexit, at_quick_exit, exit, and quick_exit (18.5). The supplied version of the header <thread> shall meet the same requirements as for a hosted implementation or including it shall have no effect. The other headers listed in this table shall meet the same requirements as for a hosted implementation. A program can detect the presence of standard headers not listed in Table 16 using the facilities provided by the <library_support> header.

4. Remove the following line from the header <thread> synopsis in 32.4 [thread.threads] p. 1:

   namespace std {
     #define __STDCPP_THREADS__ __cplusplus
   
     class thread;
     [...]
   }
   

5. Add a new section in Clause 18 or 20 (or any other suitable place at the editor's discretion):

   ?? Library support [library.support]

   The header <library_support> defines an implementation-defined set of macros to allow a program detect the presence of standard headers in freestanding implementations. [Note: Hosted implementations shall provide all standard headers, thus shall provide all macros. — end note]

   For each standard header listed in Tables 14 (C++ library headers) and 15 (C++ headers for C library facilities) that is provided by the implementation, <library_support> shall define a macro with name _ _HAS_XXX_HEADER_ _ where XXX is replaced by the uppercase version of the name of the header. Each such macro shall expand to the value _ _cplusplus. [Example:

   #include <library_support>
   
   #ifdef _ _HAS_THREADS_HEADER_ _
     #include <threads>
     // code that exploit the presence of threads
   #else
     // fallback code that doesn't rely on threads
   #endif
   

   — end example]

   No other standard header shall define macros with a name beginning with _ _HAS_ and ending with _HEADER_ _.