Ranges for the Standard Library -- Eric Niebler

By Blog Staff | Oct 13, 2014 05:41 AM | Tags: None

Fresh over the weekend, and in this morning's Standardization feed:

N4128: Ranges for the Standard Library

by Eric Niebler

From the article:

Eleven months ago, I began work on an updated range library for modern C++. Yesterday, I submitted a proposal to the C++ standardization committee to add ranges to the Standard Library. The proposal presents a vision for a future Standard Library that is familiar and yet more powerful, more usable, and more efficient than today’s.

My goal is nothing less than to change how C++ programmers write code. Seriously.

Overload 123 is now available

By Blog Staff | Oct 10, 2014 07:14 AM | Tags: None

Overload 123 is now available. It contains the following C++-related articles, and more:

Overload 123

Alternative Overloads

[No pun intended. --Ed.] How do you return a default value given a condition? Malcolm Noyes presents solutions using older and newer C++ techniques.

Debug Complexity: How Assertions Affect Debugging Time

Debugging any program can be time consuming. Sergey Ignatchenko and Dmytro Ivanchykhin extend their mathematical model to consider the effect of assertions.

Defining Visitors Inline in Modern C++

The Visitor pattern can involve non-local boilerplate code. Robert Mill and Jonathan Coe present an inline VISITOR in C++.

Quick Q: Why is "want speed? pass by value" not recommended? -- StackOverflow

By Blog Staff | Oct 9, 2014 08:41 AM | Tags: basics

Quick A: Because it performs worse than C++98 for common types like string and vector. The preferred way to optimize for rvalues is to add a && overload.

Fresh on SO:

Why is value taking setter member functions not recommended in Herb Sutter's CppCon 2014 talk (Back to Basics: Modern C++ Style)?

In Herb Sutter's CppCon 2014 talk Back to Basics: Modern C++ Style he refers on slide 28 (a web copy of the slides are here) to this pattern:

class employee {
  std::string name_;
public:
  void set_name(std::string name) noexcept { name_ = std::move(name); }
};

He says that this is problematic because when calling set_name() with a temporary, noexcept-ness isn't strong (he uses the phrase "noexcept-ish").

Now, I have been using the above pattern pretty heavily in my own recent C++ code mainly because it saves me typing two copies of set_name() every time -- yes, I know that can be a bit inefficient by forcing a copy construction every time, but hey I am a lazy typer. However Herb's phrase "This noexcept is problematic" worries me as I don't get the problem here: std::string's move assignment operator is noexcept, as is its destructor, so set_name() above seems to me to be guaranteed noexcept. I do see a potential exception throw by the compiler before set_name() as it prepares the parameter, but I am struggling to see that as problematic.

Later on on slide 32 Herb clearly states the above is an anti-pattern. Can someone explain to me why lest I have been writing bad code by being lazy?

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?

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...

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...

Quick Q: How can I call a function only one? -- StackOverflow

By Blog Staff | Oct 3, 2014 05:34 AM | Tags: None

Quick A: std::call_once.

Recently on StackOverflow:

Standard library function for running a function only once

Is there some standard library function/class the behaviour of this lambda expression:

void some_func(int some_arg, float some_other_arg){
    static int do_once = ([](){
        // will be run once upon first function call but never again
        return 0; // dummy return value
    })();
    // will always run
}

t feels like such a hack to write this, but I can't think of another way of doing this other than simply calling the function in main, but what I'm actually doing depends upon template parameters and I need to keep it as generic as possible.

For context: I register a function with atexit for every different template parameter, but only once: the first time it is called.

GEANT4: Forecasting the future -- Monica Friedlander

By Blog Staff | Oct 3, 2014 12:35 AM | Tags: None

A widely-used C++ program you might never have heard of: Physicists and other scientists use the GEANT4 toolkit to identify problems before they occur.

GEANT4: Forecasting the future

By Monica Friedlander

From the article:

Physicists can tell the future -- or at least foresee multiple possible versions of it. They do this through computer simulations. Simulations can help scientists predict what will happen when a particular kind of particle hits a particular kind of material in a particle detector. But physicists are not the only scientists interested in predicting how particles and other matter will interact. This information is critical in multiple fields, especially those concerned about the effects of radiation.

At CERN in 1974, scientists created the first version of GEANT (Geometry and Tracking) to help physicists create simulations. Today it is in its fourth iteration, developed by an international collaboration of about 100 scientists from 19 countries. Anyone can download the system to a personal computer, use C++ programming language to plug in details about the particle and material in question and find out what will happen when the two meet.

GEANT4 is used in some of the most advanced accelerator experiments in the world, but its user base has grown beyond the particle physics community...