Does the proposal attempt to handle the case where a single map_view is
mapped to two locations simultaneously within a given program? This is
sometimes called "mirror mapping". I suppose that optimizing compilers
could be really confused by mirror mapping. This is probably already true,
but so far, programmers have done things like make circular buffers using
mirror mapping without too much difficulty.

On Tue, Mar 26, 2019 at 2:24 PM Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> Bounced due to low attachment size limit. I uploaded a copy of the draft
> paper to:
>
>
> https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf
>
> Niall
>
> -------- Forwarded Message --------
> Subject: Draft 2 of Enhanced C/C++ memory and object model
> Date: Mon, 25 Mar 2019 13:16:10 +0000
> From: Niall Douglas <s_sourceforge_at_[hidden]>
> To: ub_at_[hidden]
> CC: Jens Gustedt <jens.gustedt_at_[hidden]>, Uecker, Martin
> <Martin.Uecker_at_[hidden]>, Hal Finkel <hfinkel_at_[hidden]>
>
> Dear SG12,
>
> CC: Relevant members of WG14, and Hal
>
> Please find attached draft 2 of my upcoming SG12 and WG14 targeted paper
> proposing an enhanced memory and object model for C++ and C based around
> implementing a subset of P1434 "Discussing pointer provenance" to make
> much more rigorous the modification of memory, and adding two new core
> operations to objects:
>
> 1. Detachment, the reinterpretation of a live object into an array of
> bytes representing that object.
>
> 2. Attachment, the reinterpretation of a previously detached object
> representation into a live object.
>
> It is believed that these changes are sufficient to implement memory
> shared between concurrent processes, memory mapped in from another
> device by DMA, process bootstrap from a database of shared binary
> Modules, and the elemental operations for implementing zero-copy
> serialisation and deserialisation.
>
> One also gains object relocation in memory, and substantially enhanced
> default move implementations which can use CPU registers for object
> transport.
>
>
> I appreciate that this proposal is huge, the standardese in the paper
> meagre and incomplete, and chances of success are very low. Still, I
> hope to discuss it at Cologne and subsequent SG12 meetings, if Gaby
> wishes to give time to it. I'll also be taking it to the May WG14
> meeting, and see how much the C folk hate it.
>
> Feedback is welcome.
>
> Niall
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>