Home » Blog » Categories » Standardization

Standardization

N4169: A proposal to add invoke function template (Revision 1) -- Tomasz Kamiński

By Blog Staff | Oct 8, 2014 01:47 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4169

Date: 2014-08-22

A proposal to add invoke function template (Revision 1)

by Tomasz Kamiński

Excerpt:

The aim of this proposal is to introduce the function template invoke that provide uniform semantics for invoking all C++ callable types which includes: function pointers, member pointers and functors. The behaviour of the function is defined in terms of INVOKE expression.

N4168: Removing auto_ptr -- Billy Baker

By Blog Staff | Oct 8, 2014 01:44 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4168

Date: 2014-10-02

Removing auto_ptr

by Billy Baker

Excerpt:

At Oxford in 2007, N1856 was accepted adding unique_ptr and making auto_ptr deprecated. At CppCon in 2014, Howard Hinnant stated that he would like to see auto_ptr removed from future C++ standards. This paper proposes that auto_ptr be removed entirely. Removing auto_ptr now would give plenty of time before the next C++ standard for code to be updated if necessary.

N4160: Value constraints -- Andrzej Krzemieński

By Blog Staff | Oct 8, 2014 01:41 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4160

Date: 2014-10-03

Value constraints

by Andrzej Krzemieński

Excerpt:

In this paper we want to analyse how a support for contract programming-like features could be implemented in C++. We use a different term "value constraints" to stress that we do not necessarily want to copy solutions that other imperative programming languages adapt. We want to change the focus from how broken contracts are responded to in run-time, to how contract violations can be detected at compile-time. This is a high-level overview of the problem, and we are not even covering the things like sub-contracting or other interactions with OO features.

N4155: Non-member size() and more (Revision 1) -- Riccardo Marcangelo

By Blog Staff | Oct 8, 2014 01:37 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4155

Date: 2014-09-28

Non-member size() and more (Revision 1)

by Riccardo Marcangelo

Excerpt:

This paper revises N4017 "Non-member size() and more" in response to feedback from the LEWG. Please see the original paper, N4017, for the rationale behind this proposal.

This paper includes the following changes from N4017 as requested by the LEWG:

  • Removed front() and back().
  • Added initializer_list support for the remaining functions (data() and empty()).

 

N4145: Data-Invariant Functions -- Jens Maurer

By Blog Staff | Oct 8, 2014 01:30 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4145

Date: 2014-09-26

Data-Invariant Functions

by Jens Maurer

Excerpt:

One of the hardest challenges when implementing cryptographic functionality with well-defined mathematical properties is to avoid side-channel attacks, that is, security breaches exploiting physical effects dependent on secret data when performing a cryptographic operation. Such effects include variances in timing of execution, power consumption of the machine, or noise produced by voltage regulators of the CPU. C++ does not consider such effects as part of the observable behavior of the abstract machine (C++ 1.9 [intro.execution]), thereby allowing implementations to vary these properties in unspecified ways.

As an example, this fairly recent patch for openssl replaced some if statements with open-coded operations that leak no timing information about the true vs. false outcome. In general, this is a sound approach, but it bears some risk in the framework of C and C++, because future optimizations in compilers might restore conditional branches under the as-if rule.

This paper proposes a small set of functions performing common tasks with physical execution properties that do not vary with (specified parts of) the input values. Such functions are called data-invariant functions. It is the responsibility of the implementation to ensure that they remain data-invariant even when optimizing.

This paper addresses parts of LEWG issue 15.

N4162: Atomic Smart Pointers, rev. 1 -- Herb Sutter

By Blog Staff | Oct 8, 2014 01:23 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4162

Date: 2014-10-06

Atomic Smart Pointers, rev. 1

by Herb Sutter

Excerpt:

This is a revision of N4058 to apply SG1 feedback in Redmond to rename atomic<*_ptr> to atomic_*_ptr, require default initialization to null, and add proposed wording.

N4164: Forwarding References -- Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis

By Blog Staff | Oct 7, 2014 01:44 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4164

Date: 2014-10-06

Forwarding References

by Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis

Excerpt:

To the C++ programmer, a parameter of type C&& is always an rvalue reference -- except when C is a template parameter type or auto, in which case it behaves very differently even though language-technically it is still an rvalue reference.

We intentionally overloaded the && syntax with this special case, but we did not give this special case a name. It needs a distinct name so that we can talk about it and teach it. This has already been discovered in the community, thanks to Scott Meyers in particular. [1]

In the absence of our giving this construct a distinct name, the community has been trying to make one. The one that is becoming popular is “universal reference.” [1] Unfortunately, as discussed in §3.1 below, this is not an ideal name, and we need to give better guidance to a suitable name.

The name that has the most support in informal discussions among committee members, including the authors, is “forwarding reference.” Interestingly, Meyers himself initially introduced the term “forwarding reference” in his original “Universal References” talk, [2] but decided to go with “universal references” because at the time he did not think that “forwarding references” reflected the fact that auto&& was also included; however, in §3.3 below we argue why auto&& is also a forwarding case and so is rightly included.

N4166: Movable initializer lists -- David Krauss

By Blog Staff | Oct 7, 2014 01:25 AM | Tags: None

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4166

Date: 2014-10-06

Movable initializer lists

by David Krauss

Excerpt:

Often std::initializer_list cannot be used, or it requires a const_cast hack, as it provides read-only access to its sequence. This is a consequence of the sequence potentially being shared with other initializer_list objects, although often it is statically known to be uniquely local. A new initializer list class template is proposed to allow function parameters which may leverage (by overloading) or require strict ownership. Addition of this class does not impinge on the cases where the sequence should be shared. No breaking changes are proposed.