Document number: N3750

Date: 2013-09-01

C++ Ostream Buffers

by Lawrence Crowl

We propose an ostream_buffer, that provides access to a matching basic_ostringstream for buffering output operations. The ostream_buffer, will atomically transfer the contents of the basic_ostringstream to an ostream on destruction of the ostream_buffer.

Document number: N3749

Date: 2013-08-31

Constexpr Library Additions: functional

by Marshall Clow

I propose that we make the following change:

template <class T = void> struct less {
  typedef T first_argument_type;
  typedef T second_argument_type;
  typedef bool result_type;

  constexpr bool operator()(const T& x, const T& y) const { return x < y; }

  };

This will allow people to use less<T>{}(x,y) at compile time.

This should also apply to all the relational operators (less, greater, less_equal, greater_equal, not_equal_to, equal_to), the arithmetic operators (plus, minus, multiplies, divides, modulus, negates), the bit manipulations (bit_and, bit_or, bit_xor, bit_not) and the negators (unary_negate, binary_negate, no1, not2).

Document number: N3748

Date: 2013-08-30

Implicit Evaluation of "auto" Variables and Arguments

by Peter Gottschling, Joel Falcou, Herb Sutter

Type detection for variables from expressions' return type:

auto x= expr;

has proven high usability. However, it fails to meet most users' expectations and preferences when
proxies or expression templates (ET) are involved, e.g.:

matrix A, B;
// setup A and B
auto C= A  B;

Many people would expect C to be of type matrix as well. ...

Moreover, we assume that even people who are aware of expression templates will very often prefer the evaluated object (here a matrix containing the product of A and B) and not an unevaluated or partially evaluated object (representing the product of A and B).

We therefor need a mechanism to evaluate objects of certain types implicitly and sufficient
control over this mechanism.

Document number: N3747

Date: 2013-09-01

A Universal Model for Asynchronous Operations

by Christopher Kohlhoff

... In this paper, we will first examine how futures can be a poor choice as a fundamental
building block of asynchronous operations in C++. The extended std::future brings
inherent costs that penalise programs, particularly in domains where C++ use is prevalent
due to its low overheads. An asynchronous model based on a pure callback approach, on the
other hand, allows efficient composition of asynchronous operations.

However, cognizant that some C++ programmers may have valid reasons for preferring a
futures-based approach, this paper introduces a universal model for asynchronous
operations. This model supports both lightweight callbacks and futures, allowing the
application programmer to select an approach based on appropriate trade-offs.

Finally, we will see how this universal model can be leveraged to support other models of
composition. This paper presents implementation experience of the universal model, which
includes several pure library implementations of resumable functions, or coroutines.
Programmers have the opportunity to express asynchronous control flow in an imperative
manner, without requiring the addition of new keywords to the language.

Document number: N3746

Date: 2013-08-30

Proposing a C++1Y Swap Operator, v2

by Walter Brown

We propose a new swap operator on native types for incorporation into the C++1Y core language. For user-defined types, we propose that this new operator be treated as a special member function, and that, when viable, its presence provide an alternative to traditional memberwise implementation of defaulted assignment semantics.

Document number: N3745

Date: 2013-08-28

Feature-testing recommendations for C++

by Clark Nelson

[1] The more time that passes without any sort of feature-testing recommendation, the more confusion will affect programmers and implementers interested in features of C++14, of the sort that has plagued C++11 for years. So whatever action should be taken in this arena should not be delayed any more than can be avoided.

[2] SG10 intends to produce its recommendations solely as a WG21 document, without any balloting at higher levels. This is partly to save time, but also to avoid making significant conformance changes. It is hoped that compiler and library implementers will follow these recommendations voluntarily, even without the threat of claims of non-conformance. To improve the chances of that happening, it is considered important to have a record of the endorsement of WG21 -- or at least of the C++ technical experts who attend WG21 meetings.

[3] So SG10 would like to bring this document forward for some sort of approval vote at the Chicago meeting. Formally speaking, no action by the committee is requested, so this vote should probably be just a straw poll.

[4] It should be understood that section 2, “Recommendations” (excluding the sub-sections that are currently stubs), is the section for which approval and stability really matter. Improving the examples, or explanations of rationale, is basically editorial, and improvements will hopfully continue to happen after the recommendations themselves have been approved.

[5] Note that this document recommends that the __has_include feature be provided in the C++14 time frame, even though it is not included in the CD for C++14. A conceivable alternative would be to add __has_include to C++14 before its final publication.

[6] This revision of this document contains STUBS for sections expected to be filled in later.

Document number: N3739

Date: 2013-09-02

Improving pair and tuple, revision 1

by Daniel Krügler

Changes since N3680:

• During a straw-pool vote there was a small majority (4:3) in favour for keeping the two-signatures approach, so this presentation form was used in this revision.
• The original example has been improved.
• The missing application of the declaration pattern to the allocator_arg_t constructors has been fixed.
• Consequent usage of the more precise is_convertible trait instead of the somewhat vague is implicitly convertible description.

Document numbers: N3736-38

Date: 2013-08-27

C++ Standard Evolution Active Issues List (Revision R03)

C++ Standard Evolution Completed Issues List (Revision R03)

C++ Standard Evolution Closed Issues List (Revision R03)

by Ville Voutilainen

The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document, and proposed extensions to it.

Document number: N3735

Date: 2013-09-02

On the difference between parallel loops and vector loops

by Robert Geva

This is not a proposal, it is a clarification of existing proposals.

Some feedback regarding the loops proposed within the Cilk Plus proposal expressed interest in a loop that is both parallel and vector

Other proposals pursue the idea that an algorithm can be expressed in a way that is independent of whether it is sequential, parallel or vector, and those are chosen as “execution policy”

While all the above are useful and encouraged, this presentation suggests that single threaded vector loops are more foundational and of higher priority than the combined loops and algorithms.

The fundamental argument is that vector loops and parallel loops are mostly very different, whereas their similarities are mostly superficial

Document number: N3734

Date: 2013-09-92

Vector Programming: A proposal for WG21

by Robert Geva

[As] presented to CPLEX within WG14 [ISO C.]