"Walter" <walter@digitalmars.com> wrote in news:ao9lh9$1gta$1@digitaldaemon.com:

> 
> "chris jones" <flak@clara.co.uk> wrote in message news:anigdn$1rek$1@digitaldaemon.com...
>> This is what troubles me. Arrays as parameters have diferances from all
> the
>> other parameter types. They are basicly pointers with bounds checking.
> 
> That is essentially correct.
> 
>> I dont know. Slicing does have some great benefits but i just dont like arrays as they are, they seem compromised for the sake of slicing.
> 
> I too initially shared your reluctance for the idea.

When one first reads the D documentation the initial reaction
is, "Cool two of the most used high level container types,
resizable arrays and maps (assoc array), are implemented in
the language."  However arrays in D arrays aren't really
the high level contain construct that people associate with
the STL vector template.  Array and slice semantics are going
to be the most confusing thing to understand for a new person
learning D.

I think that you are trying to accomplish two different goals with arrays in D and I think these goals are incompatible. One of the these goals is creating a safe bound checked pointer and the other goal is to use arrays as a container type.

You are absolutely correct, slices are very useful constructs for a lot of tasks.  However as a container type arrays in D are not as functional as one might desire.  As a container arrays should have the object reference semantics.  Modify an object one place and all the other references see the change. Right now if you change the array length you run the risk that other array references now don't refer to the same array.

I believe you should really separate the concepts of the slice and array.  Create two different types.  Let the slice play the role of the safe bounds checked pointer and expand arrays to have suitable container semantics for the type.

Yes... slices and arrays are really two different things.  The array is the actual container and a slice is a reduced functionality subset that's more like a boundschecked pointer.

I think most of the time when you take an array parameter you should actually take a slice instead, unless you want a reference to the actual array.

Sean

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92A5AF708AFD0patcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ao9lh9$1gta$1@digitaldaemon.com:
>
> When one first reads the D documentation the initial reaction
> is, "Cool two of the most used high level container types,
> resizable arrays and maps (assoc array), are implemented in
> the language."  However arrays in D arrays aren't really
> the high level contain construct that people associate with
> the STL vector template.  Array and slice semantics are going
> to be the most confusing thing to understand for a new person
> learning D.
>
> I think that you are trying to accomplish two different goals
> with arrays in D and I think these goals are incompatible.
> One of the these goals is creating a safe bound checked pointer
> and the other goal is to use arrays as a container type.
>
> You are absolutely correct, slices are very useful constructs for a lot of tasks.  However as a container type arrays in D are not as functional as one might desire.  As a container arrays should have the object reference semantics.  Modify an object one place and all the other references see the change. Right now if you change the array length you run the risk that other array references now don't refer to the same array.
>
> I believe you should really separate the concepts of the slice and array.  Create two different types.  Let the slice play the role of the safe bounds checked pointer and expand arrays to have suitable container semantics for the type.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92A5AF708AFD0patcodemooncom@63.105.9.61...
> When one first reads the D documentation the initial reaction
> is, "Cool two of the most used high level container types,
> resizable arrays and maps (assoc array), are implemented in
> the language."  However arrays in D arrays aren't really
> the high level contain construct that people associate with
> the STL vector template.  Array and slice semantics are going
> to be the most confusing thing to understand for a new person
> learning D.

Perhaps. They are their own animal. Once they are looked at on their own terms, rather than C, STL, Java, or Javascript style arrays, then they make sense.

> I think that you are trying to accomplish two different goals
> with arrays in D and I think these goals are incompatible.
> One of the these goals is creating a safe bound checked pointer
> and the other goal is to use arrays as a container type.
>
> You are absolutely correct, slices are very useful constructs for a lot of tasks.  However as a container type arrays in D are not as functional as one might desire.  As a container arrays should have the object reference semantics.  Modify an object one place and all the other references see the change. Right now if you change the array length you run the risk that other array references now don't refer to the same array.
>
> I believe you should really separate the concepts of the slice and array.  Create two different types.  Let the slice play the role of the safe bounds checked pointer and expand arrays to have suitable container semantics for the type.

Separating slices and arrays into different types won't change the resize problem.

BTW, I should mention that Jan Knepper provided much early inspiration and motivation for me to do the slices.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:aoa357$1vcr$1@digitaldaemon.com...
> >> I dont know. Slicing does have some great benefits but i just dont like arrays as they are, they seem compromised for the sake of slicing.
> >
> >I too initially shared your reluctance for the idea.
> >
> >...once people get used to slicing, they'll find it a huge convenience and performance boost.
>
> Right on, Walter.  If Chris wants C arrays let him use C!

I wasnt arguing for C like arrays. More the oposite.

chris

Walter wrote:
> "Patrick Down" <pat@codemoon.com> wrote in message
> news:Xns92A5AF708AFD0patcodemooncom@63.105.9.61...
> 
>>When one first reads the D documentation the initial reaction
>>is, "Cool two of the most used high level container types,
>>resizable arrays and maps (assoc array), are implemented in
>>the language."  However arrays in D arrays aren't really
>>the high level contain construct that people associate with
>>the STL vector template.  Array and slice semantics are going
>>to be the most confusing thing to understand for a new person
>>learning D.
> 
> Perhaps. They are their own animal. Once they are looked at on their own
> terms, rather than C, STL, Java, or Javascript style arrays, then they make
> sense.

Agreed vehemently.  It's the proper tool for the software environment, and I've never found it hard-to-deal-with in D code.  In fact, D has taken over Python for me in the ease of use department, which only has the advantage in string methods, being able to run as a script, and a far better library.  That's not a theoretical "D looks better than Python if I ever got around to using it"; it is.

>>I think that you are trying to accomplish two different goals
>>with arrays in D and I think these goals are incompatible.
>>One of the these goals is creating a safe bound checked pointer
>>and the other goal is to use arrays as a container type.
>>
>>You are absolutely correct, slices are very useful constructs
>>for a lot of tasks.  However as a container type arrays in D
>>are not as functional as one might desire.  As a container
>>arrays should have the object reference semantics.  Modify an
>>object one place and all the other references see the change.
>>Right now if you change the array length you run the risk that
>>other array references now don't refer to the same array.
>>
>>I believe you should really separate the concepts of the slice
>>and array.  Create two different types.  Let the slice play
>>the role of the safe bounds checked pointer and expand arrays
>>to have suitable container semantics for the type.
> 
> Separating slices and arrays into different types won't change the resize
> problem.

The ownership bit separates them AND distinguishes between an array and an array copy.  If I understand your method correctly (and I don't, as you never explained what your mysterious changes allowed):

    char [] array = "cheese_".dup;
    char [] copy = array;

    copy ~= "foo";
    array ~= "gee";

In this case, copy may be "cheese_gee" if the second append fit in the allocation, right?  That doesn't happen in DLI - copy doesn't own the array, hence must allocate.  The only thing the ownership bit changes from non-overallocating is whether append results in a new pointer or not.

"Walter" <walter@digitalmars.com> wrote in news:aob6o5$31ao$1@digitaldaemon.com:

> Separating slices and arrays into different types won't change the resize problem.

Not in their present form.  Separating the types would allow arrays to have a different implementation.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92A5AF708AFD0patcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ao9lh9$1gta$1@digitaldaemon.com:
>
> >
> > "chris jones" <flak@clara.co.uk> wrote in message news:anigdn$1rek$1@digitaldaemon.com...
> >> This is what troubles me. Arrays as parameters have diferances from all
> > the
> >> other parameter types. They are basicly pointers with bounds checking.
> >
> > That is essentially correct.
> >
> >> I dont know. Slicing does have some great benefits but i just dont like arrays as they are, they seem compromised for the sake of slicing.
> >
> > I too initially shared your reluctance for the idea.
>
> When one first reads the D documentation the initial reaction
> is, "Cool two of the most used high level container types,
> resizable arrays and maps (assoc array), are implemented in
> the language."  However arrays in D arrays aren't really
> the high level contain construct that people associate with
> the STL vector template.  Array and slice semantics are going
> to be the most confusing thing to understand for a new person
> learning D.

I agree.

Basically:
void fn(in int[] a)
is the same as
void fn(int *a, int len)
Effectively you cannot resize the array inside the function. If you only
used C, that will be quite easy.

But this concept of arrays is quite ... deprecated. Nowadays arrays are thought of as self-encapsulated objects. The length and the contents are both immutable or both changeable. The "inout" guarantees that both of them is changeable.

void fn(inout int[] a) in D
is same as
void fn(vector<int> &a)  in C++.

In both languages, one more level of indirection is needed to access the
items, so they will be slower, than the previous case.
So you can choose: Speed or logical concept.

Also see my post in the thread "Re: passing arrays as "in" parameter with suprising results".

Sandor

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:aoc5bl$sae$1@digitaldaemon.com...
> Walter wrote:
> > Perhaps. They are their own animal. Once they are looked at on their own terms, rather than C, STL, Java, or Javascript style arrays, then they
make
> > sense.
> Agreed vehemently.  It's the proper tool for the software environment, and I've never found it hard-to-deal-with in D code.  In fact, D has taken over Python for me in the ease of use department, which only has the advantage in string methods, being able to run as a script, and a far better library.  That's not a theoretical "D looks better than Python if I ever got around to using it"; it is.

I'm using D now for new code, and it sure beats everything else.

> The ownership bit separates them AND distinguishes between an array and an array copy.  If I understand your method correctly (and I don't, as you never explained what your mysterious changes allowed):
>
>      char [] array = "cheese_".dup;
>      char [] copy = array;
>
>      copy ~= "foo";
>      array ~= "gee";
>
> In this case, copy may be "cheese_gee" if the second append fit in the allocation, right?  That doesn't happen in DLI - copy doesn't own the array, hence must allocate.  The only thing the ownership bit changes from non-overallocating is whether append results in a new pointer or not.

What my method (!) is is to have the garbage collector find the allocation block for the array being resized. If it is outside the gc pool, or not at the start of the block, it allocates a new one. Otherwise, it resizes in place if the resize will fit.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:aoe332$2qji$1@digitaldaemon.com...
> But this concept of arrays is quite ... deprecated. Nowadays arrays are thought of as self-encapsulated objects.

True, but none of the languages that do so can match the array handling performance of D.

"Walter" <walter@digitalmars.com> wrote in message news:aol69i$12j2$1@digitaldaemon.com...
>
> "Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:aoe332$2qji$1@digitaldaemon.com...
> > But this concept of arrays is quite ... deprecated. Nowadays arrays are thought of as self-encapsulated objects.
>
> True, but none of the languages that do so can match the array handling performance of D.

Ok, so you now have a fast array type, which is a good thing in some
situations.
Now we have to think about creating a separate full-featured array *class*,
possibly in the standard library, with [] operator overload and
self-encapsulation, and ... well ... poorer performance than the built-in
array.

Sandor