basics

Quick Q:Is there a way to mark a parent's virtual function final from a child class?

Quick A: No.

Recently on SO:

Is there a way to mark a parent's virtual function final from a child class without reimplementing it

No, you can't do it without reimplementing it. So just reimplement it:

struct Child : public Parent
{
    virtual void fn() override final { Parent::fn(); }
};

N.B. saying virtual ... override final is entirely redundant, final is an error on a non-virtual function, so you should just say:

    void fn() final { Parent::fn(); }

See http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override

Quick Q: shrink_to_fit() vs swap trick

Quick A: Are equivalent, but shrink_to_fit mark the intention.

Recently on SO:

shrink_to_fit() vs swap trick

The swap trick isn't actually constant-time. The cost of performing the actual swap is indeed O(1), but then there's the cost of the std::vector destructor firing and cleaning up all the allocated space. That can potentially have cost Ω(n) if the underlying objects have nontrivial destructors, since the std::vector needs to go and invoke those destructors. There's also the cost of invoking the copy constructors for all the elements stored in the initial vector, which is similarly Ω(n).

As a result, both approaches should have roughly the same complexity, except that shrink_to_fit more clearly telegraphs the intention and is probably more amenable to compiler optimizations.

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