By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,054 Members | 902 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,054 IT Pros & Developers. It's quick & easy.

Can I resize an array?

P: n/a
Hi,

I declared an array like this:

string[] scriptArgs = new string[10];

Can I resize the array later in the code?

Thank you,
Max
Apr 12 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
No.

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

-dm

Apr 12 '06 #2

P: n/a
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...20Preserve.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

"Maxwell2006" wrote:
Hi,

I declared an array like this:

string[] scriptArgs = new string[10];

Can I resize the array later in the code?

Thank you,
Max

Apr 12 '06 #3

P: n/a
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

Apr 12 '06 #4

P: n/a
David Anton <Da********@discussions.microsoft.com> wrote:
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.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 12 '06 #5

P: n/a
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

"Jon Skeet [C# MVP]" wrote:
David Anton <Da********@discussions.microsoft.com> wrote:
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.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Apr 12 '06 #6

P: n/a
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

"th*********@gmail.com" wrote:
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

Apr 12 '06 #7

P: n/a
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.

"th*********@gmail.com" wrote:
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

Apr 13 '06 #8

P: n/a
> 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?

Apr 13 '06 #9

P: n/a


"Bruce Wood" wrote:
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.


Yes, List<T> is strongly typed based on what you give it. It is the
perfered way in .NET 2.0.
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?

Apr 13 '06 #10

P: n/a
> 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.

Apr 13 '06 #11

P: n/a
rmacias <rm*****@newsgroup.nospam> wrote:
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.


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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 13 '06 #12

P: n/a
Bruce Wood <br*******@canada.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Apr 13 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.