Is Boxing and UnBoxing Really Necessary?

[Peter Olcott]

Exactly why does C# and .NET require all the extra
copying of data?

[Bob Grommes]

Boxing / casting are part of the downside of an early-bound,
strongly-typed environment. If all types must be known at compile time,
then you end up using object or some other common ancestor to hold
instances whose type is not known at compile time, and then you either
have to live with the reduced functionality of the ancestor or cast it
to something more useful based on some runtime decision process.

By contrast in a late bound, loosely-typed environment the runtime may
not care what an object *is* so much as what it *does*. For example if
I make a call like someObject.Fuba r(), a late bound runtime may just try
to make the Fubar() call, throwing an exception only if that method
doesn't exist in someObject.

The trade off is that early binding / strong typing gives us the
benefits of type safety and (on balance anyway) better performance
because all addresses can be resolved statically at compile time rather
than dynamically at runtime.

The 2.0 version of the CLR (VS 2005) provides a mechanism called
generics that gets around some of this fuss. For example rather than
creating an ArrayList of objects to hold some variable number of ints
you can create a List<int> and the runtime will build a strongly typed
list of ints under the hood based on the template of the generic List
class. You can then get ints in and out of the collection with no
casting / boxing / unboxing, and yet the generic List<> class is
reusable for any kind of object your might desire and will work with
them all, without the need for boxing.

--Bob

Peter Olcott wrote:

Exactly why does C# and .NET require all the extra
copying of data?

[Peter Olcott]

"Bob Grommes" <bo*@bobgrommes .com> wrote in message news:O7******** *****@tk2msftng p13.phx.gbl...

Boxing / casting are part of the downside of an early-bound, strongly-typed environment. If all types must be known at compile
time, then you end up using object or some other common ancestor to hold instances whose type is not known at compile time, and
then you either have to live with the reduced functionality of the ancestor or cast it to something more useful based on some
runtime decision process.

By contrast in a late bound, loosely-typed environment the runtime may not care what an object *is* so much as what it *does*.
For example if I make a call like someObject.Fuba r(), a late bound runtime may just try to make the Fubar() call, throwing an
exception only if that method doesn't exist in someObject.
What I am talking about is that C++ can have value-types and reference-types
on both the stack and the heap. Also conversion can be made between
value-types and reference-types without the run-time overhead of copying
the whole thing.

int X = 5;
int* ptrX = &X;
int Z = *X;

I am not completely sure, but I think that the above conversions
between value-type X and Z, and reference-type ptrX, have
no run-time overhead at all. I don't see why C# can do something
like this (working with pointers) instead of requiring that all the
underlying data be copied. If this was a large struct rather than
a simple int, then the extra cost can become quite large.
The trade off is that early binding / strong typing gives us the benefits of type safety and (on balance anyway) better
performance because all addresses can be resolved statically at compile time rather than dynamically at runtime.

The 2.0 version of the CLR (VS 2005) provides a mechanism called generics that gets around some of this fuss. For example rather
than creating an ArrayList of objects to hold some variable number of ints you can create a List<int> and the runtime will build a
strongly typed list of ints under the hood based on the template of the generic List class. You can then get ints in and out of
the collection with no casting / boxing / unboxing, and yet the generic List<> class is reusable for any kind of object your might
desire and will work with them all, without the need for boxing.
Ah, now that's more like it.
--Bob

Peter Olcott wrote:

Exactly why does C# and .NET require all the extra
copying of data?

[Scott Roberts]

"Peter Olcott" <ol****@att.net > wrote in message
news:pd3Se.7432 $UI.6710@okepre ad05...

I don't see why C# can do something
like this (working with pointers) instead of requiring that all the
underlying data be copied. If this was a large struct rather than
a simple int, then the extra cost can become quite large.

Just a guess, but I'd imagine it has to do with reference counting and
garbage collection. If you have untyped pointers all over the place it
becomes very difficult (impossible?) to GC the memory. I could be wrong, but
that's my guess.

[Jeff Louie]

I can argue that C++ classes do a heck of lot more copying that C# since
C++
classes use value semantics and the copy constructor gets called
everywhere like
rabbits.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Peter Olcott]

"Jeff Louie" <je********@yah oo.com> wrote in message news:uU******** *****@tk2msftng p13.phx.gbl...

I can argue that C++ classes do a heck of lot more copying that C# since
C++
classes use value semantics
The difference is that with C++ one has the choice of using
reference semantics instead of value semantics, whenever
desired. With C# it seems that one is limited to the requirements
of the framework.
and the copy constructor gets called
everywhere like
rabbits.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Peter Olcott]

"Scott Roberts" <sc***********@ no-spam.intelebill .com> wrote in message news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

"Peter Olcott" <ol****@att.net > wrote in message
news:pd3Se.7432 $UI.6710@okepre ad05...

I don't see why C# can do something
like this (working with pointers) instead of requiring that all the
underlying data be copied. If this was a large struct rather than
a simple int, then the extra cost can become quite large.

Just a guess, but I'd imagine it has to do with reference counting and
garbage collection. If you have untyped pointers all over the place it
becomes very difficult (impossible?) to GC the memory. I could be wrong, but
that's my guess.

There is no reason why they must be untyped pointers.
The example that I provided was an int (thus typed) pointer.

[Daniel O'Connell [C# MVP]]

"Peter Olcott" <ol****@att.net > wrote in message
news:pd3Se.7432 $UI.6710@okepre ad05...

"Bob Grommes" <bo*@bobgrommes .com> wrote in message
news:O7******** *****@tk2msftng p13.phx.gbl...

Boxing / casting are part of the downside of an early-bound,
strongly-typed environment. If all types must be known at compile time,
then you end up using object or some other common ancestor to hold
instances whose type is not known at compile time, and then you either
have to live with the reduced functionality of the ancestor or cast it to
something more useful based on some runtime decision process.

By contrast in a late bound, loosely-typed environment the runtime may
not care what an object *is* so much as what it *does*. For example if I
make a call like someObject.Fuba r(), a late bound runtime may just try to
make the Fubar() call, throwing an exception only if that method doesn't
exist in someObject.

What I am talking about is that C++ can have value-types and
reference-types
on both the stack and the heap. Also conversion can be made between
value-types and reference-types without the run-time overhead of copying
the whole thing.

int X = 5;
int* ptrX = &X;
int Z = *X;

I am not completely sure, but I think that the above conversions
between value-type X and Z, and reference-type ptrX, have
no run-time overhead at all. I don't see why C# can do something
like this (working with pointers) instead of requiring that all the
underlying data be copied. If this was a large struct rather than
a simple int, then the extra cost can become quite large.

Consider this

public void Method()
{
int test = 5;
BoxedParameterM ethod(test);
}

public void BoxedParameterM ethod(object o)
{
classField = o;
}

object classField;

If you passed a pointer to test to the method BoxedParameterM ethod, the
pointer would point to test's allocation on the stack frame of the method
Method. After that method invocation returns that stack frame will cease to
exist and your program is no longer correct, classField points to random
data. The only way to circumvent this would be to allocate space and copy
test on the heap, which is basically what boxing does.

There are other reasons, as well. Boxed objects get a vtable pointer in
their header, allowing the use of interfaces. They can also be treated as
objects, you can lock on them(although its *VERY* unadvisable to do so),
compare them referentially, and in general treat them as full .NET reference
types.

With a pointer,you get none of that. You have to have access to a vtable to
work with interfaces, and since value types do not carry vtable pointers,
you'd lose access to instances in untyped scenarios. Locking is impossible
since the basic locking system relys on sync blocks in the object header.
Without converting the structure instance on the stack into a full reference
type, you lose all of this and you start making it possible to make an
"object" variable not an "object" anymore, such as in the above example.

[Daniel O'Connell [C# MVP]]

"Peter Olcott" <ol****@att.net > wrote in message
news:q78Se.7447 $UI.4519@okepre ad05...

"Scott Roberts" <sc***********@ no-spam.intelebill .com> wrote in message
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

"Peter Olcott" <ol****@att.net > wrote in message
news:pd3Se.7432 $UI.6710@okepre ad05...

I don't see why C# can do something
like this (working with pointers) instead of requiring that all the
underlying data be copied. If this was a large struct rather than
a simple int, then the extra cost can become quite large.

Just a guess, but I'd imagine it has to do with reference counting and
garbage collection. If you have untyped pointers all over the place it
becomes very difficult (impossible?) to GC the memory. I could be wrong,
but
that's my guess.

There is no reason why they must be untyped pointers.
The example that I provided was an int (thus typed) pointer.

Yes there is.

public void Method(object o);

is different semantically from

public void Method(int* o);

The first acts upon any object, be it an integer, a string, or
MyRandomFileTyp e.

int* only works on pointers to integers. Boxing isn't used to reference a
local variable's storage location, you use ref and out parameters for that,
its used to convert a value instance into an object so it can be treated as
an object.