October 2014

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

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

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

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.

Quick Q: Why did C++ add delegating constructors? -- StackOverflow

Quick A: Because they reduce code duplication, and so make code more readable and maintainable.

Recently on SO:

Why did C++11 introduce delegating constructors?

I cannot understand what the use is of delegating constructors. Simply, what cannot be achieve without having delegating constructors?

It can do something simple like this

class M
{
 int x, y;
 char *p;
public:
 M(int v) : x(v), y(0), p(new char [MAX]) {}
 M(): M(0) {cout<<"delegating ctor"<<endl;}
};

But I don't see it, is it worth introducing a new feature for such a simple thing? May be I couldn't recognize the important point. Any idea?

CppDepend 5 Released

CppDepend allows architects and developers to analyze a code base, automate code reviews, and facilitate refactoring and migration. It’s based on Clang for more reliability and lets queries the code base over LINQ queries thanks to CQLinq.

New features in CppDepend v5.0 include:

  • Import result files of other static analyzer like CppCheck and CPD,
  • Hundred of Clang diagnostics are available and it can be easily queried using CQLinq.
  • Custom CQLinq extensions which allows you to write elaborated CQLinq queries,
  • Support for C++14: CppDepend works with the last version of Clang which implement all of the Draft International Standard of the upcoming C++14 language standard,
  • Advanced integration with CppCheck,
  • The directory/file organization for C projects.

Open Source project license terms<span 1;"="">.

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

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

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.

N4157: Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms -- Arch Robison

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

Date: 2014-10-02

Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms

by Arch Robison

Excerpt:

If an algorithm invocation throws only a single exception, then it should be allowed to propagate the singleton exception directly instead of returning it wrapped in an exception_list.