Re: Some questions about .NET Framework design decisions
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 04/04/04
- Next message: Mike: "Re: .NET Framework 2.0 in Visual Studio 2003 ??"
- Previous message: Pieter Philippaerts: "Re: Some questions about .NET Framework design decisions"
- In reply to: SpookyET: "Some questions about .NET Framework design decisions"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 4 Apr 2004 13:08:37 -0500
"SpookyET" <not4_u@hotmail.com> wrote in message
news:opr5xz4j0n1s9n15@saturn...
> 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.
>
> 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.
- Next message: Mike: "Re: .NET Framework 2.0 in Visual Studio 2003 ??"
- Previous message: Pieter Philippaerts: "Re: Some questions about .NET Framework design decisions"
- In reply to: SpookyET: "Some questions about .NET Framework design decisions"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|