Home » Blog » Categories »

Quick Q: Should I return a const value? -- StackOverflow

By Blog Staff | Jun 3, 2013 12:47 PM | Tags: intermediate

Quick A: No.

Some authors wrote "Consider doing this" in C++98. The answer is now a definite "No" because it prevents move from returned values.

Isn't the const modifier here unnecessary?

The "Effective C++" Item 3 says "Use const whenever possible", and it gives an example like:

 

const Rational operator*(const Rational& lhs,
                            const Rational& rhs);

to prevent clients from being able to commit atrocities like this:

Rational a, b, c;
...
(a * b) = c;   // invoke operator= on the result of a*b!

But isn't the non-reference return value of functions allready a rvalue? So why bother doing this?

GotW #90 Solution: Factories -- Herb Sutter

By Blog Staff | May 31, 2013 02:50 PM | Tags: intermediate basics

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.

GCC 4.8.1 released, C++11 feature complete

By seth | May 31, 2013 11:09 AM | Tags: None

The release of GCC 4.8.1 was announced today (31 May 2013) on the gcc mailing list. In addition to many bug fixes, GCC 4.8.1 adds support for C++11 ref-qualifiers, the final missing C++11 feature. This makes GCC the first C++11 [Ed.: language specification] feature complete compiler to be released.

Information on the full set of changes is available on the GCC 4.8 series page. 

Clang 3.3, also C++11 feature complete, is in release testing and the release is currently scheduled for June 5th. Within a week full C++11 support will be available from two major compilers and on numerous platforms supported by those compilers.

Forging ahead with support for the next C++ standard.

C++ auto and decltype Explained -- Thomas Becker

By Blog Staff | May 29, 2013 03:59 PM | Tags: None

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

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

 

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.