basics

Quick Q: Syntax of final, override, const with trailing return types

Quick A: The signature of the function is first.

Recently on SO:

Syntax of final, override, const with trailing return types

The correct syntax should be:

  • override and final should appear after the member function declaration, which including the trailing return type specification, i.e.
auto debug(ostream& os=cout) const ->ostream& override final;
  • override and final should not be used with the member function definition outside the class definition, so just remove them:
auto Derived::debug(ostream& os) const ->ostream&
{
  os << "dval: " << dval << endl;
  return os;
}

Quick Q: Are the experimental features of modern C++ reliable for long-term projects?

Quick A: No

Recently on SO:

Are the experimental features of modern C++ reliable for long-term projects?

Is it guaranteed that all compliant compilers have the same experimental features?
No, experimental features are optional.
Are experimental features prone to big changes that make them unreliable?
Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.

Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).

C++ Braced Initialization--Edouard of quasardb

Do you use it?

C++ Braced Initialization

by Edouard of quasardb

From the article:

Since C++ 11 it's possible to use braces for construction and initialization. Although this is something you could ignore for the code you write, it's obviously important to know for the code you may read.

If you have a couple of years of experience in C++, the temptation can be great to keep your old habits because "All these new features are useless! The language is bloated! Those people in the committee!".

Let's make sense out of the bloat...

Reflections on the reflection proposals

Since the overview on the current papers for Kona, I wanted to know more about reflection...

Reflections on the reflection proposals

by Jens Weller

From the article

A few weeks ago I wrote a short overview over the most interesting papers for the current C++ Committee meeting in Kona, Hawaii. The big surprise was that there were many papers on reflection, while there already is a very detailed proposal for reflection.

With the C++ committee currently in Kona discussing lots of proposals, there will be some changes to the on going effort for reflection, but the current proposals are detailed enough to give an overview.

Using QtCreator together with the Visual Studio Build Tools

A first posting about working with Qt and Visual C++ in QtCreator

Using QtCreator together with the Visual Studio Build Tools

by Jens Weller

From the article:

For a while I've been using QtCreator as my IDE, mostly because its deep integration with Qt, as most of my projects are Qt related. With this, I also preferred (and still do a little) to use the MinGW builds of Qt on Windows. In the past, as GCC was a little bit better with the newer standards, today, well, never change a running system...

Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types -- Marc Mutz

Marc Mutz wrote in his recent article about the properties of default constructed object as required by Elements of Programming.

Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types

by Marc Mutz

From the article:

In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State.

Using these, I shall try to derive rules for C++ implementations of what are commonly called “value types”, focusing on the bare essentials, as I feel they have not been addressed in sufficient depth up to now: Special Member Functions.