C++ Logo

SG12

Advanced search

Subject: [ub] Fwd: Tomorrow's paper on N2367 Object detachment and attachment
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-04-29 15:02:12


CC-ing the WG21 UB study group with this email I just sent to the WG14
reflector, for SG12's information. Comments and thoughts are welcome.

Niall

-------- Forwarded Message --------
Subject: Tomorrow's paper on N2367 Object detachment and attachment
Date: Mon, 29 Apr 2019 20:59:37 +0100
From: Niall Douglas <niall_at_[hidden]>
To: ISO C <sc22wg14_at_[hidden]>

Some asked me to post the slides for tomorrow's presentation now so they
can be studied beforehand, and I grilled more severely tomorrow morning:

https://docs.google.com/presentation/d/1_pkP6Uy_Je1_B0YYOCcW4Ld6E-gKSZAQQdOLrlgQAKw/edit?usp=sharing

Essentially these are "unidirectional reinterpret casts with lifetime
end". Lifetime of the input object ends with the cast, unlike
reinterpret casts. All pointers to the input become indeterminate, only
the returned byte array is a valid way of addressing that storage.

More interesting to some of you will be working reference implementation
code that you can play with online:

https://godbolt.org/z/ou8VFT

I appreciate it's all C++, so I added extra lengthy explanatory
commenting. Trivially copyable types in C++ are types with a trivial
copy constructor and trivial destructor. Special C-like semantics are
defined for them in the C++ standard e.g. you can use memcpy() or
memmove() on them, hence the reference implementation is well defined
for trivially copyable types.

What's the relevance of this WG21 paper to C?

The proposed new abstract machine operations of detach and attach apply
equally to C as they do to C++. They similarly make possible well
defined zero copy serialisation, used of shared memory, and memory
mapped file i/o for C as well as for C++.

At the WG21 meeting in July, SG12 will almost certainly ask me whether
this proposal flies with WG14. So I will be asking tomorrow for a straw
poll on the two proposed new operations, and I will take that vote with
me to WG21 SG12.

I would be particularly interested to hear from compiler implementers on
if these proposed new operations would be in any way problematic for
their implementations.

My thanks in advance.

Niall


SG12 list run by herb.sutter at gmail.com