Re: Why '(&b) -> f() ' is static binding?
Hi
Erik Wikstr?m wrote:
On 2007-10-22 21:59, Markus Moll wrote:
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?
Sure.
3.8(6) [Object Lifetime]
Similarly, before the lifetime of an object has started but after the
storage which the object will occupy has been allocated or, after the
lifetime of an object has ended and before the storage which the object
occupied is reused or released, any lvalue which refers to the original
object may be used but only in limited ways. Such an lvalue refers to
allocated storage (3.7.3.2), and using the properties of the lvalue which
do not depend on its value is well-defined.
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.
That was the reason why, at the very end, I again constructed an X
object ;-)
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.
No, IMO it just requires that at the end, before the scope is left, there is
an object of the original type.
Markus