Empty List Initialization -- Andrzej Krzemieński

By Blog Staff | Jun 7, 2013 05:33 AM | Tags: intermediate

A belated link to Andrzej's recent article:

Empty list initialization

by Andrzej Krzemieński

From the article:

My conclusion from the above story is this piece of advice. When you provide an initializer-list constructor for your class, make sure that you also provide a default constructor with the same semantics as though you were initializing with a zero-size initializer_list.

GotW #91 Solution: Smart Pointer Parameters -- Herb Sutter

By Blog Staff | Jun 5, 2013 05:37 PM | Tags: intermediate

The solution to the latest GotW problem is now available:

GotW #91 Solution: Smart Pointer Parameters (updated for C++11/14)

by Herb Sutter

From the article:

 

Guideline: Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership.

Guideline: Prefer passing objects by value, *, or &, not by smart pointer.

If you’re saying, “hey, aren’t raw pointers evil?”, that’s excellent, because we’ll address that next...

Intuitive Interface, Part 1 -- Andrzej Krzemieński

By Blog Staff | Jun 5, 2013 02:45 PM | Tags: intermediate

Good advice from the designer of the new std::optional<T> on how to design modern C++ classes to follow GotW #1's advice to avoid writing initializer_list constructors that force callers to resort to () instead of {} to disambiguate.

Intuitive Interface -- Part I

by Andrzej Krzemieński

From the article:

Let’s start with the popular C++(11) “uniform initialization” gotcha. Changing braces to parentheses in object initialization may change the semantics of the initialization:

 

std::vector<int> v1{5, 6}; // 2 elems: {5, 6}
std::vector<int> v2(5, 6); // 5 elems: {6, 6, 6, 6, 6}

For instance, it is described in Problem 1 of the newly revisited “Guru of The Week” series by Herb Sutter.

When seeing such an example, one might conclude that the new rules for object initialization are very confusing or error-prone. But to me it looks like the problem here lies in how class template std::vector has been defined in C++03...

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