Home » Blog » Tags » basics

basics

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

By Blog Staff | Jun 7, 2013 05:42 PM | Tags: intermediate basics

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

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.

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

 

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

.

GotW #3 Solution: Using the Standard Library (or, Temporaries Revisited) -- Herb Sutter

By Blog Staff | May 16, 2013 01:11 PM | Tags: intermediate basics

The solution to GotW #3 is now available:

GotW #3 Solution: Using the Standard Library (or, Temporaries Revisited) (updated for C++11/14)

by Herb Sutter

From the article:

With no other changes, simply using the standard find algorithm could do everything the range-based for loop did to avoid needless temporaries (and questions about them) [...] and it further increases our level of abstraction.