Articles & Books

GotW #93 Solution: Auto Variables, Part 2 -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #93 Solution: Auto Variables, Part 2

by Herb Sutter

From the article:

As you worked through these cases, perhaps you noticed a pattern: The cases are mostly very different, but what they have in common is that they illustrate reason after reason motivating why (and how) to use auto to declare variables.

Let’s dig in and see...

When Is It Safe to Move an Object Instead of Copying It? -- Andrew Koenig

andy1.jpgARK's latest, hot off the press:

When Is It Safe to Move an Object Instead of Copying It?

by Andrew Koenig

From the article:

Last week, I introduced the idea of moving objects, and explained that moving an object is usually better than copying it if the original is not going to be used again. Now I'd like to explain how the compiler can figure out during compilation when to move objects instead of copying them.

As is so often the case with such problems, the obvious solution is wrong. Consider this code fragment: ...

Quick Q: What type to return from a property-style "getter"? -- StackOverflow

Quick A: Reference to const.

c++11 -- Ownership and getters

I'm new to C++ and I have troubles wrapping my head around ownership, specifically with a getter. Here's some example code:

class GameObject {
public:
  Transform *transform();
private:
  Transform _transform;
};

I guess a raw pointer is unsafe to use as someone could access it later when the object doesn't exist anymore?

  1. So I thought about using a unique_ptr for the transform member, since GameObject is the only one that owns the transform. But I can't return that from the getter, can I? But then again, why would I ever use a unique_ptr in the first place instead of adding it as a member like above?
  2. So why not use a shared_ptr? It just seems wrong to me, I don't want to share ownership, GameObject is the owner and others may access it...
  3. So what is it? A reference? I guess shared_ptr seems the wisest choice, since others could safely keep a reference to transform, but what good is that if the enclosing GameObject got destroyed, rendering the transform useless? I'm probably just thinking about ownership the wrong wrong way here but every way seems wrong to me. Thanks for your help.

Quick Q: In a function template, why pass const T& vs. T&&? -- StackOverflow

Quick A: Because you want to not change the argument, or you want to forward it, respectively.

c++ rvalue reference and const qualifier

Among the many benefits of const qualification is to make an API more understandable, example:

template<typename T> int function1(T const& in);
// clearly, the input won’t change through function1

With the introduction of rvalue references, one can benefit from perfect forwarding but often const qualifiers are removed, example:

template<typename T> int function2(T&& in);
// can explicitly forward the input if it's an rvalue

Apart from documentation, is there a good way to describe that function2 won’t change its input?

Quick Q: Is atomic decrementing more expensive than incrementing? -- StackOverflow

Quick A: No, not in general. Yes, in the specific case of a reference counted smart pointer which can take advantage of its special semantics.

Is atomic decrementing more expensive than incrementing?

In his Blog Herb Sutter writes

[...] because incrementing the smart pointer reference count can usually be optimized to be the same as an ordinary increment in an optimized shared_ptr implementation — just an ordinary increment instruction, and no fences, in the generated code.

However, the decrement must be an atomic decrement or equivalent, which generates special processor memory instructions that are more expensive in themselves, and that on top of that induce memory fence restrictions on optimizing the surrounding code.

The text is about the implementation of shared_ptr and I am not sure if his remark applies only on this or is generally the case. From his formulation I gather it is generally.

But when I think about it I can only think of "more expensive decrement" when a if(counter==0) immediately follows -- which probably is the case with shared_ptr.

Therefore I wonder if the atomic operation ++counter is (usually) always faster than --counter, or just because it is used if(--counter==0)... with shared_ptr?

Quick Q: What's the difference between lambda [x]()mutable{++x;} and [&x](){++x;}? -- StackOverflow

Quick A: [x] captures a copy, [&x] remembers a reference to the original variable.

C++ Lambdas: Difference between “mutable” and capture-by-reference

In C++ you can declare lambdas for example like this:

int x = 5;
auto a = [=]() mutable { ++x; std::cout << x << '\n'; };
auto b = [&]()         { ++x; std::cout << x << '\n'; };

Both let me modify x, so what is the difference?

GotW #92 Solution: Auto Variables, Part 1 -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #92 Solution: Auto Variables, Part 1 (updated for C++11/14)

by Herb Sutter

From the article:

When you’re new to auto, the key thing to remember is that you really are declaring your own new local variable. That is, “what’s on the left” is my new variable, and “what’s on the right” is just its initial value:

auto my_new_variable = its_initial_value;

You want your new variable to be just like some existing variable or expression over there, and be initialized from it, but that only means that you want the same basic type, not necessarily that other variable’s own personal secondary attributes such as top-level const-ness and reference-ness which are per-variable. For example, just because he’s const doesn’t mean you’re const, and vice versa.

It’s kind of like being identical twins: Andy may be genetically just like his brother Bobby and is part of the same family, but he’s not the same person; he’s a distinct person and can make his own choice of clothes and/or jewelry, go to be seen on the scene in different parts of town, and so forth. So your new variable will be just like that other one and be part of the same type family, but it’s not the same variable; it’s a distinct variable with its own choice of whether it wants to be dressed with const and/or a reference, may be visible to different threads, and so forth.

Remembering this will let us easily answer the rest of our questions...