Home » Blog » Categories » Articles & Books

Articles & Books

Explicit Is Better Than Implicit -- K-ballo

By Blog Staff | Jun 21, 2013 01:52 PM | Tags: intermediate explicit conversions basics

tales-of-cpp.PNGTales of C++, Episode 5:

Explicit Is Better Than Implicit

The Zen of Python tell us that Explicit is better than Implicit. This is good advice for any and all languages, but what are the implications in the C++ lands? There is one particular C++ feature that relates directly to that advice; one important enough that grants on its own the introduction of a keyword. That feature is user-defined conversions and that keyword is explicit.

Quick Q: Am I capturing a member variable by value? -- StackOverflow

By Blog Staff | Jun 19, 2013 03:35 PM | Tags: intermediate

Quick A: No. You're capturing "this" by value, which is a pointer, which effectively captures members by reference.

From StackOverflow:

Lambda captures and member variables

I was watching Herb Sutter's talk at the C++ and Beyond 2012 conference on Concurrency and he talks about creating a non-blocking wrapper class, which he calls concurrent<T>, with C++11 functions.

His implementation is fairly simple (aside from needing a concurrent_queue such as that which exists in Microsoft's PPL):

template <class T>
class concurrent {
private:
    mutable T t;
    mutable concurrent_queue<std::function<void()>> q;
    bool done = false;
    std::thread thread;

public:
    concurrent( T t_ = T{} ) : t{t_}, thread{ [=]{ while( !done ) q.pop()(); }} {}

    ~concurrent() { q.push( [=]{ done = true; } ); thread.join(); }

    template <typename F>
    void operator()( F f ) const { q.push( [=]{ f(t); } ); }

};

This seems simple enough, however, I'm confused as to why he has captured the member variables done and q by value instead of by reference? My understanding is that if they are captured by value then they will be copied to the thread and thus when the queue is updated the worker thread will not receive the updates?

Have I misunderstood how lambda captures work with regards to class member variables? No one said anything in the comments to the video or during the talk so I am assuming that my understanding is faulty, in which case could someone please clarify?

Regular Expressions 101: Regex in C++11 -- Brian Overland

By Blog Staff | Jun 14, 2013 04:43 PM | Tags: intermediate

overland_brian_c.jpgNew at InformIT:

Regular Expressions 101: Regex in C++11

by Brian Overland

From the article:

... You don't really need to know how it works. In fact, you only need to know a few things:

  • The regular expression grammar used by the C++11 regex library functions
  • The relevant C++11 functions and how to call them

The first part of this article focuses on the default regex grammar used in C++11: the ECMAScript grammar. You'll generally want to use ECMAScript, because it provides powerful capabilities while being easy to use. For simplicity, I'll focus on this grammar. ...

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

By Blog Staff | Jun 14, 2013 04:36 PM | Tags: intermediate basics

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

By Blog Staff | Jun 13, 2013 04:28 PM | Tags: intermediate

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

By Blog Staff | Jun 11, 2013 03:40 PM | Tags: return type ownership getters basics

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

By Blog Staff | Jun 10, 2013 01:07 PM | Tags: basics

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

By Blog Staff | Jun 10, 2013 01:51 AM | Tags: None

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?