C++ Logo


Advanced search

Re: [ub] Draft 2 of Enhanced C/C++ memory and object model

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Tue, 26 Mar 2019 23:51:04 +0100
"associated contractual precondition"

Contracts are defined for functions, not for built-in operations.
If you want to extend the concept, it might be better to
avoid the word "contract" and "precondition" and just
state the conditions and the effects when violated.

"non-void, non-null, non-function pointer object"

This mixes value with type and has a lot of "non".
Also, is this intended to cover only pointer objects
(i.e. pointers that are materialized somewhere in memory)
or also pointer values (which might live in a register)?
I think this wants to talk about both.

Suggestion: "non-null pointer to object"

Where did "safely-derived pointer value" go? The section
was replaced entirely, it seems.

"The following operations involving two non-void, non-null pointers shall fail to compile with a
Comparisons, including equality and inequality, of two pointers without common provenance
(user should convert to void* beforehand)."

It seems "provenance" of a pointer is a runtime property, so how can
that cause a compile-time diagnostic?


On 26/03/2019 22.23, Niall Douglas 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

Received on 2019-03-26 23:56:10