Re: x.~int();

[Alf P. Steinbach]

On 19.01.2017 20:58, Stefan Ram wrote:
> Lisa Lippincott used »x.~int();« in a talk.
>
> It did not compile here, but then I thought that she might
> have intended this to be read more "symbolically" than as
> executable code.

No, she was serious, but made a little error.

The following is valid code:

#include <new>
using Int = int;
void alpha( int & x ){ x.~Int(); new( &x )int; }
auto main() -> int {}

The inclusion of `<new>` is necessary for the placement new.

The `Int` alias is necessary because `int` is just a keyword.

Yeah, that last part is weird, really weird. An unexpected grayish
corner case of the language. But pseudo constructors and destructors are
a feature mainly meant for template code, where, if this feature were
commonly used, it would usually be `x.~T()`, like.


> She also used a funny placement new to make readable
> (i.e., initialized) int storage unreadable

No no, the placement new /reinitializes/ the storage, after the pseudo
destructor call has allegedly put an indeterminate value there.


> (i.e., uninitialized) again, »new( &x )int;«.
>
> Actually these two lines were written directly in this
> order, her code was (I changed some unimportant details):
>
> void alpha( int & x ){ x.~int(); new( &x )int; }
>
> . She wanted to show that a function might make readable
> (i.e., initialized) storage unreadable (i.e., uninitialized).

I think that's an unnecessarily complicated formal view of things.


Cheers!,

- Alf

[Alf P. Steinbach]

On 20.01.2017 01:36, Stefan Ram wrote:

> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
>> No no, the placement new /reinitializes/ the storage, after the pseudo
>> destructor call has allegedly put an indeterminate value there.
>>> (i.e., uninitialized) again, »new( &x )int;«.
>

> I assumed that this is the difference between
>
> new( &x )int( 2 );
>
> and
>
> new( &x )int;
>
> . The former reinitializes, but the second one not.
>
> Possibly this might be relevant paragraphs:
>
> »18 A new-expression that creates an object of type T
> initializes that object as follows:
>
> (18.1) --- If the new-initializer is omitted, the object
> is default-initialized (8.6).
>
> [Note: If no initialization is performed, the object has
> an indeterminate value. ---end note ]«
>
> 5.3.4 New [expr.new]
>

Oh you're right. Sorry.

>> I think that's an unnecessarily complicated formal view of things.
>

> That was the point of her talk: Formalizing
> assumptions we usually take for granted.

Well, tell her she'd better make sure all the examples are correct, or
at least work with clang (in the old days we'd use Comeau).

E.g. Marshall Cline once did that for all the examples in the FAQ.


Cheers!

- Alf