Some questions about .NET Framework design decisions

[SpookyET]

I've been wondering about some of the decisions that were made about the
..net framework:

- Why are arrays not dynamic, where you can decrease/increase the size of
the array without creating a new one, then copy the values from the old
one into the new one, and destroying the old one, which is what ArrayList
does. This will kill the need for a Linked-List (which currently is not
in the System.Collections name-space). Sometimes you may care more about
the amount of memory used than the speed of allocating a new node in the
list. Also, a linked list does not have the problem of array
fragmentation, which happens when you remove items from the middle of the
array.

- Why are strings immutable? Why not have String and StringBuilder united
in one class under the name String?

- Why weren't generics available in the v1.0 of the framework? It is very
annoying to have to create your own collections because you don't want to
slow your application down because of type casting to and from object.
When you want a collection that accepts any type, it makes sense to use
the base class of all objects, but most of the time you want a collection
of only one type of objects. You have CollectionBase for strongly typed
collections, but that still is using casting to and from object.

That is it for now. I've been using C# since 2002, yet I have had this
questions on the back of me mind for a long time.

 

[Pieter Philippaerts]

- Why are arrays not dynamic, where you can decrease/increase the size of
the array without creating a new one, then copy the values from the old
one into the new one, and destroying the old one

Because we have the ArrayList for that.

This will kill the need for a Linked-List (which currently is not
in the System.Collections name-space).

Sure it is; look for the Queue class.

- Why are strings immutable?

Thread safety.

Regards,
Pieter Philippaerts

 

[Daniel O'Connell [C# MVP]]

I've been wondering about some of the decisions that were made about the
.net framework:

- Why are arrays not dynamic, where you can decrease/increase the size of
the array without creating a new one, then copy the values from the old
one into the new one, and destroying the old one, which is what ArrayList
does. This will kill the need for a Linked-List (which currently is not
in the System.Collections name-space). Sometimes you may care more about
the amount of memory used than the speed of allocating a new node in the
list. Also, a linked list does not have the problem of array
fragmentation, which happens when you remove items from the middle of the
array.

I am confused about what you are wantng here. Half of this you are
discussing dynamic arrays and the other half LinkedLists

Dynamic arrays are a language feature that basically hides the operation you
are describing here. An array is just a block of memory which can be
accessed easily via an index. There is no way for an array to grow and
shrink without allocating another array and performing a memory copy because
there is no way for computer memory to simply insert a new slot(without
resorting to page sized slots and funky memory management).

Linked lists on the other hand are useful when you are doing alot of inserts
and deletes, but the lookup time is abysmal when compared to an array.
Changing arrays to linked lists as a whole would be a terrible performance
killer.

- Why are strings immutable? Why not have String and StringBuilder united
in one class under the name String?

I need to look up some stuff to address this in full, but even if string was
immutable, StringBuilder would still need to exist for performance reasons.
A string is made up of an unmanaged character array\pointer, effectivly.
Because as you point out above arrays and pointers are not dynamic(and
considering the caveats I illustrated), the performance of a string class
that was merged with StringBuilder would either plummet or a String would
often take up considerably more space than it actually uses. An insert on an
array or char pointer requires atleats two memcpys(move the second part of
the string and then copy the new value in) and potential a reallocation and
three memcpys(copy the first part, then the new value, then the second part
to the new buffer). Whereas a StringBuilder could avoid doing all of this
until the modifications are done and ToString() is called(In theory, I don't
know how StringBuilder behaves in this regard).

- Why weren't generics available in the v1.0 of the framework? It is very
annoying to have to create your own collections because you don't want to
slow your application down because of type casting to and from object.
When you want a collection that accepts any type, it makes sense to use
the base class of all objects, but most of the time you want a collection
of only one type of objects. You have CollectionBase for strongly typed
collections, but that still is using casting to and from object.

There just wasn't enough time to get it working.