Articles & Books

GotW #90 Solution: Factories -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #90 Solution: Factories (updated for C++11/14)

by Herb Sutter

From the article:

Guideline: A factory that produces a reference type should return a unique_ptr by default, or a shared_ptr if ownership is to be shared with the factory.

Guideline: A factory that produces a non-reference type should return a value by default, and throw an exception if it fails to create the object. If not creating the object can be a normal result, return an optional<> value.

C++ auto and decltype Explained -- Thomas Becker

Here's a nice detailed treatment of auto and decltype by longtime author Thomas Becker.

C++ auto and decltype Explained

by Thomas Becker

From the article:

A while later, sometime in 2012, I noticed that there was another feature, or rather, a pair of features, in C++11 that I had not fully understood, namely, the auto and decltype keywords. With auto and decltype, unlike rvalue references, the problem is not that they are difficult to grasp. On the contrary, the problem is that the idea is deceptively easy, yet there are hidden subtleties that can trip you up.

Let's start with a good look at the auto keyword...

GotW #6b Solution: Const-Correctness, Part 2 -- Herb Sutter

The solution to GotW #6b is now available:

GotW #6b Solution: Const-Correctness, Part 2 (updated for C ++11/14)

by Herb Sutter

From the article:

Option 1 is to use a mutex in the perhaps-soon-to-be-canonical “mutable mutex mutables” pattern:

// Option 1: Use a mutex

    double get_area() const {
        auto lock = unique_lock<mutex>{mutables};
        if( area < 0 )   // if not yet calculated and cached
            calc_area();     // calculate now
        return area;
    }

private:
    // ...
    mutable mutex  mutables;      // canonical pattern: mutex that
    mutable double area;          //   covers all mutable members

Option 1 generalizes well if you add more data members in the future. However, it’s also more invasive and generalizes less well if you add more const member functions in the future that use area, because they will all have to remember to acquire a lock on the mutex before using area.

Option 2 is to just change double to mutable atomic<double>. ...

 

Stroustrup's "Software Development for Infrastructure" paper selected by CR Best of 2012

From the TAMU CS blog:bs-sdfi.PNG

Stroustrup paper selected by Computing Reviews Best of 2012

"Software Development for Infrastructure" by Dr. Bjarne Stroustrup was selected as a notable paper in computing in 2012 by ACM's Computing Reviews Best of 2012. The Best of 2012 list consists of book and article nominations from CR's reviewers and category editors, the editors in chief of journals covered by CR, and others in the computing community. The paper was a cover feature article published in the IEEE Computer Society's January 2012 issue.

The basic premise of the paper is that "Infrastructure software needs more stringent correctness, reliability, efficiency, and maintainability requirements than non-essential applications. This implies greater emphasis on up-front design, static structure enforced by a type system, compact data structures, simplified code structure, and improved tool support. Education for infrastructure and application developers should differ to reflect that emphasis."

Dr. Stroustrup concludes that "In research, we need a greater appreciation of incremental (engineering) improvements with a relevance to real-world systems. 'That's just engineering, and we're computer scientists' is an attitude we can't afford. I suspect the era of transformative breakthroughs is over. We need to achieve a factor-of-two-or-three improvement in several areas, rather than trying to solve our problems with a single elusive two-orders-of-magnitude improvement from a silver bullet."

GotW #6a Solution: Const-Correctness, Part 1 -- Herb Sutter

The solution to GotW #6a is now available:

GotW #6a Solution: Const-Correctness, Part 1 (updated for C ++11/14)

by Herb Sutter

From the article:

Starting with C++11, const on a variable that is possibly shared means read-only, safe to read concurrently without external synchronization.

If you perform any operation on a const shared variable x, or call a const member function on x, you can assume that operation does not change the observable value of x -- or even modify the bits of x in an observable way even in the presence of concurrency. ...

Guideline: Remember the “M&M rule”: For a member variable, mutable and mutex (or atomic) go together. ...

Quick Q: Why pass by value then move? -- StackOverflow

Quick A: Because it's a new C++11 parameter passing pattern, also recently mentioned as part of GotW #4.

Why do we copy then move?

I saw code somewhere in which someone decided to copy an object and subsequently move it to a data member of a class. This left me in confusion in that I thought the whole point of moving was to avoid copying. Here is the example:

 

struct S
{
    S(std::string str) : data(std::move(str))
    {}
};

Here are my questions:

  • Why aren't we taking an rvalue-reference to str?
  • Won't a copy be expensive, especially given something like std::string?
  • What would be the reason for the author to decide to make a copy then a move?
  • When should I do this myself?