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

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.

Templates of Templates -- Feabhas

By Blog Staff | Oct 2, 2014 09:40 AM | Tags: None

On Sticky Bits:

Templates of Templates

by Feabhas

From the article:

In this brief article we’ll have a look at the topic of building template classes whose parameters are themselves templates.

I’m assuming you’re reasonably familiar with template classes.  If not, here’s a quick introduction...

Quick Q: Do smart pointers help replace raw pointers? -- StackOverflow

By Blog Staff | Oct 1, 2014 09:47 AM | Tags: basics

Quick A: Yes, smart pointers replace owning raw pointers, and you should prefer smart pointers in new code. Raw pointers and references are still appropriate to pass parameters down a stack.

Recently on SO:

C++ 11 Smart Pointer usage

I have a question about smart pointers in c++ 11. I've started to have a look at C++ 11 (I usualy program in c#) and read some thing about smart pointers. Now i have the question, does smart pointers completely replace the "old" style of pointers, should i always use them?

And In the Beginning... -- Tony DaSilva

By Blog Staff | Oct 1, 2014 06:16 AM | Tags: None

We don't normally link to pleas to spam mass-email anyone, never mind Bjarne Stroustrup, but we just had to share this heartfelt plea because it would be Good for the World. (Sorry, Dr. Stroustrup!)

But even if you don't email him, read or re-read D&E. It's still quite current.

And In the Beginning...

by Tony DaSilva

From the article:

I’m on my second pass through Bjarne Stroustrup’s "The Design And Evolution Of C++". In the book...

Quick Q: Why can noexcept generate faster code than throw()? -- StackOverflow

By Blog Staff | Sep 30, 2014 09:51 AM | Tags: None

Quick A: Because noexcept doesn't have to keep track of stack unwinding.

noexcept, stack unwinding, and performance

The following draft from Scott Meyers new C++11 book says (page 2, lines 7-21)

The difference between unwinding the call stack and possibly unwinding it has a surprisingly large impact on code generation. In a noexcept function, optimizers need not keep the runtime stack in an unwindable state if an exception would propagate out of the function, nor must they ensure that objects in a noexcept function are destroyed in the inverse order of construction should an exception leave the function. The result is more opportunities for optimization, not only within the body of a noexcept function, but also at sites where the function is called. Such flexibility is present only for noexcept functions. Functions with “throw()” exception specifications lack it, as do functions with no exception specification at all.

In contrast, section 5.4 of "Technical Report on C++ Performance" describes the "code" and "table" ways of implementing exception handling. In particular, the "table" method is shown to have no time overhead when no exceptions are thrown and only has a space overhead.

My question is this - what optimizations is Scott Meyers talking about when he talks of unwinding vs possibly unwinding? Why don't these optimizations apply for throw()? Do his comments apply only to the "code" method mentioned in the 2006 TR?