Re: Array vs List<>

Indexable content is interesting, something I'm not totally decided about:

On the one it is the main reason why I don't tend to use IEnumerable<T> - I've had too many experiences where I've started using it, and then had to backtrack because I've subsequently found I needed indexed access (I think the most common reasons are that (a) I need to set up a parallel array with some related data about each element of the original array, and so need the index to map between the arrays, or (b) I need the index purely for debugging - so that if an error occurs while working through the list, I can instantly tell which element of the list is causing the error);  

OTOH I increasingly find that when I'm using indexed access, it's with a slightly odd taste - a feeling that there ought to be a better way of doing this without using this data item (the index) that is largely irrelevent to the logic of what I'm doing, but which I'm dealing with for bookkeeping reasons - but I can't quite figure what the better way would be, and whatever it is, it likely isn't supported by the C# language anyway :) 

Simon

On Sat, 1 Nov 2008 13:44:23 -0400, Sébastien Lorion <[email protected]> wrote:

>If you dont wrap it with a read-only container, someone could cast it to
>IList<T> and modify the elements. Also, it's nice to have indexable content
>when possible.
>
>Sébastien
>On Sat, Nov 1, 2008 at 12:11 PM, Richard Blewett <[email protected]>wrote:
>
>> Why not just expose it as an IEnumerable<T> that saves the copy and keeps
>> the list ( but not it's members) immutable
>>
>> Rich
>>
>> Sent from my iPhone
>>
>> On 1 Nov 2008, at 13:00, Simon Robinson <[email protected]> wrote:
>>
>>  Very minor issue that occurred to me.
>>>
>>> The project I'm working on seems to have quite a few lists of objects,
>>> where each list is read in from a file when the application starts, and is
>>> subsequently guaranteed never to change; the data will be accessed
>>> constantly but neither the list nor the values of the objects in it will
>>> ever be modified.
>>>
>>> Because I don't know how many elements are going to be in the list until
>>> I've read them in, I tend to read them into a List<>, so I can dynamically
>>> expand it as I'm reading the elements in. However, because the list is then
>>> unchanged, there's no reason for it to be a dynamically expandable list. If
>>> it wasn't for the initialization process I'd just store them in a
>>> fixed-length array.
>>>
>>> So I'm curious, what are people's thoughts on keeping the data permanently
>>> in a list<>, or discarding the list<> and copying to an array as soon as the
>>> data is read in? An array entails the extra copy operation, but may lead to
>>> slightly clearer code. I'm guessing for subsequent read access, there's no
>>> performance difference. Any other factors I've missed?
>>>
>>> I realise this is most likely a pretty academic point that would have very
>>> little impact on the app either way, but I was curious...
>>>
>>> ===================================
>>> View archives and manage your subscription(s) at
>>> http://peach.ease.lsoft.com/archives
>>>
>>
>> ===================================
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>
>===================================
>View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives