Standardization

N3995: A proposal to add shared_mutex (untimed) (Revision 2) -- Gor Nishanov

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3995

Date: 2014-05-20

A proposal to add shared_mutex (untimed) (Revision 2)

by Gor Nishanov

Excerpt:

This revision is a minor edit of an earlier paper N3961 that clarifies that proposed modifications to the standard be incorporated into the Concurrency Technical Specification N3993.

N4051: Allow typename in a template template parameter -- Richard Smith

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4051

Date: 2014-05-26

Allow typename in a template template parameter

by Richard Smith

Excerpt:

Since the introduction of alias templates, C++ has had type templates that are not class templates, and in particular now has template template arguments that are not class templates. However, the syntax for template template parameters still requires the class keyword be used:

template<typename T> struct A {};
template<typename T> using B = int;

template<template<typename> class X> struct C;
C<A> ca; // ok
C<B> cb; // ok, not a class template
template<template<typename> typename X> struct D; // error, cannot use typename here

... This difference is artificial and is a common surprise. Removing it would make the language simpler.

 

N4049: 0-overhead-principle violations in exception handling -- Gutson, Bustamante, Oliva, Diaz

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4049

Date: 2014-05-27

0-overhead-principle violations in exception handling

by Daniel Gutson, Angel Bustamante, Pablo Oliva, Marcos Diaz

Excerpt:

Sometimes the 0-overhead principle is not honored; one has to pay for things that are not used. An instance where this can be observed is the Exception Handling mechanisms implemented by the diverse toolchains.

In an average computing environment, this has little or no importance; the overhead is minimal and its impact is negligible.

But on embedded systems, where memory is scarce, the overhead imposed by unused language constructs can exceed the capabilities of the available hardware, as we will show is the case for exceptions.

N4046: Executors and Asynchronous Operations -- Christopher Kohlhoff

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4046

Date: 2014-05-26

Executors and Asynchronous Operations

by Christopher Kohlhoff

Excerpt:

This proposal builds on the type traits defined in N4045 Library Foundations for Asynchronous Operations. This paper is intended as an alternative proposal to N3785 Executors and schedulers.

The type traits introduced in N4045 Library Foundations for Asynchronous Operations define an extensible asynchronous model that can support:

  • Callbacks, where minimal runtime penalty is desirable.
  • Futures, and not just std::future but also future classes supplied by other libraries.
  • Coroutines or resumable functions, without adding new keywords to the language.

The library introduced in this paper applies this asynchronous model, and its design philosophy, to executors. Rather than a design that is restricted to runtime polymorphism, we can allow users to choose the approach that is appropriate to their use case.

Future work will aim to develop guidance on the development of asynchronous operations that participate in an executor-aware model, such as those that integrate operating system services, for example networking support.

N4045: Library Foundations for Asynchronous Operations, Revision 2 -- Christopher Kohlhoff

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4045

Date: 2014-05-24

Library Foundations for Asynchronous Operations, Revision 2

by Christopher Kohlhoff

Excerpt:

1.1 Changes in this revision

This document supersedes N3964. In this revision, the handler_type<> trait has been
modified to be SFINAE-friendly, and an extended example has been added to section 9.2 to
illustrate how the traits may be specialised by a user to add a new completion token type.

N4044: A Three-Class IP Address Proposal, Revision 1 -- Christopher Kohlhoff

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4044

Date: 2014-05-24

A Three-Class IP Address Proposal, Revision 1

by Christopher Kohlhoff

Excerpt:

This proposal describes a three-class design for IP address classes:

  • A vocabulary type, ip::address, for use in IP version independent code.
  • An IPv4-specific type ip::address_v4.
  • An IPv6-specific type ip::address_v6.

 

N4041: Concerns with changing existing types in Technical Specifications -- Jonathan Wakely

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4041

Date: 2014-05-23

Concerns with changing existing types in Technical Specifications

by Jonathan Wakely

Excerpts:

In Issaquah there were proposals targeting a TS which enhanced existing types in the Standard Library, in particular N3857 which modifies std::future, N3916 which modifies std::function, std::promise and std::packaged_task, and N3920 which modifies std::shared_ptr. ...

Following straw polls the decision was taken to allow a TS to change existing types in namespace std, so that users who opt in to use the TS (via some implementation defined means) get the enhanced versions without needing to change any code. ...

The decision made following the straw polls means for an implementation to ship a TS they must change existing classes in their implementation, which has the potential to make silent ABI changes to users' programs. ...
These issues can make it complicated for implementers to provide TS support, so that users have to wait longer before they have access to an implementation, which then makes it less likely the committee will get useful and timely feedback on the TS contents.

... 

N4034: Destructive Move -- Pablo Halpern

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4034

Date: 2014-05-27

Destructive Move

by Pablo Halpern

Excerpt:

This paper proposes a function template for performing destructive move operations -- a type of move construction where the moved-from object, instead of being left in a “valid, but unspecified” state, is left in a destructed state. I will show that this operation can be made non-throwing in a wider range of situations than a normal move constructor, and can be used to optimize crucial operations, such as reallocations within vectors. An array version of the destructive move template is proposed specifically for moving multiple objects efficiently and with the strong exception guarantee.

The facilities described in this paper are targeted for a future library Technical Specification.

N4030: Feature-testing recommendations for C++ -- Clark Nelson

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4030

Date: 2014-05-22

Feature-testing recommendations for C++

by Clark Nelson

Excerpt:

[1]   The new __has_cpp_attribute feature should be reviewed by EWG and WG21.

[2]   I have added indications of changes relative to the published SD-6. The preface is informative; changes are not marked.

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

N4025: Exploring classes of runtime size -- Jeff Snyder and Richard Smith

A new WG21 paper is available. A copy is linked below, and will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4025

Date: 2014-05-23

Exploring classes of runtime size

by Jeff Snyder and Richard Smith

Excerpt:

During the Chicago meeting, several options were discussed for Arrays of Runtime Bound. These alternatives were summarised by Bjarne Stroustrup in N3810 [1]. One of the alternatives discussed, dubbed Array Constructors, was to introduce a core language feature that would allow types such as dynarray and bs_array to be written without special compiler support.

At the Issaquah meeting, J. Daniel Garcia proposed such a language feature, called Run-time bound array data members, in N3875 [2]. There was much discussion of this proposal, and of runtime-size types in general, with an overall feeling that it was worth pursuing a core language feature in this area.

This paper proposes an alternative way of allowing classes with runtime-bound array data members (aka runtime-size types) in C++ that aims to avoid various issues that were discussed at the Issaquah meeting, as well as exploring the impact that adding runtime-size types would have on the rest of the C++ language.