Home » Blog » Categories »

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.

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

By Blog Staff | Oct 7, 2014 08:40 AM | Tags: basics

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

By James | Oct 7, 2014 08:13 AM | Tags: None

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

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)?