Can I resize an array?

[Maxwell2006]

Hi,

I declared an array like this:

string[] scriptArgs = new string[10];

Can I resize the array later in the code?

Thank you,
Max

 

[the.duckman]

No.

Use Systems.Collections.ArrayList instead.
Then read a good C# book.

-dm

 

[Guest]

Although ArrayList may be preferable in some cases, you don't need to choose
it just because you want to resize easily. Arrays are also easily resized.

With C# 2.0 simply use Array.Resize (for one-dimensional arrays).

Prior to 2.0, use the method described here
http://www.tangiblesoftwaresolutions.com/Articles/CSharp Equivalent to VB ReDim Preserve.htm
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

 

[the.duckman]

Maxwell,
please keep in mind that
generaly resizing a fixed array is a process that is cpu coslty (Im not
to sure about c# 2.0).

It generaly involves making a new array then copy everything from the
old array into it, though this is greatly oversimplfing what actuly
happens.

An Arraylist is more effecient for arrays that will undergo resizing
operations on a regular basis. That is why it was provided.

-dm

 

[Jon Skeet [C# MVP]]

Although ArrayList may be preferable in some cases, you don't need to choose
it just because you want to resize easily. Arrays are also easily resized.

With C# 2.0 simply use Array.Resize (for one-dimensional arrays).

You need to be careful here. Arrays can't be resized in the same way
that Strings can't be changed. Array.Resize doesn't *actually* resize
the array any more than String.Replace replaces occurrences in the
string it's called on. Instead, Array.Resize returns a *new* array of
the desired size, with the elements from the original array copied into
it. Now, if you've only got one reference to the array, that's fine -
but if you've got two variables which refer to the original array,
calling Array.Resize will have no effect as far as the "extra" variable
is concerned. Here's an example:

using System;

class Test
{
static void Main()
{
string[] x = {"hello", "there"};
string[] y = x;

Array.Resize(ref x, 3);

Console.WriteLine (x.Length);
Console.WriteLine (y.Length);
}
}

(I'm sure you knew all this David - I just wanted to be clear for the
OP.)

 

[Guest]

Good point Jon - it's something you definitely need to be aware of.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

Although ArrayList may be preferable in some cases, you don't need to choose
it just because you want to resize easily. Arrays are also easily resized.

With C# 2.0 simply use Array.Resize (for one-dimensional arrays).

You need to be careful here. Arrays can't be resized in the same way
that Strings can't be changed. Array.Resize doesn't *actually* resize
the array any more than String.Replace replaces occurrences in the
string it's called on. Instead, Array.Resize returns a *new* array of
the desired size, with the elements from the original array copied into
it. Now, if you've only got one reference to the array, that's fine -
but if you've got two variables which refer to the original array,
calling Array.Resize will have no effect as far as the "extra" variable
is concerned. Here's an example:

using System;

class Test
{
static void Main()
{
string[] x = {"hello", "there"};
string[] y = x;

Array.Resize(ref x, 3);

Console.WriteLine (x.Length);
Console.WriteLine (y.Length);
}
}

(I'm sure you knew all this David - I just wanted to be clear for the
OP.)

 

[Guest]

Yes - the performance difference does become noticable at a certain point.
In some tests just now, the array resize becomes noticably slower at around
a few thousand resizes, varying depending on the size of the array (larger
arrays result in more expensive resizing).

If using an array doesn't provide any benefit to you over an ArrayList, then
this would be good reason to use ArrayList over an array.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C# to C++ converter & VB to C++ converter
Instant J#: VB to J# converter

 

[Guest]

In addition ususally, ArrayList are more appropriate when you are storing
reference types. If you are storing value types (int, float, bool,
structures, etc.), then it is more appropriate to use arrays.

ArrayList stores elements as System.Object. If you add value types to an
ArrayList, boxing occurs to box the value type into a reference type
(System.Object). When you access elements of an ArrayList, unboxing occurs
to unbox the reference type, back into a value type. The boxing/unboxing
process is costly. A simple test can show that storing value types in an
array is more efficient than in an ArrayList. If you are storing Reference
types, then it is more efficient to store it an ArrayList rather than an
array. ArrayList are not always to best choice.

 

[Bruce Wood]

ArrayList stores elements as System.Object. If you add value types to an

ArrayList, boxing occurs to box the value type into a reference type
(System.Object). When you access elements of an ArrayList, unboxing occurs
to unbox the reference type, back into a value type. The boxing/unboxing
process is costly.

In .NET 1.1, (almost) all collection structures store Objects, and so
they box and unbox value types accordingly. In .NET 2.0, there is
List<T>, which stores value types natively and so performs no boxing or
unboxing if it is created for a value type.

Even in .NET 1.1, though, boxing and unboxing are rarely so noticeable
that it's worth warping your design if an ArrayList was the "right
choice" from a design standpoint. Always choose the most appropriate
data structure for your design and then profile your app to see if
things like boxing cause you a real performance problem. Adapt your
design only if this is so. Otherwise you get tortured code in the name
of "efficiency" in spots where if you did it the nice (but
"inefficient") way it would have almost no effect on your program
whatsoever.

[Resizing an array] generally involves making a new array then copy everything from the old array into it.

So far as I know (and I'm often wrong) this is exactly what happens
with an ArrayList. ArrayList uses an array as its backing
implementation, so when you fill your ArrayList it simply allocates
another array and copies the contents from one to the other. I believe
that the size of the backing array doubles on each reallocation.

Of course, I could be completely out to lunch. Anyone know if this is
so?

 

[Guest]

In .NET 1.1, (almost) all collection structures store Objects, and so
they box and unbox value types accordingly. In .NET 2.0, there is
List<T>, which stores value types natively and so performs no boxing or
unboxing if it is created for a value type.

Even in .NET 1.1, though, boxing and unboxing are rarely so noticeable
that it's worth warping your design if an ArrayList was the "right
choice" from a design standpoint. Always choose the most appropriate
data structure for your design and then profile your app to see if
things like boxing cause you a real performance problem. Adapt your
design only if this is so. Otherwise you get tortured code in the name
of "efficiency" in spots where if you did it the nice (but
"inefficient") way it would have almost no effect on your program
whatsoever.

I disagree about the performance hit of boxing/unboxing. For a small amount
of elements, there is a performance differents, but it is so small it is not
noticable. However, when you get into the thousands, and larger,
boxing/unboxing is noticable. I redesigned an application that stored pixel
values of a camera in an ArrayList (.NET 1.1) of floats. The number of
varies from (320*240, 640*480, and 1024 * 1024). Performing calculations on
these pixel values stored in an ArrayList took many seconds, and sometimes
minutes. I converted the ArrayLists to arrays of floats and the calculations
now only take a couple of seconds.

It really depends on the application. If you iterate through the array
once, the it doesn't make a difference. However, you have to access the
elements many times and interate through the arrays multiple times, then you
do notice a difference.

[Resizing an array] generally involves making a new array then copy everything from the old array into it.

So far as I know (and I'm often wrong) this is exactly what happens
with an ArrayList. ArrayList uses an array as its backing
implementation, so when you fill your ArrayList it simply allocates
another array and copies the contents from one to the other. I believe
that the size of the backing array doubles on each reallocation.

Of course, I could be completely out to lunch. Anyone know if this is
so?

 

[Bruce Wood]

I redesigned an application that stored pixel

values of a camera in an ArrayList (.NET 1.1) of floats. The number of
varies from (320*240, 640*480, and 1024 * 1024). Performing calculations on
these pixel values stored in an ArrayList took many seconds, and sometimes
minutes. I converted the ArrayLists to arrays of floats and the calculations
now only take a couple of seconds.

Yes, but that's exactly my point. You had a slow application, you
determined where the slowdown was, and you optimized that section. My
point is that one shouldn't "optimize" before determining that there is
indeed a problem. In most cases, there won't be. In a few, such as
yours, there will be, and in those cases a change in data structure is
a good idea.

Too many programmers read that "boxing and unboxing are slow" and then
do horrible, tortured things to their code in order to avoid boxing and
unboxing at all costs, when in fact that's unnecessary in most cases.
It's far better to write the code using the data structure that makes
sense given the design, then profile the application, then make
adjustments where necessary, which is just what you did.

The only mistake that the original author of your application made was
that he or she didn't profile it to see if there was a problem area in
the code.

 

[Jon Skeet [C# MVP]]

I disagree about the performance hit of boxing/unboxing. For a small amount
of elements, there is a performance differents, but it is so small it is not
noticable. However, when you get into the thousands, and larger,
boxing/unboxing is noticable. I redesigned an application that stored pixel
values of a camera in an ArrayList (.NET 1.1) of floats. The number of
varies from (320*240, 640*480, and 1024 * 1024). Performing calculations on
these pixel values stored in an ArrayList took many seconds, and sometimes
minutes. I converted the ArrayLists to arrays of floats and the calculations
now only take a couple of seconds.

It really depends on the application. If you iterate through the array
once, the it doesn't make a difference. However, you have to access the
elements many times and interate through the arrays multiple times, then you
do notice a difference.

That's exactly what Bruce said though: write the code in the most
natural, readable way, then if there are performance problems, change
your app (after profiling) to fix those problems.

For "many times" and "multiple times" to actually make a significant
difference, you're likely to have to access millions of items (or the
same few items millions of times).

Even within the same app, there may be times where it's most
appropriate to use an ArrayList and times where an array would be
better. I totally agree with Bruce though - write the code to be
readable first, and worry about micro-optimisation later.

(One particular feature of your app sounds like you knew at runtime
what the size of the array would be before populating, so there
wouldn't be any need for resizing. When you know the size to start
with, an array usually ends up being easier to work with than an
ArrayList anyway.)

 

[Jon Skeet [C# MVP]]

So far as I know (and I'm often wrong) this is exactly what happens
with an ArrayList. ArrayList uses an array as its backing
implementation, so when you fill your ArrayList it simply allocates
another array and copies the contents from one to the other. I believe
that the size of the backing array doubles on each reallocation.

Of course, I could be completely out to lunch. Anyone know if this is
so?

Spot on.