On Mon, Jun 03, 2013 at 04:33:10PM +0200, Adam D. Ruppe wrote: > On Monday, 3 June 2013 at 14:20:06 UTC, Dicebot wrote: > >I don't see how struct with a disabled copy constructor is > >relevant to owned pointers. > > My thought is then you can control access to the inner pointer > better that way. You couldn't even pass this struct to a function > without calling some kind of method, which could return a different > type to indicate that it is a lent pointer.
This is an old idea. It's the same as C++'s auto_ptr, and the same as an old idea I independently came up with many years ago. Basically, you have two kinds of pointers: a reference pointer and an owner pointer. An owner pointer can be freely copied into a reference pointer, but never the other way around. An owner pointer is unique, so it has destructive copy semantics (passing it into a function invalidates it in the caller's scope, for example -- if a function doesn't need ownership of the passed object, it should take a reference argument, to which an owner pointer implicitly converts). When it goes out of scope, it's freed. Reference pointers are never freed. Of course, this scheme doesn't correctly deal with dangling reference pointers, but in a manual memory management system, you have to deal with that manually anyway, so it doesn't really matter. Distinguishing between these two kinds of pointers for the most part eliminates a lot of pointer-related bugs. For the most part, this scheme is sufficient to handle a majority of pointer uses. The remaining cases involve multiple references to objects with no clear ownership designation or lifetime. IME, this is relatively confined to specific areas of usage, for which the GC is a better memory management scheme anyway. > It also wouldn't need to be reference counted, since the refcount is > always going to be 1 because copying it is impossible. One should always be aware that there's a rough hierarchy of memory management schemes: - direct malloc/free: maximum control, most error-prone - auto_ptr (the above scheme): less error-prone - reference counting: more convenient - GC: very little control, least error-prone The further down you go, the less you have control over the memory management process, but also the more convenient it is to write code. The further up you go, the more control you have, but also the harder it is to write correct code (and the more error-prone it is). Given D's design of correctness-first, it would seem that GC by default is the correct choice. But it should definitely also allow moving up the hierarchy for applications that require finer control over memory management. Currently D allows this in theory, but in practice, much of Phobos assumes the GC, which greatly reduces its usefulness in such cases. > >Most similar thing D has is "scope" qualifier concept (and that is > >why I do want it so hard :)) - hard guarantee that no pointer to > >your data will live longer than data itself. All normal pointers > >become managed pointers in that sense. > > Yes, I'm just trying to do what we can with the language today. auto_ptr can be easily implemented with the language today. It's more a question of Phobos / certain language constructs *using* it. T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
