Re: Subclassing value type

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

From: cody (deutronium_at_gmx.de)
Date: 01/05/05 

Date: Wed, 5 Jan 2005 12:55:29 +0100

IIRC only if you call methods that you don't have overridden then the value
is passed as boxed object. If you implement a method in your struct or
override a existing one no boxing occures, instead a reference to the struct
is passed on the stack.

struct A
{
int a;
public string override ToString(){ return a.ToString(); }
public void Foo(){}
}

A a = new A();
a.ToString(); // no boxing
a.Foo(); // no boxing
a.GetHashCode(); // only that last call will pass a boxed object

"Don Caton" <support@shorelinesoftware.com> schrieb im Newsbeitrag
news:OKOyS1n8EHA.936@TK2MSFTNGP12.phx.gbl...
> "Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
> news:skeet@pobox.com:
> > benben <benhongh@yahoo.com.au> wrote:
> > > Just for curiosity: if value types behave so differently from
> > > reference
> > > types, and if value types are hardly a reference type why all the CLR
> > > value
> > > types are derived indirectly from System.Object which is a reference
> > > type?
> >
> > They're not, actually. Only the boxed type *actually* inherits from
> > System.Object. If you look at the CLR spec, it's all a bit odd, really.
> >
>
> Jon:
>
> Yes it is a bit odd, and I guess this is where the confusion arose (at
> least for me). Normally when you call an instance method, you push the
> object reference on the stack and then do a call or callvirt. This
> object reference of course, becomes the implicit "this" reference within
> the instance method.
>
> But when you call a method on a value type, you push the value type
> itself before doing the call and the VES automagically converts this
> into a reference by boxing it, which creates a real object, with real
> inheritance (from System.Object). So from the point of view of a value
> type's method, a value type is a true object. And therefore, it seemed
> reasonable that if a value type itself is a subclassed type, that you
> should also be able to subclass from it (if it wasn't sealed).
>
> No doubt the benefit of treating value types as objects outweighs the
> seeming contradiction in behavior; you really have to understand the
> underlying implementation in order for it to make sense though. At
> least for someone coming from C++; I guess it isn't an issue in higher
> level languages like C# or VB where you generally aren't even aware of
> the concept of boxing.
>
> It's all explained in the standard, but it's scattered all over the
> place and I probably shouldn't be reading it at 3am anyhow.
>
> --
> Don Caton
> Shoreline Software, Inc.
>

Relevant Pages

  • Difference between boxing a primitive type and boxing a custom str
    ... I noticed some difference between boxing primitive type and boxing custom ... struct MyStruct ...
    (microsoft.public.dotnet.framework)
  • Boxing effect on struct methods
    ... Couple of questions relating to boxing. ... the heap so that the system can treat a value type like a reference type. ... If I add custom instance method on a struct, will it box that type each ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Boxing effect on struct methods
    ... > Couple of questions relating to boxing. ... > the heap so that the system can treat a value type like a reference type. ... If I add custom instance method on a struct, will it box that type each ...
    (microsoft.public.dotnet.languages.csharp)
  • Boxing questions relating to struct methods
    ... Couple of questions relating to boxing. ... the heap so that the system can treat a value type like a reference type. ... If I add custom instance method on a struct, will it box that type each ...
    (microsoft.public.dotnet.framework)
  • Re: inheritance
    ... I did know that Int32 is a struct, ... GetHashCode or ToString would result in a boxing operation, ... The assumption I made was that they override the System.Object ...
    (microsoft.public.dotnet.general)