Herb Sutter on zero cost exceptions for C++
timon.gehr at gmx.ch
Fri Sep 27 17:13:36 UTC 2019
On 27.09.19 18:40, H. S. Teoh wrote:
> On Fri, Sep 27, 2019 at 09:55:27AM +0000, Paulo Pinto via Digitalmars-d wrote:
>> On Friday, 27 September 2019 at 09:36:33 UTC, a11e99z wrote:
>>> what is @life? (searching by forum gives only this message)
> Thanks for the link! I've also been wondering, with all this talk about
> One comment on the article, though: ownership as defined by Walter seems
> unnecessarily restrictive, in that it's impossible to have multiple
> mutable pointers to an object.
Not impossible, you are just not supposed to do it. The proposal does
zero checking at the @safe/@live interface, which means it's by
convention. @live in the best case does nothing at all and in the worst
case rips holes into @safe instead of closing them.
> Here's an enhancement based on an idea I
> had years ago: the concept of differentiating between "owning" pointers
> and "non-owning" pointers.
Yes, that's much better than a function attribute, but owning pointers
don't need to be a built-in language concept. (See Rust.)
> An owning pointer is basically what Walter describes -- only a single
> such pointer can exist per object, and when that pointer goes out of the
> scope the object gets freed. Allocation functions like malloc() return
> an owning pointer. During its lifetime, however, any number of
> "non-owning" pointers can be made from it.
That's what's called borrowing in Rust, but you need to be careful.
> A "non-owning" pointer cannot be passed to free() (or equivalent).
Issue is you can have a non-owning pointer pointing to a data structure
that contains owning pointers.
> In this scheme, free() only ever accepts an owning pointer. Furthermore, a
> non-owning pointer cannot outlive the scope of the owning pointer: they
> are 'scope', and their scope must be statically provable to be a subset
> of the scope of the owning pointer they are borrowing from. There is no
> need to restrict them with regards to mutability, however.
> This system can be implemented using RAII: pointers returned from memory
> allocators like malloc() are wrapped in an OwnerPtr struct that frees
> the pointer once it goes out of scope. It overrides assignment and copy
> ctors such that an OwnerPtr becomes null after it gets copied to another
> OwnerPtr (it has move semantics, and disables copy).
> An OwnerPtr can be copied into a regular pointer, under the condition
> that the regular pointer is scope (it cannot outlive the OwnerPtr
As mentioned above this works if you have only one level of indirection.
> I used to actually use this scheme for memory management back when I was
> writing C/C++ code, and it works fairly well: only back then I didn't
> have 'scope' so there was the danger of a non-owning pointer leaking out
> and becoming a dangling pointer. With D's scope, this becomes a
> waterproof scheme AFAICT.
Not really. E.g., you can have two non-owning pointers to a Array!int
and then one of them reassigns the array, while the other borrowed a
pointer to one of its elements. Rust enforces no mutable aliasing
exactly because reassigning something may cause the old value to be
More information about the Digitalmars-d