Re: Boxing and Unboxing ??

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


Peter Olcott wrote:
"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
It might be possible to design a language that has essentially all of the
functionally capabilities of the lower level languages, without the
requirement
of ever directly dealing with pointers.

True, but one question I know the C# team constantly asks is whether a
feature is worth the additional complexity it adds to the language. (I
know this because they frequently cite that as a reason for not
including certain features.) What does it really buy you being able to
take the address of an arbitrary variable (in safe code... I know that
you can do it in unsafe code)? As I said, I think that Java (and now
C#) have demonstrated that it doesn't buy you much. You mentioned
boxing overhead, but in .NET 2.0 you can pretty-much avoid boxing...
all you have to do is learn a new idiom: a new way to do what you've
always done, but now in a new language.

Are you referring to Generics? Does this address this issue of passing a struct
by (address) reference?

No. "ref" and "out" address the issue of passing a struct by reference
(to a method).

Generics address the problem of writing a type that contains another,
arbitrary type that could be a value type or a reference type, without
incurring boxing overhead and while maintaining compile-time type
safety. For example, in .NET 1.1 if I wanted a "vector" of Persons, I
would write:

ArrayList personList = new ArrayList();
personList.Add(new Person("Frank"));
Person frank = (Person)personList[0];

Here, Person is a reference type (as most user-defined types are) and
so the ArrayList now contains one entry, which is a reference to a
Person that has space allocated for it on the heap. However, I've lost
(compile-time) type checking: ArrayList is a collection of Object, and
so to get Frank back I had to use a cast, which involves a run-time
type check.

If I want a "vector" of ints, I say this:

ArrayList intList = new ArrayList();
intList.Add(15);
int i = (int)intList[0];

Here, 15 is an integer value type. Since ArrayList is a collection of
Object, the value type has to be boxed onto the heap and a reference to
it placed in the ArrayList. In order to get the value back, I have to
unbox the value, the unbox operation here represented by the cast.

Generics eliminate both problems. You'll recognize the template syntax
of C++:

List<Person> personList = new List<Person>();
personList.Add(new Person("Frank"));
Person frank = personList[0];

There's no need for a cast or for a run-time type check because the
compiler already knows that every reference in the list refers to a
Person.

Similarly,

List<int> intList = new List<int>();
intList.Add(15);
int i = intList[0];

No boxing, no unboxing. The list holds native integers, not Objects.

That, in the end, is what it comes down to: C# works very well. It's
just that it does things differently than does C++, and you can't take
C++ idioms and concepts and start writing C# as though it were C++. In
a few domains, C++ is much better suited to the problems than is C#,
but in most domains C# gives you all the functionality you need while
helping keep you out of trouble.

I think that it is possible to take the concept of C# further along. To be able
to provide every required feature of a language such as C++, yet to do this in
an entirely type safe way, with essentially no additional execution time
overhead, and drastically reduce the number of details that must be handled by
the programmer. I think that C# has done an excellent job of achieving these
goals up to this point. I think that there are two opportunities for
improvement:

(1) Little tweaks here and there to eliminate more of the additional execution
time overhead.

(2) Abstract out the distinction between reference types and value types so that
the programmer will not even need to know the difference. The underlying
architecture can still have separate reference types and value types, yet, this
can be handled entirely transparently by the compiler and CLR.

How would you begin to achieve this?

I'm sorry, but I have to ask this... I don't mean to be combative or
snobby, but I'm a bit confused. It appears to me that you're trying to
get your head around C#'s version of value types, how they work, what
is boxing and unboxing and when does it happen, what are generics, and
some basic plumbing issues about how C# works. Correct me if I'm wrong,
but you seem knowledgeable about the inner workings of the machine, but
you're still trying to map what's going on in C# back to what happens
under the covers. If I can presume to sum up your questions, you're
experienced and intelligent, but some aspects of C# haven't quite
"clicked" for you yet.

And yet... you claim that C# is somehow lacking and needs improvement,
and I'm just dying to ask... based on what? I guess something just
isn't "clicking" for ME here.... I find myself very productive in C#.
There are some areas of the .NET Framework that I think could use
improvement, but the language itself works just fine for me. I find the
difference between value types and reference types very clear and
logical. I don't see where the "great rewards in increased programmer
productivity" will come from by trying to unify the two of them into...
what? A C++ type model? I'm sorry, but I found more people utterly
confounded by C++ than I have ever found confounded by Java or (now)
C#. C++ is a difficult language to master; C# by comparison is much
simpler, at least IMHO.

My problem is that I can't see where you're going with this idea. Could
you outline what's wrong with C#'s type system, how it should be
improved, and how those improvements would increase programmer
productivity?

.

Relevant Pages

  • Re: C# Nullable types
    ... of an unassigned value (for reference types) apply to 0 for int ... that the compiler assigned it to. ... With the advent of higher-level programming languages, more abstraction away ... about using human language, as the abstractions approximate human ideas. ...
    (microsoft.public.dotnet.framework)
  • Re: Boxing and Unboxing ??
    ... feature is worth the additional complexity it adds to the language. ... incurring boxing overhead and while maintaining compile-time type ... Abstract out the distinction between reference types and value types so ... the programmer will not even need to know the difference. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Boxing and Unboxing ??
    ... attention to the differences between value types and reference types. ... The act very differently: value types being... ... "improve programmer productivity". ... abstraction where programmers writing programs in this language never have any ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A VB.NET Critique
    ... You believe certain types, like strings and arrays, shouldn't be ... Should the language still ... They *aren't* reference types. ... Under your scheme, every new rectangle declaration just broke, and broke ...
    (comp.programming)
  • Re: Boxing and Unboxing ??
    ... "improve programmer productivity". ... abstraction where programmers writing programs in this language never have ... There may still be separate value types and reference types under the covers, ...
    (microsoft.public.dotnet.languages.csharp)