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 33.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)
   > --- | ---
   > …
   > 33.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 33.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_ _`.