Array Slices and Interior Pointers

[Dmitry Olshansky]

12/11/2012 11:23 PM, Alex Rønne Petersen пишет:
> On 11-12-2012 20:09, Dmitry Olshansky wrote:
>> 12/11/2012 4:04 AM, Alex Rønne Petersen пишет:
>>> http://xtzgzorex.wordpress.com/2012/12/11/array-slices-and-interior-pointers/
>>>
>>>
>>>
>>>
>>> Destroy.
>>>
>>
>> Aside from the fact that I can use slices without GC just fine? :)
>> The base pointers would then be either counted, released manually or
>> implicitly as part of stack unwinding.
>
> Yes, in theory. But that's not how most idiomatic D code written today
> works.
>

I'd mention that the most of idiomatic D code is agnostic with respect 
to the origin of slice. The major reason to use slices is to avoid 
allocations and thus the allocation scheme is not important up to the 
point of explicit copy.

And at that point e.g. Phobos plays it safe and does everything that has 
to copy or incrementally build via GC. And it gets bashed for it every 
once in a while. To put simply it's because there is no concept of 
allocators in idiomatic D code _yet_.

And separating slices and allocation mechanism behind them is the key of 
usability of slices as they stand. If we add stuff that makes them 50% 
more bulky and helps only a certain scheme of GC memory allocation we 
are screwed.

Also what would direct operations with ptr field translate to in your 
scheme e.g.:
arr.ptr = arr.ptr+x;

where ptr+x is hidden by some function and not obvious to the compiler?

Same question with slicing a raw pointer - what will the base contain? 
(The pointer _might_ have been interior.)

>>
>> I personally think that managed VMs are going to have to emulate slices
>> and pointers as an array object + one or pair of offsets. In fact it
>> could be implemented as an abstract object with implementation depending
>> on where you did get that pointer from.
>>


-- 
Dmitry Olshansky