Should I explicitly initialize all member variables?

[Javaman59]

I come from a background of Ada and C++ programming, where it was considered
good practice to explicitly initialize every variable.

Now that I'm programming in C# I think that it would be best NOT to
initialize class members, because every type has well defined initialization
anyway.

eg.

class C
{

int i = 0; // redundant

int j; // better?

MyClass m = null; // redundant

MyClass m; // better?
}

What's the best practice?

TIA,

Javaman

[Visually Seen #]

Javaman59,

The best thing to do is to initialize every variable.
Then, there's always a default value for every variable.
It should probably make your code 'neater' and easier to decipher, it
makes thing clear.

Sorry if this isn't what you like but,

Seen Sharp

[laimis]

I must STRONGLY disagree. You should not initialize every variable to
its default value as that adds extra overhead. The variable
initialization is moved to the default constructor if you initialize it
by declaring it like this:

class myclass
{
int i = 0;
}

c# for above would generate a constructor and inside you would see
this.i = 0;

assignment.

Waste of cycles man.
Visually Seen # wrote:

Javaman59,

The best thing to do is to initialize every variable.
Then, there's always a default value for every variable.
It should probably make your code 'neater' and easier to decipher, it
makes thing clear.

Sorry if this isn't what you like but,

Seen Sharp

[Brian Delahunty]

I would say not to initialize them as it adds extra code to the underlying
MSIL which in the end takes longer to execute.
Brian Delahunty
Ireland

http://briandela.com/blog
"Javaman59" wrote:

I come from a background of Ada and C++ programming, where it was considered
good practice to explicitly initialize every variable.

Now that I'm programming in C# I think that it would be best NOT to
initialize class members, because every type has well defined initialization
anyway.

eg.

class C
{

int i = 0; // redundant

int j; // better?

MyClass m = null; // redundant

MyClass m; // better?
}

What's the best practice?

TIA,

Javaman

[Jeff Louie]

Javamman.. The following two lines of code are NOT equivalent in C#.

MyClass m = null; // redundant

MyClass m; // better?<

The second line simply creates an unitialized variable. It does not
default to null.

http://www.geocities.com/Jeff_Louie/OOP/oop5.htm

Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Javamman.. The following two lines of code are NOT equivalent in C#.

MyClass m = null; // redundant MyClass m; // better?<

The second line simply creates an unitialized variable. It does not
default to null.

Yes it does - if it's a member variable. If it's a *local* variable it
remains uninitialised, but the subject line makes it clear that the
question is about member variables. From the spec, section 12.2 (ECMA
numbering):

<quote>
The following categories of variables are automatically initialized to
their default values:

* Static variables.
* Instance variables of class instances.
* Array elements.

The default value of a variable depends on the type of the variable and
is determined as follows:

* For a variable of a value-type, the default value is the same as
the value computed by the value-type's default constructor (11.1.1).
* For a variable of a reference-type, the default value is null.
</quote>
http://www.geocities.com/Jeff_Louie/OOP/oop5.htm

There are a couple of slight errors in that, in the Java bit:

4) Value types *don't* actually derive from anything - only the
reference type which is used for boxing the value type derives
(indirectly) from Object. It's all a bit odd, but is spelled out in the
CLI spec.

9) Java has enums now too - they're very different to C# ones though
(and far superior, IMO).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeff Louie]

>Yes it does - if it's a member variable.<

Well I'll be. I will fix that.

Regards,
Jeff

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

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike Schilling <ms*************@hotmail.com> wrote:

"Brian Delahunty" <Br************@discussions.microsoft.com> wrote in
message news:19**********************************@microsof t.com...

>I would say not to initialize them as it adds extra code to the
>underlying
> MSIL which in the end takes longer to execute.

Does the JIT generate any code when a field is initialized to its default
value? (Real question, not rhetorical; I have no idea.)

Yes, it seems to. Here's a quick pair of test programs:

using System;

public class TestWithInit
{
int a0=0, a1=0, a2=0, a3=0, a4=0, a5=0, a6=0, a7=0, a8=0, a9=0;
int b0=0, b1=0, b2=0, b3=0, b4=0, b5=0, b6=0, b7=0, b8=0, b9=0;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

and:

using System;

public class TestNoInit
{
int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9;
int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestNoInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

On both .NET 2.0 beta 2 and .NET 1.1, the version without explicit
initialisation is faster than the version with initialisation - with or
without optimisation turned on. The difference is actually reasonably
significant - but only in a test where nothing other than object
creation (and GC, obviously) occurs.

I would personally be very reluctant to change any coding habits based
on that though.

Me too (even if my habit weren't to leave such initializations off.)

But I find your results odd; it's a simple enough JIT optimization to make.

[Willy Denoyette [MVP]]

No it's not. The JIT would have to compare each value of the initializer
with the default value, this would take much more time than a simple
assignment.

Willy.

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:OM**************@tk2msftngp13.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike Schilling <ms*************@hotmail.com> wrote:

"Brian Delahunty" <Br************@discussions.microsoft.com> wrote in
message news:19**********************************@microsof t.com...
>I would say not to initialize them as it adds extra code to the
>underlying
> MSIL which in the end takes longer to execute.

Does the JIT generate any code when a field is initialized to its
default
value? (Real question, not rhetorical; I have no idea.)

Yes, it seems to. Here's a quick pair of test programs:

using System;

public class TestWithInit
{
int a0=0, a1=0, a2=0, a3=0, a4=0, a5=0, a6=0, a7=0, a8=0, a9=0;
int b0=0, b1=0, b2=0, b3=0, b4=0, b5=0, b6=0, b7=0, b8=0, b9=0;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

and:

using System;

public class TestNoInit
{
int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9;
int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestNoInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

On both .NET 2.0 beta 2 and .NET 1.1, the version without explicit
initialisation is faster than the version with initialisation - with or
without optimisation turned on. The difference is actually reasonably
significant - but only in a test where nothing other than object
creation (and GC, obviously) occurs.

I would personally be very reluctant to change any coding habits based
on that though.

Me too (even if my habit weren't to leave such initializations off.)

But I find your results odd; it's a simple enough JIT optimization to
make.

[Mike Schilling]

The JIT would have to do this comparison once, at code-generation time,
while the assignment has to be done every time the object is instantiated.
Assuming the JIT has an up-to-date optimizer built it to it, one that does
loop unrolling, common subexpression elimination, peephole optimization (and
probably lots of things invented since I last studied this stuff:-:), it's
doing much more complex transformations than this one.
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...

No it's not. The JIT would have to compare each value of the initializer
with the default value, this would take much more time than a simple
assignment.

Willy.

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:OM**************@tk2msftngp13.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike Schilling <ms*************@hotmail.com> wrote:
"Brian Delahunty" <Br************@discussions.microsoft.com> wrote in
message news:19**********************************@microsof t.com...
>I would say not to initialize them as it adds extra code to the
>underlying
> MSIL which in the end takes longer to execute.

Does the JIT generate any code when a field is initialized to its
default
value? (Real question, not rhetorical; I have no idea.)

Yes, it seems to. Here's a quick pair of test programs:

using System;

public class TestWithInit
{
int a0=0, a1=0, a2=0, a3=0, a4=0, a5=0, a6=0, a7=0, a8=0, a9=0;
int b0=0, b1=0, b2=0, b3=0, b4=0, b5=0, b6=0, b7=0, b8=0, b9=0;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

and:

using System;

public class TestNoInit
{
int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9;
int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9;

static void Main()
{
DateTime start = DateTime.Now;
for (int i=0; i < 100000000; i++)
{
new TestNoInit();
}
DateTime end = DateTime.Now;
Console.WriteLine (end-start);
}
}

On both .NET 2.0 beta 2 and .NET 1.1, the version without explicit
initialisation is faster than the version with initialisation - with or
without optimisation turned on. The difference is actually reasonably
significant - but only in a test where nothing other than object
creation (and GC, obviously) occurs.

I would personally be very reluctant to change any coding habits based
on that though.

Me too (even if my habit weren't to leave such initializations off.)

But I find your results odd; it's a simple enough JIT optimization to
make.

[Willy Denoyette [MVP]]

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

class Foo
{
string s = Bar.s;
public void M1()
{
Console.WriteLine(this.s);
}
}

class Bar
{
internal static string s;
}
class Test
{
static void Main()
{
Foo f1 = new Foo();
f1.M1();
Bar.s = "Hello";
Foo f2 = new Foo();
f2.M1();
}
}
Willy.

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

But that's not the same situation. It's one thing for an initializer to
take a value from elsewhere - that has to be done dynamically. It
wouldn't be hard for the JIT to realise that initializers were taking
*constant* values which were also the default ones, and just skip that
initialization step.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike Schilling]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:ef**************@tk2msftngp13.phx.gbl...

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

class Foo
{
string s = Bar.s;
public void M1()
{
Console.WriteLine(this.s);
}
}

class Bar
{
internal static string s;
}
class Test
{
static void Main()
{
Foo f1 = new Foo();
f1.M1();
Bar.s = "Hello";
Foo f2 = new Foo();
f2.M1();
}
}

I don't see any exaxmples there of fields explicitly being set to their
default values, e.g.

int i = 0;

or

String s = null;

*That's* what I'm thinking the JIT could eliminate the code for.

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

> The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

But that's not the same situation. It's one thing for an initializer to
take a value from elsewhere - that has to be done dynamically. It
wouldn't be hard for the JIT to realise that initializers were taking
*constant* values which were also the default ones, and just skip that
initialization step.

I'm having second thoughts now. When do statements like

int i = 0; // i is a field, not a local variable

run? For Java, I know that answer: it's after the superclass is fully
constructed, but before the current class's constructor runs. I'm not sure
about C#, though I presume the answer is similar.

Anyway, how hard is it to prove that the superclass constructor doesn't do
anything that might set a field to a non-default value? Certainly there are
cases where it's easy:

1. The class is a direct child of Object., or
2. The superclass constructor is available to the JIT (as is its superclass
constructor, etc. all the way up) and it calls no virtual methods, does not
pass "this" to any methods, (and does no reflection.

Almost anything else leaves some gap, say that a virtual function overidden
in some derived class sets the field, either by calling another virtual
function or by reflection (or by setting it directly, if it's public or
protected rather than private.)

So (as Dennis Moore said, when the poor he was giving to had become
wealthier than the rich he had taken everything from) this is more
complicated than I had thought..

[Jon Skeet [C# MVP]]

Mike Schilling <ms*************@hotmail.com> wrote:

I'm having second thoughts now. When do statements like

int i = 0; // i is a field, not a local variable

run? For Java, I know that answer: it's after the superclass is fully
constructed, but before the current class's constructor runs. I'm not sure
about C#, though I presume the answer is similar.
No, it's not quite. In C#, it occurs before the *base* constructor
runs, which makes life much simpler.

<snip>
So (as Dennis Moore said, when the poor he was giving to had become
wealthier than the rich he had taken everything from) this is more
complicated than I had thought..

Fortunately not.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

> The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

But that's not the same situation. It's one thing for an initializer to
take a value from elsewhere - that has to be done dynamically. It
wouldn't be hard for the JIT to realise that initializers were taking
*constant* values which were also the default ones, and just skip that
initialization step.

Jon, that's right, but this is the job for the language compilers - and
that's been taken care of in C# v2.0 (optimized builds!). I for one would
have prefered that C# did not allowed instance variable initializers at all
and only allowed statics to be initialized that way, just like it's been
done in managed C++.

Willy.

[Willy Denoyette [MVP]]

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eR**************@TK2MSFTNGP12.phx.gbl...

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:ef**************@tk2msftngp13.phx.gbl...

"Mike Schilling" <ms*************@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP10.phx.gbl...

The JIT would have to do this comparison once, at code-generation time,

No, it must be done whenever an instance of the class is created, as
guaranteed by the CLI, else this (somewhat contrieved but valid) sample
would fail...

class Foo
{
string s = Bar.s;
public void M1()
{
Console.WriteLine(this.s);
}
}

class Bar
{
internal static string s;
}
class Test
{
static void Main()
{
Foo f1 = new Foo();
f1.M1();
Bar.s = "Hello";
Foo f2 = new Foo();
f2.M1();
}
}

I don't see any exaxmples there of fields explicitly being set to their
default values, e.g.

int i = 0;

or

String s = null;

*That's* what I'm thinking the JIT could eliminate the code for.

Right, Not explicitly but implicitly for the first assignment where Bar.s is
null.
But as I replied to Jon, this is something that should be done by the
language compilers not by the JIT because different languages emit different
initializer constructs in IL, and you can't let them pay for what they don't
need at the JIT level.

Willy.

[Jeff Louie]

Jon... Apparently I can call int i; i.ToString() _without_ boxing. This
implies that int i is a struct that does derive from value which derives
from object. I am a bit confused here.

http://www.csharpcorner.com/Code/200...xNUnboxSSF.asp

Regards,
Jeff

Value types *don't* actually derive from anything - only the reference
type which is used for boxing the value type derives (indirectly) from
Object. It's all a bit odd, but is spelled out in the CLI spec.

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

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Jon... Apparently I can call int i; i.ToString() _without_ boxing. This
implies that int i is a struct that does derive from value which derives
from object.
No, it doesn't. It just means that ToString() is overridden in Int32,
so the compiler already knows which version to call - there's no need
to box.

If ToString weren't overridden, it would require a box. Try it with
your own value type and see.
I am a bit confused here.

http://www.csharpcorner.com/Code/200...xNUnboxSSF.asp

That page doesn't load for me, I'm afraid.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Hmm. Do you have an online reference to this part of the CLI spec. I am
begining to think this is a fine semantic argument about the meaning of
"derives from." If int32 honors the contract/interface of object, then
one could argue that it indeed does "derive" from object.

Regards,
Jeff

No, it doesn't. It just means that ToString() is overridden in Int32,
so the compiler already knows which version to call - there's no need
to box.
*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Hmm. Do you have an online reference to this part of the CLI spec. I am
begining to think this is a fine semantic argument about the meaning of
"derives from." If int32 honors the contract/interface of object, then
one could argue that it indeed does "derive" from object.

Well, one could argue it, but then one would be ignoring the
definitions of derivation etc :)

In the C# spec, section 14.4.3 (ECMA numbering) it specifies:

<quote>
# If M is an instance function member declared in a value-type:

* E is evaluated. If this evaluation causes an exception, then no
further steps are executed.
* If E is not classified as a variable, then a temporary local
variable of E's type is created and the value of E is assigned to that
variable. E is then reclassified as a reference to that temporary local
variable. The temporary variable is accessible as this within M, but
not in any other way. Thus, only when E is a true variable is it
possible for the caller to observe the changes that M makes to this.
* The argument list is evaluated as described in §14.4.1.
* M is invoked. The variable referenced by E becomes the variable
referenced by this.

# If M is an instance function member declared in a reference-type:

* E is evaluated. If this evaluation causes an exception, then no
further steps are executed.
* The argument list is evaluated as described in §14.4.1.
* If the type of E is a value-type, a boxing conversion (§11.3.1)
is performed to convert E to type object, and E is considered to be of
type object in the following steps. [Note: In this case, M could only
be a member of System.Object. end note]
</quote>

which I think is pretty much what I said - basically, you only need to
box if the method being called isn't actually declared in the value
type.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Ravichandran J.V.]

The best practice is in any case to initialize member variables in the
constructor.

There are some specific behaviors according to the type of the app. In
ASP.Net, for instance, if you initialize the variable within a class and
not within a constructor (page_init) then each time the page loads the
variable will get initialized to that value rather than the current
value. This is also due to the statelessness of the Http protocol.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

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

[Jon Skeet [C# MVP]]

Ravichandran J.V. <jv************@yahoo.com> wrote:

The best practice is in any case to initialize member variables in the
constructor.
I disagree - I tend to prefer to do it at the variable declaration if
it's going to be the same value whichever constructor is invoked.
There are some specific behaviors according to the type of the app. In
ASP.Net, for instance, if you initialize the variable within a class and
not within a constructor (page_init) then each time the page loads the
variable will get initialized to that value rather than the current
value. This is also due to the statelessness of the Http protocol.

But page_init is not the constructor for the class, as I *think* you
were implying it was. (If you weren't, please explain the middle
sentence above - it doesn't make much sense at the moment.)

Except in a few *very* unusual circumstances, leaving the values as the
default ones, explicitly setting those values in the constructor, and
explicitly setting those values in the variable declarations will all
have the same effect.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Jon... If this means M(E) I wonder if this is just saying that if M is
declared in a
reference type and is passed E that is a value type, then E will be
boxed. So
System.Console.WriteLine(valueType) valueType is boxed whereas
valueType.ToString() there is no boxing. Either way all valueTypes honor
the
ToString() method which appears to represent polymorphic behavior.

Regards,
Jeff

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

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Jon... If this means M(E) I wonder if this is just saying that if M is
declared in a reference type and is passed E that is a value type,
then E will be boxed.
No, it's not M(E). If you look at the bit of the spec I was referring
to, E is the instance expression - i.e. what the method is going to be
invoked *on*.
So System.Console.WriteLine(valueType) valueType is boxed whereas
valueType.ToString() there is no boxing. Either way all valueTypes honor
the ToString() method which appears to represent polymorphic behavior.

No, the value types themselves don't honour ToString - their boxed
equivalents do, because the boxed types derive (indirectly) from
Object.

The difference here is that C# contrives to make it look like value
types derive from Object indirectly, but the CLR doesn't - and IMO it's
important to know the difference. Indeed, the C# spec actually refers
to value types deriving from Object implicitly, which I think is part
of the problem - it's a bad way of specifying the language, as it hides
the nature of value types as far as the CLR is concerned. I wouldn't be
surprised if analysing the C# spec closely would throw up some
inconsistencies due to this.

Take, for example, section 8.2.4 (which is part of section 8 which is
only a note, admittedly) - it states: "An int value can be converted to
object and back again to int". If int actually derives from object,
there shouldn't be any conversion necessary, just as it would make no
sense to talk about converting a string to an object.

Put it this way - while the CLR explanation (with its boxed type of the
same name business) is slightly more complicated at first sight, it's a
lot simpler in the long run. You don't need to treat inheritance with
value types as different from inheritance with reference types, because
you just state that there *is* no inheritance with value types.

It's a little bit like my old bugbear of people saying that objects are
passed by reference - it's supposedly a simplification, but the hoops
you have to jump through just to avoid stating the truth aren't worth
it IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Hi Jon... This looks more like "ad-hoc" polymorphism as opposed to
"subclass"
polymorphism where the compiler may need to convert/coerce the valueType
to
a reference type and call ToString() on the reference.

Regards,
Jeff

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

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Hi Jon... This looks more like "ad-hoc" polymorphism as opposed to
"subclass"
polymorphism where the compiler may need to convert/coerce the valueType
to
a reference type and call ToString() on the reference.

Exactly. But when ToString() is actually declared in the value type as
well, rather than getting the Object (or System.ValueType)
implementation, no boxing is required.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Jon.. Thanks for your help.

Regards,
Jeff

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

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jeff Louie <je********@yahoo.com> wrote:

Hi Jon... This looks more like "ad-hoc" polymorphism as opposed to
"subclass"
polymorphism where the compiler may need to convert/coerce the valueType
to
a reference type and call ToString() on the reference.

Exactly. But when ToString() is actually declared in the value type as
well, rather than getting the Object (or System.ValueType)
implementation, no boxing is required.

Is

public String ToString() { return base.ToString();}

an optimization, or does the base call require boxing?

[Jon Skeet [C# MVP]]

Mike Schilling <ms*************@hotmail.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jeff Louie <je********@yahoo.com> wrote:

Hi Jon... This looks more like "ad-hoc" polymorphism as opposed to
"subclass"
polymorphism where the compiler may need to convert/coerce the valueType
to
a reference type and call ToString() on the reference.

Exactly. But when ToString() is actually declared in the value type as
well, rather than getting the Object (or System.ValueType)
implementation, no boxing is required.

Is

public String ToString() { return base.ToString();}

an optimization, or does the base call require boxing?

Good question. Not sure, but I suspect it involves a box. The easiest
thing would be to try it an look at the IL :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Mike Schilling]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike Schilling <ms*************@hotmail.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

> Jeff Louie <je********@yahoo.com> wrote:
>> Hi Jon... This looks more like "ad-hoc" polymorphism as opposed to
>> "subclass"
>> polymorphism where the compiler may need to convert/coerce the
>> valueType
>> to
>> a reference type and call ToString() on the reference.
>
> Exactly. But when ToString() is actually declared in the value type as
> well, rather than getting the Object (or System.ValueType)
> implementation, no boxing is required.

Is

public String ToString() { return base.ToString();}

an optimization, or does the base call require boxing?

Good question. Not sure, but I suspect it involves a box. The easiest
thing would be to try it an look at the IL :)

You asked for it: :-)

public struct HasOverride {
public int i;

public override String ToString() {
return base.ToString();
}
}

results in:

..method public hidebysig virtual instance string
ToString() cil managed
{
// Code size 21 (0x15)
.maxstack 1
.locals init ([0] string CS$00000003$00000000)
IL_0000: ldarg.0
IL_0001: ldobj HasOverride
IL_0006: box HasOverride
IL_000b: call instance string
[mscorlib]System.ValueType::ToString()
IL_0010: stloc.0
IL_0011: br.s IL_0013
IL_0013: ldloc.0
IL_0014: ret
} // end of method HasOverride::ToString

So your suspicion is correct.