Why can't a new row be added to an array as needed?

[MikeB]

I realize that arrays have worked this way for ages, but why do we have
to continue with the old ways?

It would really be nice if you could add a new row (element) to an array
one at a time (as required).

In some cases, the programmer doesn't know how many objects that will be
loaded into an array until runtime. I know you can process the source to
find out how large it is and use this to update a variable that was used
to initialize the array. However, this seem's rather inefficient to me.

Why not create a new row in an array (using "new") just before an
assignment when you are inside a loop (e.g., when you are reading items
from a file line by line)?

This can be done for the creation of other objects. Why can't it be the
same for arrays?

This would be much more intuitive.

Comments?

Mike

 

[Doug Handler]

Mike,

This can easily be handled by using an ArrayList.

Doug

 

[Peter Rilling]

Because there is overhead in maintaining a dynamic array. The object has to
be able to recalculate the end of the array and move objects around. Also,
arrays are special types in the CLR and therefore probably needs to have
some consistent behavior.

Having said that, this is why the ArrayList was invented.

 

[Mark White]

Beat me to it

It's what the ArrayList was designed for, well partially.

Mark

 

[MikeB]

The overhead argument makes sense and as a result it makes sense that
the ArrayList mechanism exists in addition to the standard method.

But I don't think objects would have to be moved around as you have
suggested: What could be done is just change pointers or add new ones.
In this way new rows/elements could be added and they wouldn't have to
be contiguous. But, you are absolutely correct there is additional
overhead and for those embedded systems programmers this might be a
significant issue.

Thanks very much for all the responses.

 

[Jon Skeet [C# MVP]]

The overhead argument makes sense and as a result it makes sense that
the ArrayList mechanism exists in addition to the standard method.

But I don't think objects would have to be moved around as you have
suggested: What could be done is just change pointers or add new ones.
In this way new rows/elements could be added and they wouldn't have to
be contiguous. But, you are absolutely correct there is additional
overhead and for those embedded systems programmers this might be a
significant issue.

An array is by definition a contiguous block of memory. That's what
makes it fast to access. Are you suggesting that an array should
effectively be a linked list of nodes, each of which contains part of
the array?

 

[Willy Denoyette [MVP]]

| The overhead argument makes sense and as a result it makes sense that
| the ArrayList mechanism exists in addition to the standard method.
|
| But I don't think objects would have to be moved around as you have
| suggested: What could be done is just change pointers or add new ones.
| In this way new rows/elements could be added and they wouldn't have to
| be contiguous. But, you are absolutely correct there is additional
| overhead and for those embedded systems programmers this might be a
| significant issue.
|
| Thanks very much for all the responses.
|
|
|
|

Not at all, Arrays have to be contiguous, how would you apply indexing when
it wasn't the case?
Each time you extend and ArrayList the underlying array must be copied to a
new Array, what's done to reduce the overhead is to create a new array with
a size that is the double of the current array, that means that ArrayLists
grow exponentially.

Willy.

 

[Bill Butler]

Not at all, Arrays have to be contiguous, how would you apply indexing when
it wasn't the case?

Indexing makes perfectly good sense for a Linked list.
You simply need to accept that indexed access will take linear time.

Bill