I just want to ask Walter how this would work if in deed .length were a property that could be directly changed.

These chunks of code -

int[] array1 = { 3,3,3 };

int[] array2 = new int[3];
for( int i=0;i<array2.length;i++)
    array2[i] = 3;

Are array1 and array2 now virtually identical?

Now -

array2.length = 298374;    //  What exactly happens here?

for( int i=0; i<array2.length; i++)
    array2[i] = 3;

The step where you change the length of the array - how much work actually takes place there?  That seems to be quite a complicated process, not nearly as simple as just changing a "length" variable, but rather allocating new memory, copying the old elements to the new space, and perhaps some other administrative stuff.

Correct me if I'm wrong on that...

But if I'm right, should that really be something that's automated?

-Brady


"Russ Lewis" <russ@deming-os.org> wrote in message news:3B96A34F.DABE45E5@deming-os.org...
> I'm assuming that the .length property of a dynamic array can be set, causing the code to change the size, right?  This is not specified in the spec, that I can see.
>
> Also, I assume that such a resize operation can (if expanding) result in an out-of-memory exception being thrown, just like operator new.  I don't see specs for either of those...
>

> If you're a massochist, implement a Vector class in D by allocating an array with new, saving a pointer to that array, and making people do everything by hand.

I expeted that, and I answered it already in the original post, spend a whole paragraph on explaining how programmers feeling can be quite depressing if his code is 'second class' to what language offers.

> I don't know what you mean about "allocation strategy" exactly.  The "append" operation appends a single element onto an array, presumably increasing it by only one element.  That's a simple increase by one...nice for algorithms, although it's kind of wasteful if you end up having to do it a

Exactly! So which one do you force on the user? If you add only a few seldom times +1 might be okay, but most of the times you've to use a dynamic array at all it's not. A good algorithm has been proofen to double the size of the vector each time the memory exceeds, most vectors I've seen to that this way.

If you say simply set the size to what I want to add before, well generally if I would know the size I will use I would not need a dynamic vector after all or?

And saying before each append() check the size and expand it before, there is no longer any comfort at this language idea when using it, you would end up implementing it in a class having won null as net result.

I think I've even seen sometimes a vector class that even allowed to change it's allocation strategy by the user. I guess it were even the java ones, for people knowing what they do, they could specify at class construction the initial vector size, and the reallaction factor (ie. 2.0 is the default)

- Axel

Charles Hixson wrote:

> Are you resizing the array, or just changing the length of it that is counted as filled?  If you are resizing the array, then I don't like that syntax.  It seems to imply that what you are doing is taking a string, and then saying "I'm interested in *this* much of it".  I.e., it implies that all that you are doing is changing a variable.  If this includes an implicit resize and potentially string copying and garbage collection, then it seems to be to be the wrong syntax.  On the other hand, it would frequently be nice to take a block of text and say "this variable represents 20 characters starting at character 97".  (But this doesn't seem to be what D strings are.  Pity. Could you consider string range variables?)

If you are trying to get a substring of a string, just use this syntax:

char[] longString = /*some code that creates a long string*/;
char[] subString = longString[97..116]; /* contains 20 characters of the other
string */

This (in cooperation with garbage collection) is going to be *really* nice for regular expressions.  You can just return a dynamic array that is a subset of another string.  Since strings are not null terminated in D, no copying is needed!

Axel Kittenberger wrote:

> > If you're a massochist, implement a Vector class in D by allocating an array with new, saving a pointer to that array, and making people do everything by hand.
>
> I expeted that, and I answered it already in the original post, spend a whole paragraph on explaining how programmers feeling can be quite depressing if his code is 'second class' to what language offers.

I apologize for the 'massochist' remark.  It was meant light-heartedly, but I should have remembered that such things don't work well in newsgroups.

I apologize.

> > I don't know what you mean about "allocation strategy" exactly.  The "append" operation appends a single element onto an array, presumably increasing it by only one element.  That's a simple increase by one...nice for algorithms, although it's kind of wasteful if you end up having to do it a
>
> Exactly! So which one do you force on the user? If you add only a few seldom times +1 might be okay, but most of the times you've to use a dynamic array at all it's not. A good algorithm has been proofen to double the size of the vector each time the memory exceeds, most vectors I've seen to that this way.
>
> If you say simply set the size to what I want to add before, well generally if I would know the size I will use I would not need a dynamic vector after all or?
>
> And saying before each append() check the size and expand it before, there is no longer any comfort at this language idea when using it, you would end up implementing it in a class having won null as net result.
>
> I think I've even seen sometimes a vector class that even allowed to change it's allocation strategy by the user. I guess it were even the java ones, for people knowing what they do, they could specify at class construction the initial vector size, and the reallaction factor (ie. 2.0 is the default)

So you're talking about a class that automatically expands the array when you run out, without user code?  I guess I can see that.

I'm just having trouble understanding how having the arrays length-aware hurts anything.  A C++ implementation of a vector would include a pointer for the array, a length field, and (if it is used sequentially) a "used" field.  In D, the length field is included in the fundamental type; I don't understand how that makes any allocation or management algorithms "second class."

Maybe I'm just missing something huge here...please be patient with me :)

> This (in cooperation with garbage collection) is going to be *really* nice
> for
> regular expressions.  You can just return a dynamic array that is a subset
> of
> another string.  Since strings are not null terminated in D, no copying is
> needed!

Have you considered taking a deeper look at phython? They call it slices, and implement them pretty well: There is more than just creating slices, you can compare them, reverse them, stack them, queue them, etc. etc.

http://python.sourceforge.net/devel-docs/tut/node7.html

Again people, I can only repeat myself, don't take on the script languages! They all run relative slow(er) on runtime, but you'll never be able to pit on them at syntax/comfort.

We've just to distinquish what a language is for. Is in example D a procedural language or a function language? For a functional I would think having dynamic arrays in the language is nealy a must, for a procedural it's a counter indication. Don't try to be a pathic function language, you'll defintly loose against the true functionals, if you want to be a procedural language try to be a good one, and this means high control, predictable memory and code size. control on the generated output (in example allignment) and don't burn up on sugar that would fit better to a functional language.

- Axel

Walter wrote:
> 
> I've gone back and forth on this issue (whether setting .length resizes the array, or is it read-only). What do y'all think?

I think I'm in favor. Is there any other way to resize an array already provided?

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3B97D5B9.9FF40BD7@estarcion.com...
> Walter wrote:
> >
> > I've gone back and forth on this issue (whether setting .length resizes
the
> > array, or is it read-only). What do y'all think?
>
> I think I'm in favor. Is there any other way to resize an array already provided?
>
> -RB

The current way is to new a new array and copy the contents of the old one. Such always seemed like too much fiddling to me, and fiddling code is just more code that harbors bugs. The three choices are:

    array.length = newlength;

    array = renew(array, newlength, array[0].size);

    array.setLength(newlength);

I am leaning towards the first because it is simpler and so less prone to bugs. What I don't like about it is it appears to be a simple assignment, but is not.

"Rui Ferreira" <t5rui@hotmail.com> wrote in message news:9n85lo$k2$1@digitaldaemon.com...
> To choose D as a name for this language and totally abandon the systems programming level instead of building layers of abstraction around it is
not
> exactly paying an homage to C.

C arrays are implemented in D - they have a fixed length and are not resizeable. You lose nothing by going to D. D dynamic arrays are a superset of static arrays.

    int a[3];        // static array, implemented just like in C
    int b[];        // dynamic array, implemented as a layer over static
arrays

Arrays are *such* a basic data structure, I feel that a great deal is gained by building resizable arrays into the language as a primitive. A lot of my code deals with arrays, and all the fiddling to manage their memory eats up much of my time and is lots of code that has bug potential. My experiments show that using D dynamic arrays cleans up a lot of code. Things just get a lot simpler, with no sacrifice in performance.

Note that D dynamic arrays can be used for:

    1) a layer over C static arrays
    2) provides a string data type essentially "for free"
    3) implicitly provides a stack data type

In fact, many uses for linked lists goes away and become arrays.

D associative arrays add to the mix a built in symbol table handling capability. Most of the time, there's no need to go beyond that.

"Bradeeoh" <bradeeoh@crosswinds.net> wrote in message news:9n8e1g$59t$1@digitaldaemon.com...
> The step where you change the length of the array - how much work actually takes place there?  That seems to be quite a complicated process, not
nearly
> as simple as just changing a "length" variable, but rather allocating new memory, copying the old elements to the new space, and perhaps some other administrative stuff.


Assigning to the .length property essentially does a realloc() on the array
data.

Walter wrote:

> The current way is to new a new array and copy the contents of the old one. Such always seemed like too much fiddling to me, and fiddling code is just more code that harbors bugs. The three choices are:
>
>     array.length = newlength;
>
>     array = renew(array, newlength, array[0].size);
>
>     array.setLength(newlength);
>
> I am leaning towards the first because it is simpler and so less prone to bugs. What I don't like about it is it appears to be a simple assignment, but is not.

4th option:
array.append(int[10]);

I think that it's better to have the syntax match programmer conception rather than internal construction.  I believe that there are 3 types of programmers:

Experts: understand the language and compiler in depth.  Are fully aware of the impact of their code.  Shortcuts (like setting .length) just let them code more quickly, efficiently, and accurately.

Newbies/Scripters: only have a vague understanding of the language and the syntax.  Either don't know or don't care what impact their shortcuts have on runtime.

Intermediates (most programmers): have a good understanding of the language, though not expert level.  Understand some key performance drains (mostly what they've read about in textbooks or the web), but sometimes are inefficient. Most programmers are intermediates.



IMHO, experts will use your language only if they find in it an efficient way to express the algorithm they're thinking of.  D's roots in C/C++ mean that we'll get a lot of those.  They will set .length if appropriate, or use other algorithms if they think that something else is better.

Newbies will use only what they can learn and understand quickly.  Setting .length is good for them, since they can easily see what it does (though they have no idea how it does it).

Some intermediates will use .length judiciously, knowing its cost.  Others will abuse it.

Having the language easy to read encourages newbies to become intermediates, since it's easy to use and come to know the language.  Similarly, it encourages intermediates to become experts, as they spend less time learning (and relearning) the syntax of the language and more time getting (or reading/hearing about) real experience with the language.

So that's my $.02