N4318: Proposal to add an absolute difference function to the C++ Standard Library -- J. Turnbull

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

Date: 2014-09-21

Proposal to add an absolute difference function to the C++ Standard Library

by Jeremy Turnbull

Excerpt:

This document proposes the addition of the abs_diff() template function to the C++ Standard Library. This function computes the absolute difference between two parameters of a type that supports the operator<() and operator-() functions, or other functions of equivalent logic, without computing a logically negative value during function execution.

N4274: Relaxing Packaging Rules for Exceptions... Proposed Wording (Revision 1) -- A. Robison et al.

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

Date: 2014-11-14

Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms - Proposed Wording (Revision 1)

by Arch D. Robison, Jared Hoberock, Artur Laksberg

Excerpt:

N4157 described the rationale for changing a future revision of N4105 to relax exception packaging rules. Speci cally, the change permits an implementation to throw an exception that is not an exception_list if only one invocation of an element access function throws an exception. Unfortunately, the proposed wording in N4157 did not completely fix the problem. This document proposes new rewording.

N4317: New Safer Functions to Advance Iterators -- Patrick Grace

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

Date: 2014-11-17

New Safer Functions to Advance Iterators

by Patrick Grace

Excerpt:

This is a simple proposal to add new safer more robust versions of advance, next, and prev for iterators to the standard C++ library.

N4315: make_array, revision 3 -- Zhihao Yuan

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

Date: 2014-11-07

make_array, revision 3

by Zhihao Yuan

Excerpt:

Changes since N4065

  • Merge make_array and array_of into one.
  • Cleanup notes for presentation.

N4314: Data-Invariant Functions (revision 2) -- 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: N4314

Date: 2014-11-15

Data-Invariant Functions (revision 2)

by Jens Maurer

Excerpt:

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.

N4309: Return type deduction for explicitly-defaulted & deleted special member functions -- M. Price

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

Date: 2014-11-17

Return type deduction for explicitly-defaulted and deleted special member functions

by Miohael Price

Excerpt:

Proposes to allow auto and declspec(auto) as the type-specifiers for the return type of explicitly-defaulted and deleted special member functions. It seems this case was left out of N3638.

N4263: Toward a concept-enabled standard library -- Matt Austern et al.

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

Date: 2014-11-04

Toward a concept-enabled standard library

by Matt Austern, Gabriel Dos Reis, Eric Niebler, Bjarne Stroustrup, Herb Sutter, Andrew Sutton, Jeffrey Yasskin

Excerpt:

Now that the Concepts Lite TS is (almost) done, the next step is a version of the standard library that uses Concepts. Here are some informal notes on what we might want from such a library and what some of the incremental steps are for getting there.

N4316: std::rand replacement, revision 2 -- Zhihao Yuan

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

Date: 2014-11-08

std::rand replacement, revision 2

by Zhihao Yuan

Excerpt:

Changes since N4217

  • Rename the seeding utility to reseed, which resets the distributions’ states if needed, based on SG6 comments.
  • Cleanup the wording with the term “unpredictable state” stolen from Walter’s paper[1].
  • Ask the question about exposing the per-thread engine in Future Issues.
  • Update motivation to reflect the status quo.

 

Cevelop Updated for the Eclipse Luna Service Release 1 -- Mirko Stocker

News about Cevelop, a C++ IDE for professional developers from the Institute for Software at HSR Hochschule für Technik:

Cevelop Updated for the Eclipse Luna Service Release 1

by Mirko Stocker

From the announcement:

We have rebased Cevelop on top of the latest Eclipse Luna Service Release SR1. The Eclipse CDT team used the chance to include some new features. For example, code completion can now show default arguments and gives you more information on template parameters... See the CDT 8.5 changelog for a comprehensive list of changes.

Quick Q: Which is more efficient, push_back(move(var)) or emplace_back(var)? -- StackOverflow

Quick A: 1. Those cases are not equivalent. 2. Emplace is more for when you don't already have a named object of the correct type...

Recently on SO:

Efficiency of C++11 push_back() with std::move versus emplace_back() for already constructed objects

In C++11 emplace_back() is generally preferred (in terms of efficiency) to push_back() as it allows in-place construction, but is this still the case when using push_back(std::move()) with an already-constructed object?

For instance, is emplace_back() still preferred in cases like the following?

std::string mystring("hello world");
std::vector<std::string> myvector;

myvector.emplace_back(mystring);
myvector.push_back(std::move(mystring));
// (of course assuming we don't care about using the value of mystring after)

Additionally, is there any benefit in the above example to instead doing:

myvector.emplace_back(std::move(mystring));

or is the move here entirely redundant, or has no effect?