Philisophical question

Gary Wheeler

There are two ways to initialize members in a C# class, via constructor:

class MyClass
{
private int Member;
public MyClass()
{
Member = 0;
}
}

or through member initialization:

class MyClass
{
private int Member = 0;
}

My question: Are there problems / benefits of one approach vs. another? From what I can see, it's a wash if you only have a default constructor. If you have multiple constructors, member initialization is preferable for those members that are set to the same value by all constructors.

Software Zen: delete this;

Douglas Troy

Gary, If the class calls Finalize, then using member initialization is certainly the right way to go. The reason being, if there is an error in the constructor, and Finalize is called, then the state of the fields could come into play. Using member initialization in this case means that you know your fields are valid, so you won't have issues if finalize is called following failed object construction. D.

Last modified: 12mins after originally posted --

realJSOP

FXCop will trigger an "issue" if you do the 2nd thing, but FXCop is, after all, just a style guide and most of what it chokes/pukes on can safely be ignored. I tend to use method #2 in your examples.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Scott Dorman

I don't think it really matters, especially in the case of setting variables to their default values (which is recommended to not do). If you have multiple constructors, you can set the initial values in your simplest constructor and then use constructor chaining. In your first example, you actually end up with 3 additional lines of IL in the constructor to handle loading the arguement on to the evaluation stack (which it already does), then loading the 0 as an integer on to the evaluation stack, and then replacing the value stored in the "Member" field with the new value.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

carbon_golem

Right. Also if initialization of any kind is put into the body of the class, it will be injected into every constructor when compiled to IL so it will tend to bloat up classes with multiple constructors. If you're a real performance nazi you'd have to take nuggets like that into consideration because the JITer will inline code under 32 bytes. See Here. Scott P.

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

Scott Dorman

carbon_golem wrote:

JITer will inline code under 32 bytes.

Great point.

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

S Senthil Kumar

carbon_golem wrote:

it will be injected into every constructor when compiled to IL so it will tend to bloat up classes with multiple constructors.

Even if the constructors are chained with this(...)?

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

S Senthil Kumar

There's a subtle difference if you call virtual methods from your constructor, which is generally not advisable. When generating IL code for the constructor, the C# compiler puts code for all field initializers before code for the constructor's body This means that overridden will see initialized values for field initialized members, but will see default values for others.

class Base
{
protected int x = 42;
protected int y;

public Base()
{
SomeVirtualMethod();
y = 42;
}

protected virtual void SomeVirtualMethod() {}
}

class Derived : Base
{
protected override void SomeVirtualMethod()
{
Console.WriteLine(x);
Console.WriteLine(y);
}
}

prints 42 and 0.

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

Vikram A Punathambekar

Gary, in your case, this will do:

class MyClass
{
private int Member;
}

Class level members are always initialized to default values. Strings are empty, numbers are 0, and bools are false.

Cheers, Vıkram.

I don't suffer from insanity, I enjoy every moment of it.

Gary Wheeler

I'm afraid my example was a little contrived. The actual code involved is a socket interface to a set of services. The interface includes a number of data structures that have to be initialized prior to startup, and it seemed stupid to duplicate the logic (or at least the method call to the logic) in every constructor.

Software Zen: delete this;

Gary Wheeler

I do use constructor chaining occasionally, where it's appropriate. My concern here is duplicating logic in each constructor, when the member initialization takes care of it in one place. Since I'm new to .NET, I was concerned there was some drawback to using member initialization that I wasn't aware of.

Software Zen: delete this;

Vikram A Punathambekar

Ah, apologies, I didn't know that. But you have got some excellent answers :) I learnt some bits myself, so thanks for posting the question.

Cheers, Vıkram.

I don't suffer from insanity, I enjoy every moment of it.

Gary Wheeler

No need to apologize, Vikram; thanks for answering.

Software Zen: delete this;

Scott Dorman

I understand the concern, but you can still keep the member initialization in one place in your simplest constructor. For example:

public class Class1
{
private int count;
private string status;
private bool flag;

public Class1()
{
this.count = 1;
this.status = "None";
}

public Class1() : this()
{
flag = false;
}

Scott Dorman

Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]

Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

S Senthil Kumar

Douglas Troy wrote:

Using member initialization in this case means that you know your fields are valid, so you won't have issues if finalize is called following failed object construction.

How so?

    static class Win32
    {
        public static IntPtr OpenHandle() { return IntPtr.Zero; }
        public static void CloseHandle(IntPtr ptr) { }
    }

    class TestClass
    {
        IntPtr h1 = Win32.OpenHandle();

        ~TestClass()
        {
            Win32.CloseHandle(h1);
        }
    }

If OpenHandle throws an exception, I would expect the finalizer to still run, with h1 having the default value.

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro

carbon_golem

No. If you chain constructors, the compiler is smart enough to put members initialized in the class body into the last chain target. I went back through and verified this. Here is some sample code for you to compile and run ILDasm on. Car has chained constructors, where Truck does not. Truck's constructors all get the initialization code for the CultureInfo member, where Car has the initialization for CultureInfo in the constructor that takes 2 args. using System; using System.Globalization; namespace ConstructorChainKata { class Program { static void Main(string[] args) { } } public enum Market { Production, Concept, Military, Custom, Armored } public class Car { private String manufacturer; private Market market; private CultureInfo targetLocale = new CultureInfo("en-US"); public Car(String manuf) :this(manuf, Market.Production) { //.. } public Car(String manuf, Market markt) { manufacturer = manuf; market = markt; } } public class Truck { private String manufacturer; private Market market; private CultureInfo targetLocale = new CultureInfo("en-US"); public Truck(String manuf) { manufacturer = manuf; market = Market.Production; } public Truck(String manuf, Market markt) { manufacturer = manuf; market = markt; } } } Scott P

"Simplicity carried to the extreme becomes elegance."
-Jon Franklin

S Senthil Kumar

Yeah, that's what I thought it would do. In fact, if the compiler did not do this, the program would be wrong - field initializers would run as many times as the length of the chain. If some of the field initializers got populated as a result of a static method call with side effects...

Regards Senthil [MVP - Visual C#] _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro