declaring array dimension and type at runtime
-
I am writing a program that requires array types and dimensions be decided at runtime. I can use System.Array.CreateInstance() to do this. What is the most efficient way to access the data in this array? I know I can use the getValue and setValue methods. I can also use the enumerable interface when allowed by the situation. Both of these are however inconvenient when compared to indexing the values using []. Does anyone have any suggestions. Efficiency of the code is a major consideration. Thanks, Karl
-
I am writing a program that requires array types and dimensions be decided at runtime. I can use System.Array.CreateInstance() to do this. What is the most efficient way to access the data in this array? I know I can use the getValue and setValue methods. I can also use the enumerable interface when allowed by the situation. Both of these are however inconvenient when compared to indexing the values using []. Does anyone have any suggestions. Efficiency of the code is a major consideration. Thanks, Karl
If you expect the modify the array while enumerating you cannot use
IEnumerable
. It will throw an exception if the underlying enumerable changes. Why not just use anArrayList
? It has the same read performance as an array because it uses an array internally. It's only when you add elements past the current capacity that there is overhead since a new array is created (doubling in size) and previous elements are copied. Dynamic code is often an inconvenience, but there's not much you can do short of wrapping such behavior (which, once again,ArrayList
already does for you - just examine the IL for yourself or use a decompiler like .NET Reflector). Ever written native code to access automation (IDispatch
implementations) servers? It's a pain compared to automation clients like VB6 and script, but that's the price to pay for late-binding code. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
If you expect the modify the array while enumerating you cannot use
IEnumerable
. It will throw an exception if the underlying enumerable changes. Why not just use anArrayList
? It has the same read performance as an array because it uses an array internally. It's only when you add elements past the current capacity that there is overhead since a new array is created (doubling in size) and previous elements are copied. Dynamic code is often an inconvenience, but there's not much you can do short of wrapping such behavior (which, once again,ArrayList
already does for you - just examine the IL for yourself or use a decompiler like .NET Reflector). Ever written native code to access automation (IDispatch
implementations) servers? It's a pain compared to automation clients like VB6 and script, but that's the price to pay for late-binding code. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]Thanks for your response. As I understand the ArrayList and all other collections provide lists of objects. My arrays will contain standard types such as byte, int, float... As a result if I use a collection there will be a large performance hit (boxing,unboxing,longer value retreval times). Thanks Karl Baum
-
Thanks for your response. As I understand the ArrayList and all other collections provide lists of objects. My arrays will contain standard types such as byte, int, float... As a result if I use a collection there will be a large performance hit (boxing,unboxing,longer value retreval times). Thanks Karl Baum
An array is an
IList
implementation, which inherits fromICollection
which inherits fromIEnumerable
. As I said - and as you can see in the IL module whereArrayList
is defined - theArrayList
(and, hence, any collections that use an internalArrayList
) - do use arrays that are doubled in capacity before that capacity is exceeded. There will only be a performance hit if you collect value types (like primatives, not "standard" types). Boxing and unboxing only describes the process that the CLR performs when treating a value type as an object and back again, respectively. In .NET 2.0, of course, you could simply useList<>
to declare a generic list for whatever type, reference or value types. If performance is a problem now and you can't or don't want to use .NET 2.0 (granted, it's still in beta 1 but beta 2 is due out shortly) than you'll need to use what you're doing now to create arrays. Again, though, I urge that you wrap such functionality in a class. Later you can derive that class fromList<>
and remove your implementation. Now you won't have to change your calling code. Just make sure to use the same signatures asList<>
, which you can find at http://msdn2.microsoft.com/library/6sh2ey19.aspx[^] (the new namespace extension to MSDN2 doesn't appear to be functioning just yet for generics, so I can't give you the simple change-tolerant link). Basically, you'd just implement your ownArrayList
-like class. It's really not hard. If you know IL, use ildasm.exe that ships with the SDK (that's installed by default with VS.NET) or use a decompiler like .NET Reflector to see howArrayList
operates if you can't figure it out based on the documentation. You're already part way there with what you're doing. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
An array is an
IList
implementation, which inherits fromICollection
which inherits fromIEnumerable
. As I said - and as you can see in the IL module whereArrayList
is defined - theArrayList
(and, hence, any collections that use an internalArrayList
) - do use arrays that are doubled in capacity before that capacity is exceeded. There will only be a performance hit if you collect value types (like primatives, not "standard" types). Boxing and unboxing only describes the process that the CLR performs when treating a value type as an object and back again, respectively. In .NET 2.0, of course, you could simply useList<>
to declare a generic list for whatever type, reference or value types. If performance is a problem now and you can't or don't want to use .NET 2.0 (granted, it's still in beta 1 but beta 2 is due out shortly) than you'll need to use what you're doing now to create arrays. Again, though, I urge that you wrap such functionality in a class. Later you can derive that class fromList<>
and remove your implementation. Now you won't have to change your calling code. Just make sure to use the same signatures asList<>
, which you can find at http://msdn2.microsoft.com/library/6sh2ey19.aspx[^] (the new namespace extension to MSDN2 doesn't appear to be functioning just yet for generics, so I can't give you the simple change-tolerant link). Basically, you'd just implement your ownArrayList
-like class. It's really not hard. If you know IL, use ildasm.exe that ships with the SDK (that's installed by default with VS.NET) or use a decompiler like .NET Reflector to see howArrayList
operates if you can't figure it out based on the documentation. You're already part way there with what you're doing. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]Thank you for your response, I understand how all of this works, and was just wondering if c# contained anything I wasn't aware of. It appears I will have to continue doing it as I have been. ArrayLists and the other collections are simply not appropriate for what I am trying to do. The functionality they provide come with too much of a performance hit. The implementation of ArrayList is significantly different from what I am trying to do. ArrayList's power and weakness come from it being a list of references, and hence you can stick anything in there, at the expense of following the references. What I am looking for is a standard array (one continuous chunk of memory, with only one reference to the array itself). Thanks for your help and suggestions. Particularly your suggestion for easier transition over to the new capabilities that will be provided by 2.0. Karl Baum