basics

Quick Q: Why are override and final identifiers with special meaning instead of reserved keywords?

Quick A: To avoid breaking old code, thanks to context-sensitive keywords.

Recently on SO:

Why are override and final identifiers with special meaning instead of reserved keywords?

Both the override specifier and final specifier were added in C++11. They differ from other specifiers added to C++11 such as constexpr and decltype, in that they are not keywords and so are available for use as identifiers:

int main()
{
  int override = 0 ;    // Ok
  int final = 0 ;       // Ok
  //int constexpr = 0 ; // Error
}

They are referred to as identifiers with special meaning, which is covered in the draft C++11 standard section 2.11 [lex.name] (emphasis mine):

The identifiers in Table 3 have a special meaning when appearing in a certain context. When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production. any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.
and Table 3 -- Identifiers with special meaning lists both override and final.

Why did these two specifiers end up being identifiers with special meaning instead of keywords?

Modern C++ Workshop at Polyglot Unconference 2015

This workshop is an introduction to new features and best practices of modern C++. We will delve into the core of C++ and all new features introduced in C++11 and C++14.

Introduction to Modern C++ Workshop happening at Polyglot Unconference 2015 in Vancouver, BC.

by Alejandro Isaza

From the workshop summary:

  • Write C++ code using the latest language features while following the best practices
  • Use third-party libraries and frameworks

 

 

Binary literals and digit separators—Marius Bancila

The title says it all:

Binary literals and digit separators

by Marius Bancila

From the article:

The C++14 standard provides two new small features to the language: binary literals and digit separators. They are already available in Clang 3.4 and GCC 4.9 and now Visual Studio 2015 RC has implemented them. They may not be something you can’t leave without, but sometimes it’s convenient to have them. Let’s have a look...

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