Empty destructor vs literal destructor

Question

Consider the following code:

#include <iostream>

class Test
{
    public:
        constexpr Test(const int x) : _x(x) {}
        constexpr int get() const {return _x;}
        ~Test() {} // HERE
    protected:
        const int _x;
};

int main()
{
    static constexpr Test test(5);
    return 0;
}

If I remove the line HERE the code compiles well, but if I define an empty destructor, it results to a compilation error saying that Test is non-literal.

Why and what is the difference between an empty destructor and no destructor at all ?

EDIT: Another related question : if empty and literal destructors are different how to define a protected literal destructor ?

You can't have a non-trivial destructor in a constexpr object. — chris, Jan 10 '13 at 10:23
Difference: **12.4 Destructors [class.dtor]** *3) [...] A destructor is trivial if it is implicitly-declared and if: [...]* — Luchian Grigore, Jan 10 '13 at 10:32
@Vincent In that case why not make the *constructor* `protected` instead of the destructor? — Konrad Rudolph, Jan 10 '13 at 10:38
@KonradRudolph : I have asked the question here : http://stackoverflow.com/q/14256208/882932 — Vincent, Jan 10 '13 at 10:53
@KonradRudolph If some class is intended to be a base class for other ones, its destructor should be either virtual or protected to prevent UB when derived object is deleted via base pointer. — Tadeusz Kopec for Ukraine, Jan 10 '13 at 11:56
@TadeuszKopec Just that you don't have to mess with virtual destructors when you're not going to polymorphically destroy objects at all. — Christian Rau, Jan 10 '13 at 12:08
@Tadeusz If the class isn’t polymorphic then how in hell did you get a pointer/reference to it via its base? That is a bug, you mustn’t use CRTP like that. — Konrad Rudolph, Jan 10 '13 at 12:44
@Tadeusz I think there is no point in protecting against something that won't happen accidentally. — R. Martinho Fernandes, Jan 10 '13 at 12:54

ForEveR · Accepted Answer · 2013-01-10T10:45:18.523

20

Quotes from n3376

7.1.5/9

A constexpr specifier used in an object declaration declares the object as const. Such an object shall have literal type and shall be initialized. If it is initialized by a constructor call, that call shall be a constant expression

3.9/10

A type is a literal type if:

it has a trivial destructor...

12.4/5

A destructor is trivial if it is not user-provided and if:

— the destructor is not virtual,

— all of the direct base classes of its class have trivial destructors, and

— for all of the non-static data members of its class that are of class type (or array thereof), each such class has a trivial destructor.

Otherwise, the destructor is non-trivial.

clang diagnostic is really more informative:

error: constexpr variable cannot have non-literal type 'const C'

'C' is not literal because it has a user-provided destructor

edited Jan 10 '13 at 10:45

answered Jan 10 '13 at 10:39

ForEveR

55,233
2
119
133

2

Clang: 1254, Everyone Else: 32 – chris Jan 10 '13 at 10:47
1

@chris: Sorry for my unknowledge, but what does your comment mean? – user1284631 Jan 10 '13 at 13:16
@axeoth, It was a play on how good Clang is with its errors being readable and/or helpful compared to other compilers. – chris Jan 10 '13 at 16:16

score 0 · Answer 2 · answered Sep 06 '13 at 22:28

No destructor causes the compiler to add a trivial destructor, which is ill defined in the spec, but basically does nothing.

If you specify a destructor, it does not add the trivial destructor. Your destructor is non-trivial.

In your case, Test::~Test() { } looks pretty darn trivial, but that is a human interpretation of what you see. To go further, what about:

Test::~Test()
{
    int a = 5;
}

We can see that an optimizer can optimize out a, so it is obviously doing nothing. How about:

Test::~Test()
{
    for (int i = 0; i < 1000; i += 2) {
        if ((i % 2) == 1)
            doSomeSideEffect(); // like throwing or setting a global
    }
}

We can see that i can never be odd, so that destructor does nothing.

The spec has to define what is allowed to be a constexpr and what cannot. Rather than going down this rabbit hole of defining "doing nothing," they simply declare that the only do-nothing destructor that is good enough for constexpr is the compiler provided trivial destructor.

Empty destructor vs literal destructor

2 Answers2