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

By Blog Staff | May 29, 2013 09:32 AM | Tags: intermediate basics

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

 

Quick Q: Why use the array form of unique_ptr? -- StackOverflow

By Blog Staff | May 28, 2013 03:06 AM | Tags: intermediate

Enquiring minds want to know: Why use unique_ptr<T[]> vs. vector<T> vs. array<T>?

Is there any use for unique_ptr with array?

std::unique_ptr has support for arrays, for instance:

 

std::unique_ptr<int[]> p(new int[10]);

but is it needed? probably it is more convenient to use std::vector or std::array.

Do you find any use for that construct?

An interesting parallel: Pixar and C++ philosophy

By Blog Staff | May 27, 2013 02:32 PM | Tags: None

As a considerable portion of the C++ world's writership and readership is taking holiday, a less technical thought:

Isn't there an interesting parallel between these two quotes taken from interviews with industry luminaries?

From an interview with Ed Catmull (President of Pixar):

The notion that you’re trying to control the process and prevent error screws things up. We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I think there is a corollary: if everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and over-plan things.

From an interview with Bjarne Stroustrup (creator of C++):

I do not consider it the job of a programming language to be “secure.” Security is a systems property and a language that is -- among other things -- a systems programming language cannot provide that by itself. C++ offers protection against errors, rather than protection against deliberate violation of rules. C++11 is better at that than C++98, but the repeated failures of languages that did promise security (e.g. Java), demonstrates that C++’s more modest promises are reasonable. Unfortunately, “we” have built an infrastructure with weak interfaces, poor hardware protection, and a maze of complex communication protocols that seriously complicates security, but that’s not for any individual language or even for all programming languages to solve. Trying to address security problems by having every programmer in every language insert the right run-time checks in the code is expensive and doomed to failure.

Hat tip to Daring Fireball.

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

By Blog Staff | May 24, 2013 05:48 PM | Tags: None

From the TAMU CS blog:

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

By Blog Staff | May 24, 2013 03:48 PM | Tags: None

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

By Blog Staff | May 23, 2013 03:17 PM | Tags: None

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?

Lambdas vs. Closures -- Scott Meyers

By Blog Staff | May 22, 2013 08:34 PM | Tags: basics

This bears repeating:

Lambdas vs. Closures

by Scott Meyers

From the article:

In recent days, I've twice found myself explaining the difference between lambdas and closures in C++11, so I figured it was time to write it up. ...

GotW #5 Solution: Overriding Virtual Functions -- Herb Sutter

By Blog Staff | May 22, 2013 05:29 PM | Tags: None

The solution to GotW #5 is now available:

GotW #5 Solution: Overriding Virtual Functions (updated for C ++11/14)

by Herb Sutter

From the article:

Exactly one of the following can be true for a polymorphic type:

• Either destruction via a pointer to base is allowed, in which case the function has to be public and had better be virtual;
• or else it isn’t, in which case the function has to be protected (private is not allowed because the derived destructor must be able to invoke the base destructor) and would naturally also be nonvirtual (when the derived destructor invokes the base destructor, it does so nonvirtually whether declared virtual or not).

C++Now 2013 Trip Report -- Jens Weller

By Blog Staff | May 20, 2013 01:54 PM | Tags: None

Reporting from the just-concluded C++Now 2013 event:

C++ Now 2013 -- Trip Report

by Jens Weller

From the article:

This years sessions focused a lot on threading, which brought great talks about atomics, transactional memory or C++11 threading to the conference. I have to admit, that threading is not my main interest in C++, so not all of those talks were meant for me. But having three tracks always gives you a great choice. And also gave me the confidence that the decision to go for 3 tracks at this years Meeting C++ conference was right.

GotW #4 Solution: Class Mechanics -- Herb Sutter

By Blog Staff | May 20, 2013 12:45 PM | Tags: intermediate basics

The solution to GotW #4 is now available:

GotW #4 Solution: Class Mechanics (updated for C++11/14)

by Herb Sutter

From the article:

... To see why, consider the following canonical forms for how operator+= and operator+ should normally be implemented for some type T.

T& T::operator+=( const T& other ) {
    //...
    return *this;
}

 

T operator+( T a, const T& b ) {
    a += b;
    return a;
}

Did you notice that one parameter is passed by value, and one by reference? That’s because if you’re going to copy from a parameter anyway, it’s often better to pass it by value, which will naturally enable a move operation if the caller passes a temporary object such as in expressions like (val1 * val2) + val3. We’ll see more on parameter passing in a future GotW. ...

.