Articles & Books

C++11 New Feature: auto Type Deduction -- FangLu

A new article on auto type deduction has been posted to IBM's C/C++ cafe.

C++11 new feature: auto type deduction

by FangLu

This article describes a new C++11 feature that deprecates the auto keyword as a storage class specifier, but reserves auto as a type specifier that directs the compiler to deduce the type of a declared variable from its initialization expression. This auto type deduction feature can increase programming convenience, eliminate potential typing errors, and simplify the code.

Optimizing C++ Code: Constant-Folding -- Jim Hogg

vc-team-blog.PNGThe Visual C++ Team Blog has been publishing an article series about optimizations that C++ compilers perform for you under the covers to make your code more efficient. This short nugget answers a question people sometimes ask: "What's constant folding, and why do I care?"

Optimizing C++ Code: Constant-Folding

by Jim Hogg

From the article:

This post examines Constant-Folding -- one of the simplest optimizations performed by the VC++ compiler.  In this optimization, the compiler works out the result of an expression while it is compiling (at “compile-time”), and inserts the answer directly into the generated code.  This avoids the cost of performing those same calculations when the program runs (at “runtime”).

Here is an example...

Quick Q: What's the weak_ptr equivalent for unique_ptr? -- StackOverflow

Quick A: There isn't, because unique_ptr is unique. If you want shared ownership or shared observation, you need a shared_ptr. The "shared"-ness in shared_ptr enables both shared ownership (shared_ptr) and shared observation (weak_ptr).

shared_ptr<> is to weak_ptr<> as unique_ptr<> is to... what?

In C++11, you can use a shared_ptr<> to establish an ownership relation with an object or variable and weak_ptr<> to safely reference that object in a non-owned way.

You can also use unique_ptr<> to establish an ownership relation with an object or variable. But what if other, non-owning objects want to also reference that object? weak_ptr<> isn't helpful in this case. Raw pointers are helpful but bring various downsides (e.g. they can be automatically initialized to nullptr but this is accomplished through techniques that are not consistent with the std::*_ptr<> types).

What is the equivalent of weak_ptr<> for non-owning references to objects owned via unique_ptr<>?

Working with Dynamic Memory in C++ -- Stan Lippman, Josée Lajoie, Barbara Moo

A chapter worth reading on InformIT, excerpted from C++ Primer 5th Edition:

Working with Dynamic Memory in C++

by Stan Lippman, Josée Lajoie, Barbara Moo

C++ lets you allocate objects dynamically. The authors of C++ Primer discuss why properly freeing dynamic memory is a rich source of bugs, and how the new library defines smart pointers -- shared_ptr, unique_ptr, and weak_ptr -- that make managing dynamic memory much safer.

Quick Q: How do you have an STL container of polymorphic objects? -- StackOverflow

Quick A: Try vector<unique_ptr<base>> by default.

What's the preferred C++ idiom to own a collection of polymorphic objects?

... I'm sure there's something related to move semantics in there (I could move the objects passed to add_items() to own them) but I still can't figure out how my collection would be declared.

What is the C++ idiom for this sort of polymorphic ownership (particularly with STL containers)?

When decltype meets auto -- Scott Meyers

A fresh Scott Meyers post about a brand-new C++14 feature:

When decltype meets auto

by Scott Meyers

... C++14 is on the horizon, and one of the new features sure to stifle even the strongest of yawns is the ability to declare types using decltype(auto). This feature leads to two questions, only the first of which is rhetorical:

  1. You can declare what?
  2. During type deduction for decltype(auto), which type deduction rules are to be followed: those for auto or those for decltype? Or does decltype(auto) have its own set of type deduction rules?

Quick Q: How do I remove a unique_ptr from a queue? -- StackOverflow

Quick A: move(q.front()).

remove unique_ptr from queue

I'm trying to figure out how/if I can use unique_ptr in a queue.

// create queue
std::queue<std::unique_ptr<int>> q;

// add element
std::unique_ptr<int> p (new int{123});
q.push(std::move(p));

// try to grab the element
auto p2 = foo_queue.front();
q.pop();

I do understand why the code above doesn't work. Since the front & pop are 2 separate steps, the element cannot be moved. Is there a way to do this?

Living with Lambdas -- Alfons Haffmans

living-with-lambdas.PNGWe have such a powerful language, and what a powerful language it is.

Living with Lambdas

by Alfons Haffmans

From the article:

You can work in the functional programming paradigm in C++. And you may be surprised at how complete C++’s support for functional programming is.

... C++ has always been a multi-paradigm language. And while previous attempts to add practical functional programming features required significant effort, recent additions to the C++ standard, like lambdas, have improved the situation. This paper explores the out-of-box support for functional programming provided by the new standard. We’ll look at techniques typically found in introductory functional programming textbooks. This article assumes familiarity with C++, but not necessarily with basic functional programming.

The source code is available in github and is compiled using gcc 4.8 installed on Mac OSX using MacPorts.

Quick Q: What are move semantics? -- StackOverflow

One of the highest-ranked C++ questions (and answers) on StackOverflow is worth re-reading if you're new to the topic:

What are move semantics?

I just finished listening to the Software Engineering talk radio podcast interview with Scott Meyers regarding C++0x. Most of the new features made sense to me, and I am actually excited about C++0x now, with the exception of one. I still don't get move semantics... What are they exactly?