Herb Sutter on zero cost exceptions for C++

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Sep 27 16:40:10 UTC 2019


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)
> 
> https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

Thanks for the link! I've also been wondering, with all this talk about
@live.

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.  Here's an enhancement based on an idea I
had years ago: the concept of differentiating between "owning" pointers
and "non-owning" pointers.

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.

A "non-owning" pointer cannot be passed to free() (or equivalent). 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
itself).

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.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte


More information about the Digitalmars-d mailing list