Standardization

N4058: Atomic Smart Pointers -- Herb Sutter

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: N4058

Date: 2014-06-12

Atomic Smart Pointers

by Herb Sutter

Excerpt:

We encourage that modern C++ code should avoid all uses of owning raw pointers and explicit delete. Instead, programmers should use unique_ptr and shared_ptr (with weak_ptr), as this is known to lead to simpler and leak-free memory-safe code. This is especially important when lifetimes are unstructured or nondeterministic, which arises especially in concurrent code, and it has long been well-known that the smart pointers would be useful there; for an example, see [1].

Unfortunately, lock-free code is still mostly forced to use owning raw pointers. Our unique_ptr, shared_ptr, and weak_ptr would directly benefit lock-free code just as they do regular code (see next section), but they are not usable easily or at all in lock-free code because we do not support atomic<unique_ptr<T>>, atomic<shared_ptr<T>>, and atomic<weak_ptr<T>>.

...

If we had atomic<unique_ptr<T>> we could (and should) write the following equivalent code that is safer, no slower, and less error-prone because we can directly express the unique ownership semantics including ownership transfer:

atomic<unique_ptr<X>> p_root;
void producer() {
    auto temp = make_unique<X>();
    load_from_disk_and_store_in( *temp ); // build data structure
    p_root = move(temp);                  // atomically publish it
}
This righteous code should be supported...

N4052: WG21 2014-06-06 Telecon Minutes -- Ville Voutilainen

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: N4052

Date: 2014-06-10

WG21 2014-06-06 Telecon Minutes

by Ville Voutilainen

Excerpt:

Teleconference information:

  Date:     2014-06-06

  Time:     8:00am N.Am. Pacific Time

  Duration: 2 hours

1. Opening and introductions

Sutter called the meeting to order 8:10 Pacific Time.

1.1 Roll call of participants

In attendance were: ...

N4056: Minimal incomplete type support for standard containers -- Zhihao Yuan

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: N4056

Date: 2014-05-23

Minimal incomplete type support for standard containers

by Zhihao Yuan

Excerpt:

In the previous version (N3890) of this paper, we explored the possibility to make all STL containers usable in the recursive data structure definitions, such as

struct Entry
{
    std::list<Entry> messages;
    // ...
};

Based on the discussion on the Issaquah meeting, we achieved the consensus to processed with the approach – “Containers of Incomplete Types”, but limit the scope to std::vector, std::list, and std::forward_list, as the first step.

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.

...