Why would the implicitly generated constructor (et al.) be more efficient than a user-defined (trivial) one?

I read this article from D. Kalev this morning about the new c++11 feature "defaulted and deleted functions", and can't understand the part about performance, namely:

the manual definition of a special member function (even if it's trivial) is usually less efficient than an implicitly-defined one.

By googling to find an answer, I found another article of the same author:

the synthesized constructor and copy constructor enable the implementation to create code that's more efficient than user-written code, because it can apply optimizations that aren't always possible otherwise.

There is no explication, but I read time to time similar claims.

But how is it that writing:

class C { C() = default; };

can be more efficient than

class C { C(){} };

? I though a compiler would be smart enough to detect such situation and optimize that. In other words how is it easier for the compiler to optimize when it sees =default instead of {} (void body function)?

Edit: the question was edited to add 开发者_如何学运维the "c++11" tag, but this question remains in c++03 context: just replace class C {C()=default;}; by class C {};, so not really a c++11 specific question.

You ask, how is it that

class C { C() = default; };

can be more efficient than

class C { C(){} };

Well, both constructors do nothing, so it's meaningless to talk about efficiency for that example.

But more generally, in e.g. a copy constructor one can imagine that copying one POD item at a time will not be recognized as optimizable by simple optimizer, whereas with automatic generation it might just do a memcpy. Who knows. It's a Quality of Implementation issue, and I can easily imagine also the opposite.

So, measure, if it matters.

Cheers & hth.,

It makes no sense whatsoever to talk about "manual definition of a special member function (even if it's trivial)", because user-provided special member functions are, by definition, non-trivial. This non-triviality comes into play when using type traits, and also POD-ness, and many optimizations are only possible with trivial or POD types.

A better restatement of the same quote would be:

The defaulted special member functions enable libraries to detect that calls to these functions may be omitted entirely.

From section 12.1 [class.ctor]

A default constructor is trivial if it is neither user-provided nor deleted and if:

• its class has no virtual functions (10.3) and no virtual base classes (10.1), and
• no non-static data member of its class has a brace-or-equal-initializer, and
• all the direct base classes of its class have trivial default constructors, and
• for all the non-static data members of its class that are of class type (or array thereof), each such class has a trivial default constructor.

Otherwise, the default constructor is non-trivial.

From section 12.8 [class.copy]:

A copy/move constructor for class X is trivial if it is neither user-provided nor deleted and if

• class X has no virtual functions (10.3) and no virtual base classes (10.1), and
• the constructor selected to copy/move each direct base class subobject is trivial, and
• for each non-static data member of X that is of class type (or array thereof), the constructor selected to copy/move that member is trivial;

otherwise the copy/move constructor is non-trivial.

From section 9, [class]:

A trivially copyable class is a class that:

• has no non-trivial copy constructors (12.8),
• has no non-trivial move constructors (12.8),
• has no non-trivial copy assignment operators (13.5.3, 12.8),
• has no non-trivial move assignment operators (13.5.3, 12.8), and
• has a trivial destructor (12.4).

A trivial class is a class that has a trivial default constructor (12.1) and is trivially copyable. [ Note: in particular, a trivially copyable or trivial class does not have virtual functions or virtual base classes. — end note ]

Take performance claims "with a grain of salt".

I've heard a high-rated MIT professor make a claim like that for his favorite thing, and the only reason nobody asked him "why" was because he was a high-rated MIT professor.

Such constructors and destructors might have other advantages, but claims about performance (outside of big-O) are seldom even meaningful except in highly contrived circumstances.

To be honest, I can't see it either.

Among other things, I can see why one should use

class C { C() = default; };

that seems to me the same as

class C { };

Or, if other constructors are provided, as:

class C { 
    C() {}
    // other constructors.
};

I fail to see the real problem the author is writing about here.