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