Quick Q: Doesn't { } initialization guarantee no narrowing conversions? -- StackOverflow

By Blog Staff | Jun 5, 2013 08:05 AM | Tags: None

Quick A: Yes, but some compilers have conforming extensions that give meaning to nonportable programs.

Preventing narrowing conversion when using std::initializer_list

#include <iostream>

struct X {
    X(std::initializer_list<int> list) { std::cout << "list" << std::endl; }
    X(float f) { std::cout << "float" << std::endl; }
};

int main() {
    int x { 1.0f };
    X a(1);     // float (implicit conversion)
    X b{1};     // list
    X c(1.0f);  // float
    X d{1.0f};  // list (narrowing conversion) ARG!!!

    // warning: narrowing conversion of '1.0e+0f' from 'float' to 'int'
    // inside { } [-Wnarrowing]
}

Is there any other way of removing std::initializer_list from an overload list (i.e., making the non-list ctors more favorable) instead of using the ()-initialization, or at least prohibiting narrowing conversion to happen (apart from turning warning into error)?

I was using http://coliru.stacked-crooked.com/ compiler which uses GCC 4.8.

Trailing Return Types -- sumi_cj

By Blog Staff | Jun 4, 2013 11:08 AM | Tags: None

From the IBM C/C++ Cafe:

Introduction to the C++11 feature: trailing return types

by sumi_cj

From the article:

To solve this problem, C++11 introduced a feature called trailing return types. Using this feature, the previous program can be rewritten as follows:

template<class T>
auto mul(T a, T b) -> decltype(a*b){
    return a*b;
}

Quick Q: When should I use {} vs. () to initialize variables? -- StackOverflow

By Blog Staff | Jun 3, 2013 03:37 PM | Tags: basics

Quick A: In C++11, prefer to initialize using {} where possible, which is nearly always.

Uniform initialization syntax difference

What's the difference between doing

A a{ A() };

and,

 

A a( A{} );

to avoid the Most Vexing Parse? When should I use a particular one?

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.

Copying Container Elements From The C++ Library: It's Trickier Than It Looks -- Andrew Koenig

By Blog Staff | May 31, 2013 02:41 PM | Tags: None

New on DDJ:

Copying Container Elements From The C++ Library: It's Trickier Than It Looks

by Andrew Koenig

From the article:

Now consider this call:

 

v.push_back(v[0]);

GotW #89 Solution: Smart Pointers -- Herb Sutter

By Blog Staff | May 30, 2013 02:36 PM | Tags: intermediate basics

The solution to GotW #89 is now available:

GotW #89 Solution: Smart Pointers (updated for C ++11/14)

by Herb Sutter

From the article:

So, why use make_shared (or, if you need a custom allocator, allocate_shared) whenever you can, which is nearly always? There are two main reasons: simplicity, and efficiency...

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

Defaulted Functions in C++11 -- Fang Lu

By Blog Staff | May 29, 2013 10:22 AM | Tags: basics

New at the IBM DeveloperWorks C/C++ Cafe:

Defaulted functions in C++11

by Fang Lu

From the article:

The defaulted functions feature is newly introduced into the C++11 standard. In this article, I will explain this feature and provide some examples on how to use it.

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