Orphan ranges
Tove
tove at fransson.se
Sun Apr 15 10:03:43 PDT 2012
On Sunday, 15 April 2012 at 16:34:12 UTC, Andrei Alexandrescu
wrote:
> I'm making good progress on an allocator design. If things come
> together as I hope, it'll kick some serious ass.
>
> I'm currently looking at four allocation models:
>
> * straight GC, safe (no deallocation)
> * GC + the ability to free memory
> * malloc/free, unsafe, buyer beware (STL-level safety)
> * reference counted (based on either malloc or GC+free)
> * region (scoped)
>
> I need to kink out a few details, most important being - is
> safety part of the allocator or an extricable property that's a
> different policy? For now I have a related question about
> orphan ranges.
>
> Consider this motivating example:
>
> void main()
> {
> int[] x;
> {
> auto b = new int[20];
> x = b[5 .. $ - 5];
> }
> ... use x ...
> }
>
> The range x is a 10-elements range that originates in a
> 20-element array. There is no safe way to access the original
> array again, so in a sense the other 10 elements are "lost".
> That's why I call x an orphan range - a range of which original
> container is gone.
>
> Built-in arrays work routinely like that, and in fact the
> originating arrays are not distinguished by type in any way
> from their ranges (be they orphan or not). The question is,
> what should std.container do about orphan ranges in general?
> Should it allow them, disallow them, or leave the decision open
> (e.g. to be made by the allocator)? Depending on what way we
> go, the low-level design would be quite different.
>
>
> Thanks,
>
> Andrei
Wow, cool!
To flat out disallow Orphan ranges is imho too restrictive,
especially considering we already have a safe solution, what is
missing is an unsafe(no overhead) version.
If the design can handle safe/unsafe as a policy for a
stack(scoped) based allocator... that would be kick ass, indeed.
More information about the Digitalmars-d
mailing list