constructor calling constructor
-
Scenario: I have an object that has 2 overloads of a constructor. For some reason, overload1 in turn calls overload2. i.e. I want to defer object creation until overload2 is eventually called. I'm not sure of the syntax, as constructors don't seem to be treated as normal functions. Can someone provide me with code for this? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
-
Scenario: I have an object that has 2 overloads of a constructor. For some reason, overload1 in turn calls overload2. i.e. I want to defer object creation until overload2 is eventually called. I'm not sure of the syntax, as constructors don't seem to be treated as normal functions. Can someone provide me with code for this? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
class Foo
{
int value;
public Foo()
: this(0)
{
}
public Foo(int i)
{
value = i;
}
} -
class Foo
{
int value;
public Foo()
: this(0)
{
}
public Foo(int i)
{
value = i;
}
} -
Thanks, Neil. I'll pass this on to my team. Is this a good practice (constructor calling constructor)? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
It’s more personal preference issue, although I don’t see how it could be a bad practice and in this case it is an integral part of the language. Code reuse (outside of cut and paste) is never a bad practice in my opinion. Regards
-
It’s more personal preference issue, although I don’t see how it could be a bad practice and in this case it is an integral part of the language. Code reuse (outside of cut and paste) is never a bad practice in my opinion. Regards
Is there no additional overhead, in terms of MSIL code, to pull this off? What about the alternative of creating an additional function that had the "shared" code that both constructors could use? In your opinion, wouldn't this produce cleaner code? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
-
Is there no additional overhead, in terms of MSIL code, to pull this off? What about the alternative of creating an additional function that had the "shared" code that both constructors could use? In your opinion, wouldn't this produce cleaner code? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
Again, its personal preference. In overhead terms, there really is nothing to pull off; the initial constructor does generate a call to the target constructor. If you were going to supply a common private initialization member, it may accomplish the same thing with or without parameter passing. If your initialization member is parameterized, I would venture a guess that it carries the same amount of overhead. Regards
-
Is there no additional overhead, in terms of MSIL code, to pull this off? What about the alternative of creating an additional function that had the "shared" code that both constructors could use? In your opinion, wouldn't this produce cleaner code? Cheers, Simon "Every good work of software starts by scratching a developer's personal itch.", Eric S. Raymond
In terms of cleaner code, if the class carries a significant amount of initialization that is common across all constructors, yes a shared initialization member can be cleaner. I have also seen cases where these initialization members also become a reset mechanism for the class. Not that this is a bad thing, but in large projects and/or as time goes on and maintenance coding kicks in, it may be easier for a member of your team to forget what the primary purpose of the member was and start calling virtual members within it, which is a bad thing. My two cents. Regards