C# 2.0 Generics and collections

  • Thread starter Thread starter Gary van der Merwe
  • Start date Start date
G

Gary van der Merwe

Hi

When C# 2.0 arrives System.Collections.Specialized.StringCollection will
become "obsolete". Will the framework still contain this class, or will
there be a C# 1.X to 2.0 conversion utility that will change
System.Collections.Specialized.StringCollection to
System.Collections.ArrayList <string> and ArrayList to ArrayList<object>
??

Gary
 
SADLY (so to say) the old non-generic collections are still there.

Which just keeps, porapbly, existing bugs around.

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
 
Hi

Are there new generic collections?

Gary

Thomas Tomiczek (MVP) said:
SADLY (so to say) the old non-generic collections are still there.

Which just keeps, porapbly, existing bugs around.

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
Click to expand...
 
SADLY (so to say) the old non-generic collections are still there.

Which just keeps, porapbly, existing bugs around.
Click to expand...

Well, I haven't noticed any bugs in StringCollection so far, and
besides they could re-implement it as a pre-created generic collection
in .NET 2.0, couldn't they?
 
What they should do is label them as obsolete in a compiler warning and then
recommend using the Generics collection.

If its in the ECMA spec its gotta be supported. (then again the spec there
isnt final yet. Can anybody submit proposals for the C# ECMA comittee?)

Why isnt VB going for ECMA, to me if its not , its propriety closed language
and wont be used here, after all they just are runing VB6 until end of life
now which is 31-Mar-2005 when VB6 = offically dead. (from
support.microsoft.com)

Until its standardized, those languages wont be used here.
 
Hi

I think the refrence to bugs was regarding the fact that the old collections
are slow because you have to continualy box objects.

Gary
 
A generic wouldn't solve the problem of the speed of boxing, would it? I
haven't read about how they are implemented, but I would think that integers
would still have to be treated a objects by the generic.
 
Keith Patrick said:
A generic wouldn't solve the problem of the speed of boxing, would it? I
haven't read about how they are implemented, but I would think that integers
would still have to be treated a objects by the generic.
Click to expand...

I don't believe so. I believe each generic class is compiled into a
type-specific class when it's first used, and that can take advantage
of anything type-specific such as size. (Note that this *isn't* the way
generics will be working in Java, AFAIK.)
 
Gary van der Merwe said:
No. Thats the whole point of them. With Generics, the type checking happens
when you complile, not at runtime.
Click to expand...

That doesn't *necessarily* get rid of boxing though. For instance, in
the Java implementation of generics, the casting will be (largely)
removed, but boxing won't be.
 
Keith Patrick said:
A generic wouldn't solve the problem of the speed of boxing, would it? I
haven't read about how they are implemented, but I would think that integers
would still have to be treated a objects by the generic.
Click to expand...

Hi Keith,

In the September MSDN, Jason Clark writes about Generics. In the
Performance paragraph he states "This is because boxing of the values is
avoided completely.", but you should read the whole paragraph for context:

http://msdn.microsoft.com/msdnmag/issues/03/09/NET/

There is also a follow-up article in the October edition that talks more
about the implementation:

http://msdn.microsoft.com/msdnmag/issues/03/10/NET/

Joe
 
Gary van der Merwe said:
What is the difference between Boxing and Casting?
Click to expand...

Boxing is what happens to make a reference-type value out of a value-
type value. For instance:

int i = 15;
object x = i;

The above creates a "boxed" int, and when you cast back to int it has
to unbox it.

When you cast between different reference types, or indeed between
different value types, there's no boxing or unboxing involved:

string s1 = "hello";
object o = s1;
string s2 = (string) o;

int i = 5;
byte b = (byte) i;
int j = b;
 
For ValueTypes, a specialized type class is created. For RefTypes, only one
is created and it's reused. This solves the boxing issue (preliminary
results tell me it's at least 5 times faster in a tight loop that woult
otherwise box and unbox).

-mike
MVP
 
StringCollection doesn't have any boxing going on, but the other
object-based ones would suffer.
-mike
MVP
 
Jon's answer is about Generics in general. The .NET implementation will
eliminate boxing (support at the IL level). The Java implementation doesn't
get around this.
-mike
MVP
 
Hi

Dose the runtime casting from object -> string not cause performence
problems?

Would this improve with the use of generics?

Gary
 
Dose the runtime casting from object -> string not cause performence
problems?
Click to expand...

No. String is a reference type, so there's no boxing/unboxing going
on, so the performance penalty will be negligible. (At least compared
to what you'd have to pay for value types!)
 
Right, storing a reftype in an object costs nothing (whereas a boxing costs
quite a bit). A downcast costs about 4 times less than a box.
-mike
MVP
 
Back
Top