cplusplus/draft

C++ standards drafts

C++ Standard Draft Sources

These are the sources used to generate drafts of the C++ standard. These sources should not be considered an ISO publication, nor should documents generated from them unless officially adopted by the C++ working group (ISO/IEC JTC1/SC22/WG21).

Get involved:

• How to submit an editorial issue
• How to tell if an issue is editorial
• How to submit a new issue/defect report for non-editorial issues

More information about the C++ standard can be found at isocpp.org.

Getting Started on Mac OS X

Install the MacTeX distribution.

If you are on a slow network, you'll want to get the BasicTeX package instead, then run the following command to install the other packages that the draft requires:

sudo tlmgr install latexmk isodate substr relsize ulem fixme rsfs extract layouts enumitem l3packages l3kernel imakeidx splitindex xstring

Getting Started on Debian-based Systems

Install the following packages:

sudo apt-get install latexmk texlive-latex-recommended texlive-latex-extra texlive-fonts-recommended lmodern

Getting Started on Fedora

Install the following packages:

dnf install latexmk texlive texlive-isodate texlive-relsize texlive-ulem texlive-fixme texlive-extract texlive-l3kernel texlive-l3packages texlive-splitindex texlive-imakeidx

Getting Started on Arch Linux

Install the following packages:

pacman -S make texlive-latexextra texlive-binextra texlive-plaingeneric texlive-fontsrecommended

-----------------------------Getting Started on Microsoft Windows -----------------------------

Install Perl (for example, using a Cygwin installation and adding perl. See sample instructions for more details)

Install MiKTeX

Instructions

To typeset the draft document, from the source directory run:

make

That's it! You should now have an std.pdf containing the typeset draft.

Generated input files

To regenerate figures from .dot files, run:

make <pdfname>

For example:

make figvirt.pdf

Acknowledgements

A great deal of gratitude goes out to Pete Becker for his amazing work in the original conversion of the C++ standard drafts to LaTeX, and his subsequent maintenance of the standard drafts up to C++11. Thank you Pete.

Thanks to Walter Brown for suggesting the use of latexmk.

draft's Issues

unresolved references

latexmk -pdf std tells me:

Latexmk: Reference 'basic.scope.local''on page 1228 undefined
Latexmk: Reference 'basic.scope.local' on page 1228 undefined
Latexmk: Log file says output to 'std.pdf'
Latexmk: Summary of warnings:
Latex failed to resolve 2 reference(s)

index: formatting issues

Via cxxeditor@:

Finally, I noted a very minor typographical issue: There seems to be
a space missing after "see" in the index entry for
"conditionally-supported behavior". I also suspect there shouldn't be a
page entry here, given that it's a cross-reference to another entry.
(Besides, the page number is wrong.) [Hmmm; I now see this entry is
generated via an \indexdefn macro call; perhaps it should be an
\indextext call instead?]

[expr.static.cast]/12 specifies "undefined result" instead of undefined behaviour

Currently says:

"If class B contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. Otherwise, the result of the cast is undefined."

LaTeX: Pull contents for synopses in by reference as possible.

There are often inconsistencies between synopses, lists of definitions, and sometimes even between two synopses (e.g. the <memory> vs the shared_ptr synopsis).

For example, the <memory> synopsis was missing make_shared() and allocate_shared() (issue #71).

It would be great to include these bits by reference instead of copying them in the document. At minimum, this should be doable for cases like the above where there are "nested" synopses.

[containers.requirements.general] missing reference to table

From an email to cxxeditor@:

I would like to report a simple Editorial issue. It appears not only
in the official standard but in also in which I believe is latest
draft: N3485.

Paragraph 23.2.1/4 says:

"In Tables 96 and 97 [...] a and b denote values of type X [...]"

whereas it meant

"In Tables 96, 97 and 98 [...] a and b denote values of type X [...]"

Indeed, Table 98 uses a and b and no other paragraph between 23.2.1/4
and Table 98 defines a and b. Alternatively, the paragraph immediately
preceding Table 98, which is 23.2.1/12, could redefine a and b by
replicating the definition given in 23.2.1/4.

Lock tag types not in Index of library names

The following library names, all specified in [thread.lock]/p2, do not appear in the "Index of library names", as of n3376:

defer_lock_t
defer_lock
try_to_lock_t
try_to_lock
adopt_lock_t
adopt_lock

use of "Remark" element in library specifications

I've noticed the library inconsistently uses Remark: (i.e. \remark) and Remarks: (i.e. \remarks) but only the latter is presented in 17.5.1.4 [structure.specification].

I can prepare a patch if wanted.

Initializer List

This issue is motivated by the discussion at http://isocpp.org/forums/iso-c-standard-discussion with the title "Initializer List"

The issue:

A braced-init-list is not treated as an expression. This is evident from the grammar in section 5.2.2.

and even in the paragraph 6.6.3/1-

"A return statement with neither an expression nor a braced-init-list can be used only in functions that do not return a value, that is, a function with the return type void"

Now,

Given a function

'void f(std::initializer_list t) { }
The function call 'f({1, 2}) is well-formed.

However, given the fact that a braced-init-list is not an expression, the wording in section 5.2.2 seems inappropriate to me as it accounts only for "expressions" to be allowed as function call arguments.

"There are two kinds of function call: ordinary function call and member function63 (9.3) call. A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function."

This statement possibly can be more permissive and explicitly mention about braced-init-list. My proposal is as follows:

"There are two kinds of function call: ordinary function call and member function63 (9.3) call. A function call is a postfix expression followed by parentheses containing a possibly empty, comma-separated list of expressions or braced-init-list which constitute the arguments to the function."

An alternate proposal is to treat a braced-init-list such as {1, 2} also as an expression.

§16.3.5 [cpp.scope] ends in an unmatched "— end note ]"

Paragraphs §16.3.5/3-9 contain examples of the preprocessor macro expansion rules, and as such I would expect them all to not be normative text.

It is clear that §16.3.5/3 is not normative, but unclear whether or not §16.3.5/4-9 are normative text as they end in an unmatched — end note ]

To illustrate, without the text of the examples the paragraphs look like this:

3. [Note:
...
— end note]
4.
...
...
...
9.
...
— end note]

Missing end-note tags

20.6.5 [ptr.align]/4: "[ Note: The function updates its ptr and space arguments so that it can be called repeatedly with
possibly different alignment and size arguments for the same buffer." This is the last paragraph in the section, so the end-note tag can't be hiding below.

20.7.2.3.7 [util.smartptr.ownerless]/2: "operator()(x,y) shall return x.owner_before(y). [ Note: Note that
— operator() defines a strict weak ordering as defined in 25.4;
— under the equivalence relation defined by operator(), !operator()(a, b) && !operator()(b, a), two shared_ptr or weak_ptr instances are equivalent if and only if they share ownership or are both empty." Again, this is the last paragraph in the section, so the end-note tag can't be hiding below.

22.4.5.1.1 [locale.time.get.members]/9: "[ Note: The function uses the ctype facet installed in f’s locale to determine valid whitespace characters. It is unspecified by what means the function performs case-insensitive comparison or whether multi-character sequences are considered while doing so." This is the second-to-last paragraph in the section, so the end-note tag can't be hiding below.

[dcl.attr.grammar]/6 ill formed and malformed are poorly formed

From an email to cxxeditor@:

§7.6.1/6
In the note there is "ill" and "formed" on separate lines but the - is missing in between.

The example uses term "malformed" even though the note uses ill-formed. Also malformed
is not used anywhere else in the standard.

[tuple.swap] wrong subscript

From a cxxeditor@ email:

N3485 20.4.2.3 [tuple.swap]/1 says "where T1 is the ith type in Types." with a number-1 subscript, instead of a letter-i subscript.

[over.ics.rank]/3 Horrible nested sub-bullets

The formatting is a mess here (examples nested in nested bullets, sentences ending with a period but then continuing with "or, if not that"), etc...

[expr.cond]/3 typo - rvalue -> prvalue

From an email to cxxeditor@:

In subclause 5.16 [expr.cond] paragraph 3:

Each bullet in the following is probably meant to be exclusive of the others. The third bullet should use "prvalue" instead of "rvalue".

• If E2 is an lvalue: E1 can be converted to match E2 if E1 can be implicitly converted (Clause 4) to the type "lvalue reference to T2", subject to the constraint that in the conversion the reference must bind directly (8.5.3) to an lvalue.
• If E2 is an xvalue: E1 can be converted to match E2 if E1 can be implicitly converted to the type "rvalue reference to T2", subject to the constraint that the reference must bind directly.
• If E2 is an rvaluea prvalue or if neither of the conversions above can be done and at least one of the operands has (possibly cv-qualified) class type

Mike Miller confirmed as editorial.

[gram.dcl] assignment-expression -> alignment-expression

From an email to cxxeditor:

In N3485 [gram.dcl] the following typo is still present:

- alignas ( alignment-expression ...opt )
+ alignas ( assignment-expression ...opt )

This was fixed in [dcl.attr.grammar], but not reflected in [gram.dcl]

Related: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1323

Related: https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-discussion/K5t9ac8yZSU

[associative.reqmts] Terribly formatted table

The table "Associative container requirements" has awful formatting.

[adjacent.difference]'s Effects paragraph isn't numbered

[adjacent.difference]'s Effects paragraph isn't numbered. Below it, the Requires paragraph is numbered 1.

Change "full specializations" to "explicit specializations" in [atomic.types.generic]/4

Currently the paragraph reads:
"There shall be full specializations of the atomic template for the integral types..."

Full specializations should be changed to explicit specializations so it reads like so:
"There shall be explicit specializations of the atomic template for the integral types..."

implementation-defined bits not in implementation-defined index

E.g. in the bad_cast description, where it says "The results of calling what() ... is implementation-defined" there's no \impldef{} and thus no index entry. There's probably a lot of these; do a grep and fix em all.

partial_sum_copy should be partial_sum

the example in [stream.iterators] 24.6
refers to

   partial_sum_copy(istream_iterator<double, char>(cin),
     istream_iterator<double, char>(),
     ostream_iterator<double, char>(cout, "\n"));

the function partial_sum_copy is non-existent but named "partial_sum" instead. It would even be better if such an example would use the new initializer syntax :-)

   partial_sum(istream_iterator<double, char>(cin),
     istream_iterator<double, char>(),
     ostream_iterator<double, char>(cout, "\n"));

or better

   partial_sum(istream_iterator<double, char>{cin},
     istream_iterator<double, char>{},
     ostream_iterator<double, char>{cout, "\n"});

P.S.: This has already been reported to comp.lang.c++ in 2005 but didn't seem to have taken up attention by somebody yet
http://groups.google.com/group/comp.std.c++/browse_thread/thread/cdd1d6f37f42a33c?pli=1

and it has been sitting there since Stepanov 1995

@@ -2569,9 +2569,9 @@ are provided.

 \enterexample
 \begin{codeblock}
-partial_sum_copy(istream_iterator<double, char>(cin),
-  istream_iterator<double, char>(),
-  ostream_iterator<double, char>(cout, "@\textbackslash@n"));
+partial_sum(istream_iterator<double, char>{cin},
+  istream_iterator<double, char>{},
+  ostream_iterator<double, char>{cout, "@\textbackslash@n"});
 \end{codeblock}

 reads a file containing floating point numbers from

make_shared missing in synopsis for <memory>

basic_regex constructor inconsistencies

From an email to cxxeditor:

In the Working Draft #3337 of the C++ Standard in section
28.8 Class template basic_regex

there is written

explicit basic_regex(const charT* p, flag_type f = regex_constants::ECMAScript);

Take into account the keyword explicit.

However in the description of this constructor this keyword is abset

basic_regex(const charT* p, flag_type f = regex_constants::ECMAScript);

The simialar defect was pointed out by Daniel Krügler for the constructor

template <class ST, class SA>
explicit basic_regex(const basic_string<charT, ST, SA>& p,
flag_type f = regex_constants::ECMAScript);

In its description the keyword explicit is also abset.

template <class ST, class SA>
basic_regex(const basic_string<charT, ST, SA>& s,
flag_type f = regex_constants::ECMAScript);

Semicolons after references to functions in comments

Via cxxeditor@:

E.g. in [over.load]

void f(int i);
void f(Int i); // OK: redeclaration of f(int) <-- no semicolon
void f(int i) { /* ... */ }
void f(Int i) { /* ... */ } // error: redefinition of f(int) <-- no semicolon

when few lines down you have

int f(char*);
int f(char[]); // same as f(char*);
int f(char[7]); // same as f(char*);
int f(char[9]); // same as f(char*); <-- semicolon

Formatting issue in Cross References annex

From an email to cxxeditor@:

In Annex F ("Cross references"):
The first line following each alphabetic head is indented to align with the head letter; all the other lines are left-justified.

[dcl.type.simple] erroneous example

From an email to cxxeditor@:

I just notice that the example in [dcl.type.simple]

const int&& foo();
int i;
[..]
decltype(foo()) x1 = i; // type is const int&&

looks erroneous. The defect is that you cannot initialize a variable
"const int&&" with an lvalue of int (as shown here). A possible fix
would be to write this as:

const int&& foo();
[..]
decltype(foo()) x1 = 0; // type is const int&&

(this is: Including a strike of the variable 'i').

My understanding is that this is an editorial defect, because

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#651

already suggested a fix of the examples here.

"conditionally supported" -> "conditionally-supported"

Via cxxeditor@:

I was searching the pdf for "conditionally-supported" but
accidentally omitted the hyphen; nonetheless these popped up:
[lex.header]/2
[lex.string]/6
I suggest the missing hyphen be inserted in both places.

Inconsistent null values throughout the draft

From an email to cxxeditor@ (and pointed out by various people in the past):

I noticed following inconsistent usage of null and NULL in the current C++ standard (checked against N3337)

20.7.2.2.1/16 Uses NULL when i think it should be null to be consistent.
20.8.11.2.1/8 Same issue.

20.8.11.2.1/15 & 22 Uses NULL to compare where in other places in the std 0 and nullptr are used.

For example
20.7.1.2.5 compares against nullptr
20.7.2.2.1/22 compares against 0 (there are many more such)

There are many other NULL uses in the standard that are not clear that they should be NULL.

deallocation function term defined in a weird spot

It's defined in [expr.delete] and in a very strange way, especially after applying N3664 (Clarifying Memory Allocation).

[streambuf.virt.put]/5 "NULL non-value"

From an email to cxxeditor@:

27.6.3.4.5 [streambuf.virt.put] p5 says:

at pbase() are the associated output stream. In case r is zero (all
characters of the pending
sequence have been consumed) then either pbase() is set to NULL, or
pbase() and pptr() are
both set to the same NULL non-value.

I'm assuming that should be non-NULL value, because I don't think we
want to set them to a non-value!

[class.mem]/10 inconsistent formatting of "static"

non-\tcode{static} vs non-static

Inconsistent spacing between "template" and "<"

From an email to cxxeditor@:

template<typename T>

or

template <typename T>

The standard as-is has 1494 instances of 'template<' that I can find trivially, and 2053 instances of 'template <'.

[dcl.array]/1 code example needs more \tcode{}

// type is “array of 5 const int”
// type is “array of 2 array of 3 const int”

"const int" should be \tcode{}. Also applies to "int" in the text added by N3639.

[pairs.pair] "Requires Requires" requires fewer Requires

Via cxxeditor@:

N3485 20.3.2 [pairs.pair]/16 says:

"Requires: Requires: is_constructible<first_type, Args1&&...>::value is true and is_constructible<second_type, Args2&&...>::value is true."

This typo is not repeated elsewhere in the Working Paper, as far as I can see.

Extra comma in [ios::failure]/3

explicit failure(const string& msg, , const error_code& ec = io_errc::stream);

From an email to cxxeditor: "The second comma is spurious. Fortunately, this appears to be the only occurrence."

[associative.reqmts] begins a sentence with lowercase "always"

In 23.2.4 [associative.reqmts]'s table, the "a.insert(p, t)" row says:

"Effects: Inserts t if and only if there is no element with key equivalent to the key of t in containers with unique keys; always inserts t in containers with equivalent keys. always returns the iterator pointing to the element with key equivalent to the key of t. t is inserted as close as possible to the position just prior to p."

The second "always" begins a sentence and should therefore be capitalized.

"sequenced after" undefined

From an email to cxxeditor@:

I found "sequenced after" used in 5.17[expr.ass] but I could not find where it was defined. (I searched N3485. This is the only appearance. )

Would it better to use "sequenced before" to instead, or introduce the term "sequenced after" in 1.9[intro.execution] just like italicized "sequence before"?

PS. I found both "sequenced before" and "sequenced after" in WG14/N1570 5.1.2.3/2 defined as normative terms.

20.2.3 forward/move helpers [forward]

1. paragraph 3 is unlabeled; I recommend inserting \remark before the leading "if" and then capitalizing that leading "if"
2. the Returns clause above paragraph 6 is unnumbered; I recommend inserting \pnum before \returns

Construction order for thread_local objects is unclear

The order (and frequency) of construction is implicit, but the current wording is very terse and deserves at least a note to clarify the intent.

There may also be a CWG issue about when the arguments to such a constructor call are evaluated.

"integral literal" should be "integer literal"

/Users/sdutoit/dev/c++/draft/source/lex.tex:
535
536 \pnum
537: Preprocessing number tokens lexically include all integral literal
538 tokens~(\ref{lex.icon}) and all floating literal
539 tokens~(\ref{lex.fcon}).
...
541 \pnum
542 A preprocessing number does not have a type or a value; it acquires both
543: after a successful conversion to an integral literal token or a floating literal
544 token.%
545 \index{number!preprocessing|)}

[atomics.types.generic]/7 Typo

From an email to cxxeditor@:

N3485 29.5 [atomics.types.generic]/7 says:

"Each named type is a either typedef to the corresponding specialization or a base class of the corresponding specialization."

This should say "either a".

"shall not participate in overload resolution unless" considered not not harmful

Search for "shall not participate". There are around 40 occurrences of the form "X shall not participate in overload resolution unless Y". This is unnecessarily confusing. "X shall participate in overload resolution if and only if Y" would be clearer, and as a bonus, it would mirror how enable_if is used.

There are only a few occurrences that aren't exactly of this form which will need slightly less mechanical reworking:

• 20.3.2 [pairs.pair]/9 is unnecessarily phrased differently from the other pair constraints: "Remarks: If U is not implicitly convertible to first_type or V is not implicitly convertible to second_type this constructor shall not participate in overload resolution."
• 23.6.3.3 [queue.cons.alloc]/1, 23.6.4.2 [priqueue.cons.alloc]/1, and 23.6.5.4 [stack.cons.alloc]/1 say: "If uses_allocator<container_type, Alloc>::value is false the constructors in this subclause shall not participate in overload resolution."
• 23.2.3 [sequence.reqmts]/14 says: "If the constructor [...] is called with a type InputIterator that does not qualify as an input iterator, then the constructor shall not participate in overload resolution." and "If the member functions of the forms: [...] are called with a type InputIterator that does not qualify as an input iterator, then these functions shall not participate in overload resolution."
• 26.5.3 [rand.eng]/6 says: "if the constructor [...] is called with a type Sseq that does not qualify as a seed sequence, then this constructor shall not participate in overload resolution;" and "if the member function [...] is called with a type Sseq that does not qualify as a seed sequence, then this function shall not participate in overload resolution."
• 30.6.8 [futures.async]/8 says: "Remarks: The first signature shall not participate in overload resolution if decay::type is std::launch."

type-specifier-seq should be decl-specifier-seq

From an email to cxxeditor@:

In a number of places stmt.select talks about the "type-specifier-seq" (presumably of the "condition declaration"). However, type-specifier-seq has been replaced by decl-specifier-seq to allow for constexpr.

[thread.threads] Namespace indentation

From an email to cxxeditor@:

I also suggest to indent all members of namespace this_thread in 30.3 Threads [thread.threads].

Currently optically you can't see that they are defined INSIDE namespace this_thread.

[vector.bool]/1 typos

From an email to cxxeditor@:

N3485 23.3.7 [vector.bool]/1 declares:

void assign(initializer_list<bool>;

which is missing a parenthesis.

Additionally, this says:

vector operator=(initializer_list<bool>);

which should certainly be saying "vector&".

ios_base synopsis issues

in the synopsis of ios_base, it says:

typedef T4 seekdir;
static constexpr fmtflags beg = unspecified ;
static constexpr fmtflags cur = unspecified ;
static constexpr fmtflags end = unspecified ;

but shouldn't it be:

typedef T4 seekdir;
static constexpr seekdir beg = unspecified ;
static constexpr seekdir cur = unspecified ;
static constexpr seekdir end = unspecified ;

[ratio.ratio] Order of ratio members

Via cxxeditor@:

In 20.10.3 Class template ratio [ratio.ratio] we declare:

namespace std {
 template <intmax_t N, intmax_t D = 1>
 class ratio {
   public:
     typedef ratio<num, den> type;
     static constexpr intmax_t num;
     static constexpr intmax_t den;
 };
}

It would be clearer as:

class ratio {
  public:
    static constexpr intmax_t num;
    static constexpr intmax_t den;
    typedef ratio<num, den> type;
};

Inconsistent formatting of T1, T2, etc. placeholders

Most of the time these are \tcode{} formatted, but there are places like [conv.qual] where they are unformatted or italicized.

[unord.req] says "maximum load load factor"

[unord.req] says "maximum load load factor". The repeated word is a typo typo.

[thread.condition.condvar], [thread.condition.condvarany] Misuse of term function scope

From an email to cxxeditor@:

Discussed here: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/JpQVT-pwP9E

N3485

3.3.5 Function scope [basic.funscope]
1 Labels (6.1) have function scope and may be used anywhere in the function in which they are declared. Only labels have function scope.

30.5.1 Class condition_variable [thread.condition.condvar]
10 Effects:
— Atomically calls lock.unlock() and blocks on *this.
— When unblocked, calls lock.lock() (possibly blocking on the lock), then returns.
— The function will unblock when signaled by a call to notify_one() or a call to notify_all(), or spuriously.
— If the function exits via an exception, lock.lock() shall be called prior to exiting the function scope.
20 Effects:
— Atomically calls lock.unlock() and blocks on *this.
— When unblocked, calls lock.lock() (possibly blocking on the lock), then returns.
— The function will unblock when signaled by a call to notify_one(), a call to notify_all(), expiration of the absolute timeout (30.2.4) specified by abs_time, or spuriously.
— If the function exits via an exception, lock.lock() shall be called prior to exiting the function scope.

30.5.2 Class condition_variable_any [thread.condition.condvarany]
10 Effects:
— Atomically calls lock.unlock() and blocks on *this.
— When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
— The function will unblock when signaled by a call to notify_one(), a call to notify_all(), or spuriously.
— If the function exits via an exception, lock.lock() shall be called prior to exiting the function scope.
15 Effects:
— Atomically calls lock.unlock() and blocks on *this.
— When unblocked, calls lock.lock() (possibly blocking on the lock) and returns.
— The function will unblock when signaled by a call to notify_one(), a call to notify_all(), expiration of the absolute timeout (30.2.4) specified by abs_time, or spuriously.
— If the function exits via an exception, lock.lock() shall be called prior to exiting the function scope.

The use of "function scope" in [thread.condition] is conflict with the description in [basic.funscope]. Probably the former should be "outermost block scope of the function".

[thread.thread.class] missing declaration of swap(thread&,thread&)

From an email to cxxeditor@:

I suggest to add in
30.3.1 Class thread [thread.thread.class]
right after the declaration of class thread but still inside
namespace std a declaration of the global swap():

namespace std {
  class thread {
    ...
  };

HERE:

  // 30.3.1.7 specialized algorithms:
  void swap(thread& x, thread& y) noexcept;
}

As it is usually done for container and other classes.