Standardization : Standard C++

Home » Blog » Categories » Standardization

« Prev Next »

Standardization

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

By Blog Staff | Jun 10, 2014 11:07 AM | Tags: None

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

By Blog Staff | Jun 8, 2014 03:47 PM | Tags: None

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

By Blog Staff | Jun 5, 2014 08:46 AM | Tags: None

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

By Blog Staff | May 28, 2014 01:37 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:34 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:31 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:29 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:27 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:23 PM | Tags: None

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

By Blog Staff | May 28, 2014 01:17 PM | Tags: None

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.