Home » Blog » Tags » basics

basics

An Important Move Optimization Is Nearly Invisible -- Andrew Koenig

By Blog Staff | Aug 15, 2013 01:13 PM | Tags: basics

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

By Blog Staff | Aug 14, 2013 04:53 PM | Tags: intermediate basics

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

By Blog Staff | Jul 31, 2013 03:54 PM | Tags: basics

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

By Blog Staff | Jul 30, 2013 02:09 PM | Tags: basics

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.

By Blog Staff | Jul 30, 2013 09:32 AM | Tags: basics

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

By Blog Staff | Jul 26, 2013 11:06 AM | Tags: basics

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

The Point of No Return -- bulldozer00

By Blog Staff | Jul 24, 2013 04:20 AM | Tags: basics

A cute nugget about [[noreturn]]:

The Point of No Return

by bulldozer00

As part of learning the new feature set in C++11, I stumbled upon the weird syntax for the new “attribute” feature: [[ ]]. One of these new C++11 attributes is [[noreturn]]. ...

Quick Q: When should you use constexpr? -- StackOverflow

By Blog Staff | Jul 23, 2013 10:10 PM | Tags: basics

Quick A: When you want to potentially evaluate a calculation at compile time. You can do much, much more than just "return 5;".

When should you use constexpr capability in C++11?

It seems to me that having a "function that always returns 5" is breaking or diluting the meaning of "calling a function". There must be a reason, or a need for this capability or it wouldn't be in C++11. Why is it there?

// preprocessor.
#define MEANING_OF_LIFE 42
// constants:
const int MeaningOfLife = 42;
// constexpr-function:
constexpr int MeaningOfLife () { return 42; }

It seems to me that if I wrote a function that return a literal value, and I came up to a code-review, someone would tell me, I should then, declare a constant value instead of writing return 5.