basics

GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1—Herb Sutter

The solution to the latest GotW problem is now available. In this Item, the focus is on analyzing and managing compile-time dependencies.

    GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1

    by Herb Sutter

From the article:

Managing dependencies well is an essential part of writing solid code. C++ supports two powerful methods of abstraction: object-oriented programming and generic programming. Both of these are fundamentally tools to help manage dependencies, and therefore manage complexity. It’s telling that all of the common OO/generic buzzwords—including encapsulation, polymorphism, and type independence—along with most design patterns, are really about describing ways to manage complexity within a software system by managing the code’s interdependencies.

When we talk about dependencies, we usually think of run-time dependencies like class interactions. In this Item, we will focus instead on how to analyze and manage compile-time dependencies. As a first step, try to identify (and root out) unnecessary headers.

Guideline: Never #include unnecessary header files.

Guideline: Prefer to #include <iosfwd> when a forward declaration of a stream will suffice.

Guideline: Never #include a header when a forward declaration will suffice.

Continue reading...

Overload 116 available

overload-116.PNGOverload 116 is now available. It contains the following articles, and more:

 

Overload 116

Auto -- A Necessary Evil? Part 2 -- Roger Orr

When is the use of auto good, and when is it evil?

Dynamic C++, Part 2 -- Alex Fabijanic

Alex Fabijanic and Richard Saunders continue to explore dynamic solutions in C++.

Portable String Literals in C++ -- Alf Steinbach

How hard can it be to make a file in C++ with international text literals in its name? Alf Steinbach shows us how to write a file called π.recipe.

Hard Upper Limit on Memory Latency -- Sergey Ignatchenko

How low can latency really get?

 

... and more!

An Important Move Optimization Is Nearly Invisible -- Andrew Koenig

Today in Dr. Dobb's:

An Important Move Optimization Is Nearly Invisible

by Andrew Koenig

From the article:

Last week, we looked at subtle differences between copying and moving a container (a string in this example) in the context of passing arguments to functions. Curiously, one of the biggest differences between copying and moving happens in code that we don't write. ...

The improvements in robustness and functionality that stem from moving instead of copying are, in my view, at least as important as the optimization. ...

GotW #94 Solution: AAA Style (Almost Always Auto) -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #94 Solution: AAA Style (Almost Always Auto)

by Herb Sutter

From the article:

4. When declaring a new local variable x, what advantages are there to declaring it using auto and one of the two following syntaxes:

(a) auto x = init; when you don’t need to commit to a specific type? (Note: The expression init might include calling a helper that performs partial type adjustment, such as as_signed, while still not committing to a specific type.)

(b) auto x = type{ init }; when you do want to commit to a specific type by naming a type?

Why Would You Ever Pass a Container By Value? -- Andrew Koenig

From the desk of ARK:

Why Would You Ever Pass a Container By Value?

by Andrew Koenig

From the article:

Consider two fundamental features of C++: functions and references. Which shall we teach first?

If we teach references first, there is the problem of coming up with interesting example programs that use references but completely avoid user-defined functions. This is hard to do because the most common use of references is as function parameters — so it's probably easier to teach functions first.

However, if we teach functions before we teach references, then every function we write must accept its arguments by value — references not yet being available as an alternative...

Quick Q: Why do I have to std::move a variable that is already a &&? -- StackOverflow

Today on SO, a frequently asked question and a nicely summed up answer:

std::move on a variable which already is T&&

On the page http://msdn.microsoft.com/en-us/library/dd293665.aspx Microsoft has an example on how to write a move constructor. It is essentially of the form:

MyClass::MyClass(MyClass&& lhs)
{
    *this = std::move(lhs);
}

I have tried and std::move really is required here, but why? I thought the only thing move did was to convert to T&&. But lhs is already of type MyClass&&, is it not?

Some Notes on C++11 Lambda Functions -- Ranju V.

ranjuv.jpgHere's a nice lambda synopsis with some usage notes.

Some notes on C++11 lambda functions

by Ranju V.

From the article:

Bjarne Stroustrup says that C++11, which is the latest ratified revision of the C++ standard, “feels like a new language”.  I think lambda functions are a big part of what makes the language feel so very different from C++03.  Lambda functions basically allow you to do things like this:

vector<int> nums { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
auto evens = count_if(begin(nums), end(nums), [](int num) {
    return (num % 2) == 0;
});

Is Moving Objects Worth the Hassle? -- Andrew Koenig

Koenig's latest just went live at DDJ:

Is Moving Objects Worth the Hassle?

by Andrew Koenig

From the article:

Last week, I discussed how C++ compilers use overloading to decide whether to move or copy an object. This week, I'd like to take a step back and discuss why moving instead of copying is worth doing in the first place.

You might think that this claim needs no justification. After all, copying takes time; so programs that copy a lot of data will be slower than programs that avoid doing so. However, this kind of unthinking optimization can lead to trouble. For example...