Home » Blog » Categories »

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.

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

By Blog Staff | Oct 7, 2014 01:21 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: 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.

N4154: Operator assert -- David Krauss

By Blog Staff | Oct 7, 2014 01:17 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: N4154

Date: 2014-09-30

Operator assert

by David Krauss

Excerpt:

The assert macro has never behaved much like a real function, and for the foreseeable future, it will look and smell like an operator. The way the macro is specified by C precludes it from providing optimization hints in production mode, but allows it to execute arbitrary side effects in debug mode. Adding assert as a keyword and built-in operator would have benefits but essentially no downside.

This will resolve LWG DR 2234 and 2413.

Ranges in C++: Counted Iterables and Efficiency -- Eric Niebler

By Blog Staff | Oct 7, 2014 12:34 AM | Tags: experimental

New in Eric's series on ranges for C++:

Ranges in C++: Counted Iterables and Efficiency

by Eric Niebler

From the article:

I’ve been hard at work fleshing out my range library and writing a proposal to get range support into the standard. That proposal describes a foundational range concept: Iterable. An Iterable is anything we can pass to std::begin() and std::end() to get an Iterator/Sentinel pair. Sentinels, as I described here earlier this year, make it possible for the Iterable concept to efficiently describe other kinds of ranges besides iterator pairs.

The three types of ranges that we would like the Iterable concept to be able to efficiently model are:

  • Two iterators
  • An iterator and a predicate
  • An iterator and a count
The Iterator/Sentinel abstraction is what makes it possible for the algorithms to handle these three cases with uniform syntax. However, as Sean Parent pointed out here, the third option presents challenges when trying to make some algorithms optimally efficient. Back in February, when Sean offered his criticism, I promised to follow up with a blog post that justified the design. This is that post.

Quick Q: Should I prefer non-member std::begin and std::end? -- StackOverflow

By Blog Staff | Oct 5, 2014 09:26 PM | Tags: intermediate

Quick A: Yes.

A classic on SO, just re-asked yesterday:

When to use std::begin and std::end instead of container specific versions

Are there any general preferences or rules that explain when container specific versions of begin and end should be used instead of free functions std::begin and std::end?

It is my understanding that if the function is a template whereby the container type is a template parameter then std::begin and std::end should be used, i.e.:

template<class T> void do_stuff( const T& t )
{
    std::for_each( std::begin(t), std::end(t), /* some stuff */ );
}

What about in other scenarios such as a standard / member function where the type of container is known? Is it still better practice to use std::begin(cont) and std::end(cont) or should the container's member functions cont.begin() and cont.end() be preferred?

Am I correct in assuming that there is no benefit in performance by calling cont.end() over std::end(cont)?

ACCU 2015 Call for Papers

By Blog Staff | Oct 4, 2014 12:03 AM | Tags: None

ACCU 2015 is now putting together its program, and they want you to speak on C++. ACCU has long had a strong C++ track, though it is not a C++-only conference. If you have something to share, check out the call for papers. 

Call for Papers

ACCU 2015

We invite you to propose a session for this leading software development conference...

The Call for Papers lasts 5 weeks and will close at midnight Wednesday 5th November 2014. Remember, remember, the 5th of November...

N4152: uncaught_exceptions -- Herb Sutter

By Blog Staff | Oct 3, 2014 10:40 PM | 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: N4152

Date: 2014-09-30

uncaught_exceptions

by Herb Sutter

Excerpt:

This paper is a revision of N3614 to implement EWG direction in Bristol.

...

This paper proposes a new function int std::uncaught_exceptions() that returns the number of exceptions currently active, meaning thrown or rethrown but not yet handled.

Insights into new and C++

By Meeting C++ | Oct 3, 2014 07:49 AM | Tags: performance intermediate efficiency c++14 c++11 boost basics

I've written down some basic thinking on new and new standards:

Insights into new and C++

by Jens Weller

From the article:

Every now and then, I've been thinking about this. So this blogpost is also a summary of my thoughts on this topic, dynamic memory allocation and C++. Since I wrote the blog entries on smart pointers, and C++14 giving us make_unique, raw new and delete seem to disappear from C++ in our future code...