Count vs Length

  • Thread starter Thread starter Mark Mullin
  • Start date Start date
M

Mark Mullin

I'd be curious about peoples observations on the (implicit) design
principle that causes dynamic collections to be sized via .Count and
fixed collections to be sized via .Length.

Yes, I know of history of .Count, but just because its been around
doesn't mean it should stay around.

Sometimes I find the distinction useful, otoh, its never the _only_
thing letting me know if my collection is fixed size or not.

In general, I'd lean to unifying them so there was a single abstract
method that sized any collection, but I might well be missing
something.

Anybody got any comments on the positives or negatives ?

mmm
 
In general, I'd lean to unifying them so there was a single abstract
method that sized any collection, but I might well be missing
something.
Click to expand...

ICollection.Count provides the single abstract method, and is the most
general way to determine the number of elements in a collection. Array
provides an explicit interface implementation of ICollection, so you can
always write code in terms of ICollection if a unified "size" property was
required. The Count on an array always returns the length, but its painful
to use when you have an array reference because of the cast required (see
sample at end of response).

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org

int[] arr = new int[10];

//int size = arr.Count; - doesn't work

int size = ((System.Collections.ICollection)arr).Count;
 
I'm not asking how to use Count and Length, I'm asking a question
about design in general.

I do see your casting example shows how to use count in all cases,
but what's the real cost? If it's execution speed, then maybe we're
at - count is global and slow, length is used to identify sizing of
only fixed size internal storage. If the execution speed of your
casted count is roughly comparable to length, then maybe it would be
possible to alias length to this (that would of course require c#
support macros)

Reiterating, Count is a value thats been around for a while, and since
even com interfaces use it, its hard to change. Length is something
I've first encountered often in C#. The distinction seems
articificial if you discount the history of count, and I wonder why
its neccessary.

mmm

Nick Wienholt said:
In general, I'd lean to unifying them so there was a single abstract
method that sized any collection, but I might well be missing
something.
Click to expand...

ICollection.Count provides the single abstract method, and is the most
general way to determine the number of elements in a collection. Array
provides an explicit interface implementation of ICollection, so you can
always write code in terms of ICollection if a unified "size" property was
required. The Count on an array always returns the length, but its painful
to use when you have an array reference because of the cast required (see
sample at end of response).

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org

int[] arr = new int[10];

//int size = arr.Count; - doesn't work

int size = ((System.Collections.ICollection)arr).Count;
Click to expand...
 
Back
Top