Home » Blog » Tags » intermediate

intermediate

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

 

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.

GotW #2 Solution: Temporary Objects -- Herb Sutter

By Blog Staff | May 13, 2013 05:27 AM | Tags: intermediate basics

The solution to GotW #2 is now available:

GotW #2 Solution: Temporary Objects (updated for C++11/14)

by Herb Sutter

From the article:

Because C++ naturally enables move semantics for returned values like this string object, there’s usually little to be gained by trying to avoid the temporary when you return by value. ... For example, if the caller writes auto address = find_addr( mylist, “Marvin the Robot” );, there will be at most a cheap move (not a deep copy) of the returned temporary into address, and compilers are allowed to optimize away even that cheap move and construct the result into address directly.

But what if you did feel tempted to try to avoid a temporary in all return cases by returning a string& instead of string? Here’s one way you might try doing it that avoids the pitfall of returning a dangling reference to a local or temporary object: [...] To demonstrate why this is brittle, here’s an extra question:

For the above function, write the documentation for how long the returned reference is valid.

Go ahead, we’ll wait. ...

The questions for #3 are posted for discussion:

GotW #3: Using the Standard Library (or, Temporaries Revisited)

 

 

Some Subtleties of Aliasing -- Andrew Koenig

By Blog Staff | May 12, 2013 04:59 PM | Tags: intermediate

Why "aliasing can cause paradoxical behavior"...

Some Subtleties of Aliasing

by Andrew Koenig

 

... As an example of a problem with this code, I suggested that it might be called by writing

 

scale(v, v[n]);

with the aim of dividing every element of v by v[n], but that this call would actually do something else entirely. From the comments on the article, I think that some readers were unclear about what that something else might be. To understand this call's behavior in detail, we have to look at the code more closely. ...

Quick Q: What's the difference between vector<T...> and vector<T>...? -- StackOverflow

By Blog Staff | May 8, 2013 09:22 AM | Tags: intermediate

SO's version of the question added one layer of wrapping:

What's the difference between doing vector<vector<T...>> and vector<vector<T>...>

I saw code like this earlier:

 

using A = std::vector<std::vector<T>...>

where T is a variadic list of template arguments. I wanted to know what the difference is between putting the parameter pack at the end of the last angle bracket and the first. For example:

using B = std::vector<std::vector<T...>>;

Both of these two compile fine but I don't know what the difference is.

Can someone explain? Thanks.