Re: Why '(&b) -> f() ' is static binding?
On 2007-10-22 21:59, Markus Moll wrote:
Hi
Owen Jacobson wrote:
zhangyafei_k...@163.com wrote:
base b ;
...
(&b) -> ~base() ;
Undefined behaviour. The variable 'b' was not creating using
placement new, and the object is not being destoryed; you are not
permitted to invoke the destructor here.
Um... what was that famous saying again? "Chapter and verse, please?"
I don't see anything that would forbid explicitly calling the destructor for
objects with automatic storage duration. On the contrary, the example in
12.4(14) seems to suggest that it's perfectly fine.
new (&b) derive ;
Undefined behaviour.
Agreed, but only because I think there are no guarantees about alignment.
The variable 'b' must hold an instance of base, not any other class.
Phew... only partially agreed. I think there may be other objects residing
in the memory of b, given that size and alignment requirements are
satisfied. However...
The compiler is permitted to assume this and
skip virtual dispatch for methods on b,
... you may not access any other (non-"base") object through b (3.10(15)).
This also says that the implicit destruction of b will result in undefined
behavior (because the destructor for base is called).
I think the following would be fine, though:
There are two things that makes me unsure.
#include <new>
struct X { int a; int b; };
int main()
{
X x;
x.~X();
new(&x) int; // x must be properly aligned for ints (9.2(17))
After the destructor has been invoked the object no longer exists, can
you then take the address of it?
int& y = reinterpret_cast<int&>(x);
y = 5;
y.~int();
new(&x) X;
}
And here x's destructor would be implicitly invoked, which would result
in UB.
This makes me wonder, is it possible to explicitly invoke the destructor
of an automatic object and not end up with UB? It would require a way to
exit a block in a way that would normally not implicitly invoke the
objects destructor.
--
Erik Wikstr??m