Array types not treated uniformly when passed as ranges
Jonathan M Davis
jmdavisProg at gmx.com
Tue Feb 15 11:43:38 PST 2011
On Tuesday, February 15, 2011 06:10:57 Steven Schveighoffer wrote:
> On Mon, 14 Feb 2011 22:59:52 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
>
> wrote:
> > It's because an Array is not a range. Dynamic arrays are a bit special
> > in that
> > they're both a container and a range. An Array is just a container. But
> > honestly, you wouldn't really want it to work.
>
> Dynamic arrays are not containers. They do not own the data they
> reference, they just reference that data. In fact, the owner of the data
> is really the runtime.
>
> The naming of Array makes this a difficult thing to understand. An Array
> owns its data, it manages the data, creates it, destroys it, and there is
> no way to "slice" the Array into a smaller Array. It's a true reference
> type. A builtin array is not really a container, so it really should be
> named differently. But there's no way to change that.
>
> > However, this won't work for containers in general. If you pass an
> > Array, you're
> > passing the container. The passed in Array is identical to the original
> > (currently, Array is a struct with reference semantics thanks to internal
> > reference counting, but soon it will become a class and more obviously
> > have
> > reference semantics). As such, if you alter the passed in Array, you
> > alter the
> > original. So, if you were to continuously pop the front off of the
> > passed in
> > Array, you would be continually popping the front off of the original
> > Array. So,
> > a function like find would actually remove the front part of your Array
> > as it
> > processed it, and if what you were trying to find wasn't there, you'd
> > have an
> > empty Array. The way to fix this is to not have Array be a range.
> > Instead, you
> > have a helper type which is a range over it. You get that with the slice
> > operator.
>
> This is a good way to explain it.
>
> > You don't have the problem with arrays that you'd have with user-defined
> > container types, because the semantics of arrays are a bit odd when you
> > copy
> > them. So, if anything were faulty, it would be the built in arrays, not
> > user-
> > defined container types like Array. It is quite handy to have arrays
> > work how
> > they work, however, so that's not likely to change.
>
> What is faulty is that they are called arrays. They are slices.
Yeah. I guess that arrays aren't really technically containers in that they
don't actually own the memory that they refer to. Arrays are just a bit weird
overall (not necessarily badly designed, just a bit weird). And there really is
no difference in D between a slice and an array as far as arrays go, which may
not be clear to everyone...
The overal result is that arrays are actually pretty easy to use and definitely
very powerful, but discussing and explaining them can get a bit entertaining.
- Jonathan M Davis
More information about the Digitalmars-d-learn
mailing list