basics

Tippet: Use reference_wrapper to create views of data—Indi

Explicit C++ describes how to use std::reference_wrapper to create alternative views of data.

Tippet: Use reference_wrapper to create views of data

by Indi

from the article:

When working with objects indirectly, always use references. Only use pointers to indicate optional referencing. But there’s one little hitch: because you can’t rebind references, you can’t simply have a container of references. Enter std::reference_wrapper.

The C++ highlights and more of GCC 5.1

The release of GCC 5.1 is a highlight, here is an overview on the most important new things:

The C++ highlights of GCC 5.1 and more

by Jens Weller

From the article:

Just recently, GCC 5.0 has been released as GCC5.1, the not only the newest version of GCC, but also bumping up the version number from 4 to 5. This release is a major milestone for GCC, but also for C++, as it brings full C++14 support, but yet not C++11(std=c++11) as the new default...

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.

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

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

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

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

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.