C++0x : virtual destructor and =default
Albert
(please forgive my poor english, i 'll try to be clear enought).
I have been reading over and over, in the n3000 draft, the 8.4 section
item 9 about =default definition and the 12.4 section about
destructors.
However, following code :
#include <iostream>
struct A {
virtual ~A()=default;
};
struct B : public A {
virtual ~B() {
std::cout << "B destructor\n";
}
};
int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
outputs nothing making me think that B destructor is not called.
Whereas, following code :
#include <iostream>
struct A {
virtual ~A();
};
A::~A()=default;
struct B : public A {
virtual ~B() {
std::cout << "B destructor\n";
}
};
int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
works as i expect calling B destructor.
Is that a gcc (4.4.1) failure or is that conform to the new
specification ?
I was expecting virtual ~A()=default; be a correct definition of the
destructor. It seems that I have to separate the declaration
specifying the virtual property from the definition beeing defaulted.
Have i missed something ?
Thanks in advance.
Albert.
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Scott Meyers
> Hi,
> (please forgive my poor english, i 'll try to be clear enought).
Your English is great, so don't worry about it.
> I have been reading over and over, in the n3000 draft, the 8.4 section
> item 9 about =default definition and the 12.4 section about
> destructors.
[snip]
> I was expecting virtual ~A()=default; be a correct definition of the
> destructor. It seems that I have to separate the declaration
> specifying the virtual property from the definition beeing defaulted.
> Have i missed something ?
I read N3000 the same way you do. I think you've found a bug in gcc's
implementation. I suggest you file a bug report.
Scott
Albert
> I read N3000 the same way you do. I think you've found a bug in gcc's
> implementation. I suggest you file a bug report.
>
Thank's for the answer. We reported the bug (42983).
Albert
In C++ Standard Core Language Active Issues, Revision 67, section :
906. Which special member functions can be defaulted?, we found :
"[Note: This implies that parameter types, return type, and cv-
qualifiers must match the hypothetical implicit declaration. —end
note] An explicitly-defaulted function may be declared constexpr only
if it would have been implicitly declared as constexpr. If it is
explicitly defaulted on its first declaration,
* it shall be public,
* it shall not be explicit,
* it shall not be virtual, ****************************
* it is implicitly considered to have the same exception-
specification as if it had been implicitly declared (15.4
[except.spec]), and
* in the case of a copy constructor or copy assignment operator,
it shall have the same parameter type as if it had been implicitly
declared.
"
Does it means that my first believe (virtual ~A()=default; is correct)
is no more valid ?
gcc teams seems to say in the bug report (http://gcc.gnu.org/bugzilla/
show_bug.cgi?id=42983) that the specification has changed according to
this last document. And the virtual ~A()=default; is no more valid ?
According to that, I must separate virtual declaration from default
definition.
So, how do I have to understand this feature ? Work still in
progress ?
By the way, constraint for public access troubles me. And so for the
explicit constraint for constructors. I'm not sure to see the reasons
for those constraints in a default definition.
I understood =default to be a *definition* whose behaviour is same as
the implicit one. But, I don't see why this default *definition* even
in first declaration must exactly mach the *implicit declaration
behaviour*. I am wondering whether implicit declaration and implicit
definition should not be distinguish to be able to clarify default
definition from implicit *definition* and let declaration be what the
code declares.
Hope you understand what i want to say :(
Thanks in advance,
Best regards,
Albert
Daniel Krügler
Your description is quite clear. Notice that the constraints for
defaulting a special member function is still in flux, see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#667
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906
therefore it's hard to foresee the final decision.
HTH & Greetings from Bremen,
Daniel Krügler
Scott Meyers
> Hi (again),
> In C++ Standard Core Language Active Issues, Revision 67, section :
> 906. Which special member functions can be defaulted?, we found :
> Does it means that my first believe (virtual ~A()=default; is correct)
> is no more valid ?
Well, technically, it doesn't mean anything yet, because it has not been adopted
into even a draft standard, but if it gets adopted, then, yes, it means that the
code you wrote (and which I think is reasonable) would not be valid.
> gcc teams seems to say in the bug report (http://gcc.gnu.org/bugzilla/
> show_bug.cgi?id=42983) that the specification has changed according to
> this last document.
More precisely, they say that that is what they have chosen to implement.
> So, how do I have to understand this feature ? Work still in
> progress ?
Like everything else in draft C++0x :-) Some parts are in more of a state of
flux than others.
> I understood =default to be a *definition* whose behaviour is same as
> the implicit one. But, I don't see why this default *definition* even
> in first declaration must exactly mach the *implicit declaration
> behaviour*.
I think my understanding was the same as yours: "=default" tells the compiler
to generate the "normal" function definition for a user-declared special
function. My sense from scanning issue 906 is that this led to trouble with the
definition of "trivial" functions, so 906 severely restricts what can be done
with =default in a class definition. I think these restrictions are
unfortunate, but I haven't thought about the interaction with "triviality"
enough to have a feeling for whether there is a better solution.
Scott
Albert
Thanks for these explanations. I'm not sure to realy understand
consequences on triviality.
At first glance, i tend to consider *=default* as a definition and i
expect to be able to write the definition where i would like. I
thought that a defaulted function is closer to a user-defined one than
to the implicit version. The only thing it shares with the implicit
one is the effective content.
Well, it will be hard to explain that this
struct A {
~A()=default;
};
is valid, whereas
struct A {
virtual ~A()=default;
};
is not, nor :
struct A {
protected:
~A()=default;
};
Moreover, if i have to write :
struct A {
virtual ~A();
};
A::~A()=default;
temptation will be great to do this :
struct A {
virtual ~A(){}
};
emptying one of the interest of the =default definition :(
Thanks again for these intersting answers and I hope an easy to use
and explain solution will be found by the comitee :)
Albert.
Lavock
Sorry for double-post, but suddenly i have a question. What about this
code :
class base{
public:
virtual ~base();
};
base::~base() = default;
class derived : public base {
public:
~derived() = default; //ill-formed or not ?
};
It's pretty strange, because writing nothing is clear,
but write it could be ill-formed... So, =default does NOT generate
like there is no user-declared function.
And if it's correct, it opposite to the core issue 906.
Lavock
> I think these restrictions are
> unfortunate, but I haven't thought about the interaction with "triviality"
> enough to have a feeling for whether there is a better solution.
Hi,
I'm maybe stupid, but why the committee would want to add a feature,
which in some cases, does the same that write nothing ? The only
interest
for user-declared first-line-defaulted (in the way showed by issue
906)
function is for constructors of trivial classes, when you define a non-
trivial
constructor. I don't find any other case where i need to wrote this.
I have maybe forgotten some cases, but i don't think they are many.
Daniel Krügler
> Hi again,
> Sorry for double-post, but suddenly i have a question. What about this
> code :
>
> class base{
> public:
> virtual ~base();};
>
> base::~base() = default;
>
> class derived : public base {
> public:
> ~derived() = default; //ill-formed or not ?
>
> };
>
> It's pretty strange, because writing nothing is clear,
> but write it could be ill-formed... So, =default does NOT generate
> like there is no user-declared function.
> And if it's correct, it opposite to the core issue 906.
You shouldn't consider the current proposal of 906
as a final decision - It is just a snapshot in the
endless universe of human imaginations.
I don't consider above example as strange: Given
a more relaxed interpretation of defaulting special
member functions there is no need to introduce a
dependency to triviality here. The above code could
just be well-formed with nontrivial destructors in
both derived and base.
The meaning of the declaration would just be, as if the
compiler would have generated them. Since compilers
do generate destructors even for nontrivial classes
(fortunately...), there should be no reason to worry.
You are arguing that you could simply don't write
the = default at all, but I think that this argument
is not convincing for me to forbid the syntax:
1) If you don't like, just don't write it
2) The syntax gives a message: It says, that i
intend to accept the compiler-generated form
"as is". Programmers, who see this don't have
to look for some hidden expressions of
additional meaning.
HTH & Greetings from Bremen,
Daniel Kr�gler