On Sat, 11 Feb 2012 01:37:47 +0100, Martin Nowak <[email protected]> wrote:
On Fri, 10 Feb 2012 21:18:46 +0100, Andrei Alexandrescu
<[email protected]> wrote:
On 2/10/12 11:42 AM, Martin Nowak wrote:
On Fri, 10 Feb 2012 16:35:18 +0100, kenji hara <[email protected]>
wrote:
I think std.typecons.Unique should place the object ownership under
the control.
Unique!T holds the unique ownership of given object typed T.
yes, Unique can hold an object on heap, but also should be able to
hold stack allocated object.
(In this case, Unique!T will work as rebindable scoped!T, IMO)
An experimental implementation of mine.
https://github.com/9rnsr/scrap/blob/master/typecons/unique.d
Kenji Hara
Can you give an example where a unique value type is useful.
Transferring ownership across threads. Thanks Kenji for working on
this. An essential aspect will be to get the move right.
Andrei
I probably miss the point but here is what I see.
Values are unshared by default so transferring ownership
only make sense for structs owning shared resources.
To make this safe you'd need to enforce uniqueness for all fields as
well.
Aliasing and static values are corner cases of that rule.
What I wanted to add is a unique_ptr like construct to help
reducing the pervasive use of GC memory for unshared objects.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
Well the obvious example is are files or any kind of handles.
So unique can't enforce uniqueness when being created but helps
to avoid accidental duplication.
It seems like a unique_ptr construct would be most helpful after
the allocator interface is known. It could probably still use Unique
if the allocated object is wrapped in a struct that does the freeing.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
