On 11-12-2012 21:24, Dmitry Olshansky wrote:
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.
Then our current slice design is broken.
int[] arr;
arr.length = 1024; // guess where this memory comes from?
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?
Exactly what you wrote. Remember, the ptr field doesn't change meaning.
Same question with slicing a raw pointer - what will the base contain?
(The pointer _might_ have been interior.)
Of course you have to take care not to slice an interior pointer and let
the base pointer go out of scope.
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.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
