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?

Variadic Templates -- Feabhas

By Blog Staff | Sep 29, 2014 12:24 AM | Tags: intermediate

Recently on StickyBits, a nice primer on variadics:

Variadic Templates

by feabhas

From the article:

In this article we’re going to look at a new feature of templates in C++11 -- the concept of the variadic template.

Variadic templates allow us to create functions and classes, not only with generic types, but also a variable number of generic types.

If you haven’t been following along with the template articles, I’d suggest you read this article first before continuing.

A Grand Introduction: Stepanov introduces Stroustrup at CppCon -- Tony DaSilva

By Blog Staff | Sep 29, 2014 12:09 AM | Tags: None

Bulldozer00's appreciation for Alex Stepanov's introduction for Bjarne Stroustrup at CppCon. We already linked to the video last week -- but if you didn't watch it then, do yourself a favor and spend 6 minutes now getting your workweek off to a great start.

A Grand Introduction

by Tony DaSilva

From the article:

"We should not be ashamed of bits. We should be proud of them." -- Alex Stepanov

You may not interpret it in the same way as I did, but I found this cppcon conference introduction of Bjarne Stroustrup by programming scholar Alex Stepanov very moving...