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

By Adrien Hamelin | Apr 13, 2015 09:58 AM | Tags: c++11 basics

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.

C++ User Group Meetings in April

By Meeting C++ | Apr 8, 2015 06:14 AM | Tags: community basics

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

Did you know? - Type aliasing

By Adrien Hamelin | Apr 1, 2015 08:35 AM | Tags: c++11 basics

Did you know?

C++ allows to do this:

include <vector>
using vector = std::vector;

Check it out.

Bug of the week--Andrzej Krzemieński

By Adrien Hamelin | Mar 31, 2015 02:41 PM | Tags: boost basics

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

CppCon 2014 An Overview of C++11/14, Part II--Leor Zolman

By Adrien Hamelin | Mar 30, 2015 08:00 AM | Tags: c++14 basics

While we wait for CppCon 2015 in September, we’re featuring videos of some of the 100+ talks from CppCon 2014. Here is today’s feature:

An Overview of C++11/14, Part II

by Leor Zolman

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

This accelerated introduction to C++11/14 surveys most of the key additions to the C++ language, including support for increased code clarity (lambdas, uniform initialization, auto, new OOD control) and improved performance (rvalue references, move semantics and perfect forwarding.)

The presentation is designed for those who truly need a quick overview of the new C++, so the focus is on breadth rather than depth. Whenever feasible, new language features are presented in a style showcasing how they improve over their "Old C++" counterparts.

C++ Tail Recursion Using 64-bit variables -- Giovanni Campo

By Jeremy Wright | Mar 16, 2015 06:53 AM | Tags: basics assembly

Leveraging the elegance of recursion:

C++ Tail Recursion Using 64-bit variables

by Giovanni Campo

From the article:

Main disadvantage of Recursion in imperative languages is the fact that not always is possible to have tail calls, which means an allocation of the function address (and relative variables, like structs for instance) onto the stack at each call. For deep recursive function this can cause a stack-overflow exception because of a limit to the maximum size of the stack, which is typically less than the size of RAM by quite a few orders of magnitude.

Refactoring my Qt database code

By Meeting C++ | Mar 15, 2015 06:04 AM | Tags: qt intermediate c++11 basics

I spend some time on refactoring my database code in Qt:

Refactoring my Qt database code

by Jens Weller

From the article:

For two days I had the chance to clean up my code and do a little refactoring. One of the results is, that my database code now also uses variadic templates. For some time now, I use Qt as the UI and Database frontend of my applications...

Threads are an illusion - asynchronous programming with boost::asio

By Meeting C++ | Mar 13, 2015 03:17 AM | Tags: performance intermediate efficiency c++11 boost basics

This talk was recorded during the LWG Meeting in Cologne:

Threads are an illusion - asynchronous programming with boost::asio

by Chris Kohlhoff

Quick Q: Return a local object rvalue reference, right or wrong?

By Adrien Hamelin | Mar 11, 2015 01:54 PM | Tags: c++11 basics

Quick A: Wrong!

Recently on SO:

Return a local object rvalue reference,right or wrong?

I see once return a local object,the compiler will take the return value optimization.(RVO,NRVO).

The part of the Standard blessing the RVO goes on to say that if the conditions for the RVO are met, but compilers choose not to perform copy elision, the object being returned must be treated as an rvalue.

So we just write code like this:

Widget makeWidget()
{
Widget w;
…
return w;//never use std::move(w);
}

I never see somebody write code like this:

Widget&& makeWidget()
{
Widget w;
…
return std::move(w);
}

I know that returns an lvalue reference of local object is always wrong. So, returns an rvalue reference of local object is also wrong?

Secrets of the Conditional (ternary) Operator -- Alex Kulikov

By Blog Staff | Mar 7, 2015 06:06 PM | Tags: basics

Hot off kukuruku:

Secrets of the Conditional (ternary) Operator

by Alex Kulikov

(Note: Translation of the original Russian-language article here.)

From the article:

Every self-respecting C/C++ programmer knows what the ternary operator is, and most everyone used it at least once in their programs. But do you know all the secrets of the ternary operator? What potential dangers are associated with its use and what features, seemingly not related to its direct purpose, it has? This article gives you the opportunity to test your knowledge and maybe learn something new.

Let's start with a small test...