Articles & Books

Quick Q: How is “=default” different from “{}” for default constructor and destructor?

Quick A: The "= default" keeps the type trivial.

Recently on SO:

How is “=default” different from “{}” for default constructor and destructor?

I originally posted this as a question only about destructors, but now I'm adding consideration of the default constructor. Here's the original question:

If I want to give my class a destructor that is virtual, but is otherwise the same as what the compiler would generate, I can use =default:

class Widget {
public:
   virtual ~Widget() = default;
};

But it seems that I can get the same effect with less typing using an empty definition:

class Widget {
public:
   virtual ~Widget() {}
};

Is there any way in which these two definitions behave differently?

Based on the replies posted for this question, the situation for the default constructor seems similar. Given that there is almost no difference in meaning between "=default" and "{}" for destructors, is there similarly almost no difference in meaning between these options for default constructors? That is, assuming I want to create a type where the objects of that type will be both created and destroyed, why would I want to say

Widget() = default;

instead of

Widget() {}

?

I apologize if extending this question after its original posting is violating some SO rules. Posting an almost-identical question for default constructors struck me as the less desirable option.

Boost.Spirit + Flatbuffers + Catch + Biicode + CLion + Github--Max Galkin

Come see a nice product review:

Boost.Spirit + Flatbuffers + Catch + Biicode + CLion + Github

by Max Galkin

From the article:

This weekend I’m test-driving several new technologies. OK, OK, maybe not so new for everyone else, but new for me. I’m trying to write a parser for the Flatbuffers IDL grammar using Boost.Spirit, I’m referencing Boost using Biicode, I’m testing the code using Catch, I’m editing the project in CLion, and I’m pushing the results to Github yacoder/flatbuffers-with-spirit!

C++ User Group Meetings in April

The monthly overview on upcoming user group meetings at Meeting C++:

C++ User Group Meetings in April 2015

by Jens Weller

From the article:

The List:

    9.4 C++ UG Dublin - C/C++ two great talks\, quiz with prizes\, pizza\, ...
    9.4 C++ UG Amsterdam - New data structures in C++11 and Boost
    9.4 C++ UG Dresden - Go all binary!
    11.4 C++ UG Pune, India - More C++ Concurrency
    13.4 C++ UG Denver - Denver Tech Center C++ Developers
    14.4 C++ UG Luzern - C++ Pub Quiz
    15.4 C++ UG Düsseldorf - Encryption & C++
    15.4 C++ UG Hamburg - Operators
    15.4 C++ UG Northwest/Seattle - Pushing the boundaries of C++ Codegeneration
    16.4 C++ UG Rhein-Neckar - Modern C++ Allocators (C++03 to C++17)
    16.4 C++ UG Ruhrgebiet - April fools!
    20.4 C++ UG Austin - North Austin Monthly C/C++ Pub Social
    21.4 C++ UG Berlin - Rationales behind C++ atomics
    22.4 C++ UG San Francisco/ Bay area - Workshop and Discussion Group
    23.4 C++ UG Munich - TBA
    23.4 C++ UG New York - Introduction to C++ Casting
    28.4 C++ UG Chicago - Modern Template Metaprogramming
    29.4 C++ UG London - monthly meetup
    29.4 C++ UG Bremen - C++11/14/1x und Biicode

Overload 126 is now available

ACCU's Overload journal of April 2015 is out. It contains C++ related articles.

Overload 126

From the journal:

Alternatives to Singletons and Global Variables: Global variables and Singletons are usually considered bad. Bob Schmidt summarises some alternatives. by Bob Schmidt

Resource Management with Explicit Template Specializations: RAII is a useful idiom. Pavel Frolov presents a powerful extension using explicit template specialization. by Pavel Frolov

Variadic and Variable Templates: C++11 and 14 offer new features for Variadic and Variable templates. Peter Sommerlad showcases the compile-time possibilities they offer. by Peter Sommerlad

iterator_pair – A Simple and Useful Iterator Adapter: Can you form a new contain from two others? Vladimir Grigoriev reminds us how to write an iterator. by Vladimir Grigoriev

Benchmarking in C++

A writeup of one approach to implement helpers for...

... Benchmarking in C++

by Nick Athanasiou

From the article:

We’ll be creating a framework that attempts to provide a generic, cross platform (standard compliant), non dependent to third party libraries solution to the benchmarking problem and explore the facilities C++ has to offer on the topic. 

The end product will have the following use pattern :

benchmark<time_type, clock_type> bm;

bm. run(
    "Experiment Name"
    , sampleSize
    , { /* code to time */ }
    , "factor name"
    , factors. begin(), factors. end() );

bm. serialize(
    "benchmark name" , "output file name" , mode);

 

Eggs.Variant - Part II (the constexpr experience)--K-ballo

A link to make type-safe unions:

Eggs.Variant - Part II (the constexpr experience)

by K-ballo

From the article:

Ruminations on the development of Eggs.Variant, a C++11/14 generic, type-safe, discriminated union. Part I explored a straightforward implementation based on untyped raw storage appropriate to hold any of the variant members. It was noted, however, that such an implementation would never be constexpr-aware. It's time to throw it away and start from scratch in order to properly support constexpr...

Bug of the week--Andrzej Krzemieński

Here is an interesting bug:

Bug of the week

by Andrzej Krzemieński

From the article:

Today we are going to see a case study illustrating a bug. Not a very spectacular one: a typical bug one would encounter in everyday work. We will start with the symptoms, identify the root cause, and suggest measures to prevent similar things from happening in the future...

Simple and Clean Code vs. Performance -- Arne Mertz

This article talks about why simple code is more important.

Simple and Clean Code vs. Performance

by Arne Mertz

From the article:

One of C++s strengths is that it is possible to write very performant code. But does that mean we always have to worry about performance and write our everyday code as performant as possible? Should we give up simplicity for performance? Do we have to?