Re: Generics + D2007/win32

"Jim Cooper" <jcooper@xxxxxxxxxxxxx> a écrit dans le message de news:
447fca4a$1@xxxxxxxxxxxxxxxxxxxxxxxxx

| > From TObject? <g>
|
| In fact, yes. They do not need to subclass from anything.

Jim, this is not a reply to your post but this is a convenient place to hang
my suggestion for Bryce's consideration.

Using TCollection, involves casting the TCollectionItem to/from a pointer in
order to store/retrieve items from the list. Now, whereas in Delphi for
Win32, this is a relatively inexpensive operation, in .NET, you have to
consider the type with which you are doing this.

..NET non-generic containers like ArrayList are based on storing *anything*
in a System.Object reference.

Unlike Delphi, types like integer, double, DateTime, etc all derive from
System.ValueType.

If you try the following :

{
int i = 123;
object o = i;
int j = (int) o;
}

The first assignment of i to o does something called boxing. This means that
an Int32 object is created and the int value is placed inside it; it is not
the simple cast it appears to be.

Neither is the second assignment just a simple explicit cast required to get
the "untyped" object o back to an int; in this case the "cast" has to
extract the value from the Int32 object o in order to get it into the int
variable j.

This boxing is not relevant to anything other than value types, so any so
called reference type like our own classes, are not boxed, but structs
(records) *are* value types and incur the same penalty.

Now if you use the .NET ArrayList, which is the nearest equivalent to TList,
as an internal store in a typesafe wrapper class, every time you add/access
items, you incur these boxing penalties.

Now, if you look at the List<T> class, you get an entirely different
scenario.

List<T> is written so that when I instantiate a "bound" instance, what I am
getting is a true list of the type to which it is bound.

So :

{
List<int> intList = new List<int>();

intList.Add(123);

...
}

This snippet creates a true list of ints, the items of which are *really*
ints, not just objects; therefore adding/accessing the items doesn't incur
any boxing/conversion penalties.

This is one of the major advantages of using generics in .NET 2.0 -
performance and efficiency in typesafe collections which where previously
notoriously slow due to boxing.

The MSDN article quoted elsewhere in this thread is a good introduction and
shows how to use generics other than for collections.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer


.

Relevant Pages

  • Re: Value Types and Reference Types
    ... So your saying that an int is not special? ... What I mean is that the compiler ... Boxing definitely creates an object on the heap. ... Int32 x; are pretty much identical except for speed/memory issues. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Value Types and Reference Types
    ... So your saying that an int is not special? ... What I mean is that the compiler ... but the main point was that boxing is slow. ... Actually a boxing operation takes 11 machine instruction, 10 instruction to allocate the object space on the heap and 1 instruction to move the value into the object. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Boxing
    ... primitive data types like int) ... unboxing is to convert the boxed struct back to its original form: ... boxing and unboxing is a relatively expensive operation and should be ...
    (microsoft.public.dotnet.general)
  • RE: Basic types: objects or not?
    ... Primitive types in .Net such as int, float etc are aliases for system objects ... means that "a" is an alias for a memory location which is a 32 bit space ... The final piece of the puzzle is boxing/unboxing, ... > I read that in C# all are objects including basic types, ...
    (microsoft.public.dotnet.languages.csharp)