By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,901 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

can I call from one constructor another constructor ?

P: n/a
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul
Nov 16 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
You cannot. You will have to move the code in the second constructor into a
function, called 'Initialize' for example, and then invoke that function
from both constructors.

You can, however, invoke inherited contructors in the constructor signature
using the base keyword, eg:

public A (int param1, string param2) : base(param1, param2)
{
...
}

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Paul" <no*****@dupa.com> wrote in message
news:u3*************@tk2msftngp13.phx.gbl...
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul

Nov 16 '05 #2

P: n/a
Paul.

use this to reference current instance.

E.g.

public A() : this(1,2,3) {
....
}

HTH
Alex

"Paul" <no*****@dupa.com> wrote in message
news:u3*************@tk2msftngp13.phx.gbl...
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul

Nov 16 '05 #3

P: n/a
do it like this:
public A() : this(1, 2, 3)
{
// other constructor will be called before anything
// happens in this one.
}

Chris

"Paul" <no*****@dupa.com> wrote in message
news:u3*************@tk2msftngp13.phx.gbl...
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul

Nov 16 '05 #4

P: n/a
C# Constructors are described at:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/csref/html/vclrfinstanceconstructors.asp

You can call another version of constructor as follows:

public class A
{
public A() : this(1,2,3)
{
// Equivalent to Calling another version of
constructor at first line

}

public A (int a, int b, int c)
{
// some code
}
}

--
Cheers,
Rahul
-----Original Message-----
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how toaccomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul
.

Nov 16 '05 #5

P: n/a
John Wood <j@ro.com> wrote:
You cannot. You will have to move the code in the second constructor into a
function, called 'Initialize' for example, and then invoke that function
from both constructors.
Yes you can - just as your code below, but using "this" instead of
"base".
You can, however, invoke inherited contructors in the constructor signature
using the base keyword, eg:

public A (int param1, string param2) : base(param1, param2)
{
...
}


Point of pedantry: constructors aren't inherited. That invokes the base
constructor.

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

P: n/a
Paul <no*****@dupa.com> wrote:
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}


See http://www.pobox.com/~skeet/csharp/constructors.html

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

P: n/a
> Yes you can - just as your code below, but using "this" instead of
"base".

Yeah true you can (I admit I forgot), but I rarely use that because you have
little control over when the referenced constructor is called (it always
runs before the constructor body).
Nov 16 '05 #8

P: n/a
John Wood <j@ro.com> wrote:
Yes you can - just as your code below, but using "this" instead of
"base".

Yeah true you can (I admit I forgot), but I rarely use that because you have
little control over when the referenced constructor is called (it always
runs before the constructor body).


That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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

P: n/a
I still don't get why they didn't add optional parameters in C#...
Constructor overloads can get pretty messy, given all the permutations you
have to provide.

--
John Wood
EMail: first name, dot, last name, at priorganize.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
Yes you can - just as your code below, but using "this" instead of
"base".

Yeah true you can (I admit I forgot), but I rarely use that because you have little control over when the referenced constructor is called (it always
runs before the constructor body).


That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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

Nov 16 '05 #10

P: n/a
Incidentally, I typically use the essence pattern for constructing complex
objects now.. saves having all those overloads cluttering the class.

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
Yes you can - just as your code below, but using "this" instead of
"base".

Yeah true you can (I admit I forgot), but I rarely use that because you have little control over when the referenced constructor is called (it always
runs before the constructor body).


That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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

Nov 16 '05 #11

P: n/a

"John Wood" <j@ro.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...
I still don't get why they didn't add optional parameters in C#...
Constructor overloads can get pretty messy, given all the permutations you
have to provide.
Because, IMHO, Optional parameters end up being more complex in practice.
They pretty much hide whats actually going on: an optional parameter hides
values, meaning you have to rely on documentation to understand whats being
passed as well as to what the passed values mean as far as behavior goes.
That isn't particularly pleasent and doesn't tend to be that easy to debug
or maintain.
Badly written methods that use optional parameters can be more complex than
a set of overloads(a few dozen if statements in one method redirecting to
sub methods or whatever, based entirely on which parameters were provided).
Another particular problem is that optional parameters do *nothing* to
express constraints. A method with 4 parameters, of which any three can be
provided or where all 4 can be provided or only 2 can, or whatever just
doesn't work. Overloads are the proper choice here, optional parameters are
not substitutes for functional permutation, they are only for situations
where you don't wish to pass a parameter and are happy with the default
value. Note I would consider it bad practice to check an optional parameter
for null and then assign a property a generic value based on that null(ya
know, new MyObject()).
Optional parameters also have a particular limitation in that the default
value takes away one possible state. Its usually irrelevent, but being able
to differentiate between a default value x and the literal value y that
happens to be equal to x may be relevent, especially if you are using
reference types(strings most likely). This manifests in nullablity as
well(as best as I remember, the runtime doesn't allow that level of
flexibilty but I may be wrong. These are conceptual arguments not
implementation specific).

I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty
unreadable.

Beyond that, the one implementation specific issue: optional parameters
don't version well. You have to recompile client code whenever the parameter
values change as they are inserted into calling code directly.

Put all that together and I argue that optional parameters should rarely, if
ever, be used. There are just too many problems, too many tricks, and far to
many oppurtunities for misuse(and, examining history, misuse is the law of
the land). --
John Wood
EMail: first name, dot, last name, at priorganize.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
> > Yes you can - just as your code below, but using "this" instead of
> > "base".
> Yeah true you can (I admit I forgot), but I rarely use that because you have > little control over when the referenced constructor is called (it
> always
> runs before the constructor body).


That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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


Nov 16 '05 #12

P: n/a
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message
Because, IMHO, Optional parameters end up being more complex in practice. They pretty much hide whats actually going on: an optional parameter hides
values, meaning you have to rely on documentation to understand whats being
passed as well as to what the passed values mean as far as behavior goes.
<<

Right but the same goes for overloaded methods... you're no longer providing
the parameter, so what would it default to? In VIsual Basic, for example,
you can specify the default value as part of the method signature. As such,
it would be displayed in intellisense. That's something which is impossible
with overloading -- because the defaulting is hidden away in code that's not
visible without manual documentation.
Another particular problem is that optional parameters do *nothing* to express constraints. A method with 4 parameters, of which any three can be
provided or where all 4 can be provided or only 2 can, or whatever just
doesn't work. <<

I agree here, sometimes parameters aren't just optional they're mutually
exclusive, in combinations that are impossible to represent with optional
parameters. However this is an obvious candidate for overloading... but that
doesn't mean we shouldn't have optional parameters for all other situations,
they easily complement one another.
Note I would consider it bad practice to check an optional parameter for null and then assign a property a generic value based on that null(ya know,
new MyObject()). <<

Yeah of course, I don't think anyone would advocate that, another good
reason to have optional parameters, rather than letting people try to
synthesize a half-baked optional parameter implementation themselves.
Optional parameters also have a particular limitation in that the default value takes away one possible state...able to differentiate between a
default value x and the literal value y that happens to be equal to x may be
relevent <<

Yeah, this can and has been solved in Visual Basic, where you have the
IsMissing keyword that indicates whether or not a parmeter was actually
specified. eg. if (isMissing(price)) price = 23;
I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty unreadable. <<

VBA actually has some nice optional parameter syntax, it allows you to
specify the name of the parameter(s) in the method call, eg. MyMethod(
category:=CitrusFruit, price:=1.45, weight:=6 );
C# could quite easily adopt this syntax, and allow it for non-optional
paramaterized methods also.
Beyond that, the one implementation specific issue: optional parameters don't version well. You have to recompile client code whenever the parameter
values change as they are inserted into calling code directly. <<

I think the above method of specifying optional parameters would version
quite well, so long as a parameter names didn't change. In fact it would
probably version better than a regular method (because parameter specifying
to parameter signature binding is explicit).

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:u3*************@TK2MSFTNGP10.phx.gbl...

"John Wood" <j@ro.com> wrote in message
news:uh**************@TK2MSFTNGP11.phx.gbl...
I still don't get why they didn't add optional parameters in C#...
Constructor overloads can get pretty messy, given all the permutations
you have to provide.

Because, IMHO, Optional parameters end up being more complex in practice.
They pretty much hide whats actually going on: an optional parameter hides
values, meaning you have to rely on documentation to understand whats

being passed as well as to what the passed values mean as far as behavior goes.
That isn't particularly pleasent and doesn't tend to be that easy to debug
or maintain.
Badly written methods that use optional parameters can be more complex than a set of overloads(a few dozen if statements in one method redirecting to
sub methods or whatever, based entirely on which parameters were provided). Another particular problem is that optional parameters do *nothing* to
express constraints. A method with 4 parameters, of which any three can be
provided or where all 4 can be provided or only 2 can, or whatever just
doesn't work. Overloads are the proper choice here, optional parameters are not substitutes for functional permutation, they are only for situations
where you don't wish to pass a parameter and are happy with the default
value. Note I would consider it bad practice to check an optional parameter for null and then assign a property a generic value based on that null(ya
know, new MyObject()).
Optional parameters also have a particular limitation in that the default
value takes away one possible state. Its usually irrelevent, but being able to differentiate between a default value x and the literal value y that
happens to be equal to x may be relevent, especially if you are using
reference types(strings most likely). This manifests in nullablity as
well(as best as I remember, the runtime doesn't allow that level of
flexibilty but I may be wrong. These are conceptual arguments not
implementation specific).

I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty
unreadable.

Beyond that, the one implementation specific issue: optional parameters
don't version well. You have to recompile client code whenever the parameter values change as they are inserted into calling code directly.

Put all that together and I argue that optional parameters should rarely, if ever, be used. There are just too many problems, too many tricks, and far to many oppurtunities for misuse(and, examining history, misuse is the law of
the land).
--
John Wood
EMail: first name, dot, last name, at priorganize.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
> > Yes you can - just as your code below, but using "this" instead of
> > "base".
> Yeah true you can (I admit I forgot), but I rarely use that because
you have
> little control over when the referenced constructor is called (it
> always
> runs before the constructor body).

That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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



Nov 16 '05 #13

P: n/a


Right but the same goes for overloaded methods... you're no longer
providing
the parameter, so what would it default to? In VIsual Basic, for example,
you can specify the default value as part of the method signature. As
such,
it would be displayed in intellisense. That's something which is
impossible
with overloading -- because the defaulting is hidden away in code that's
not
visible without manual documentation.
Not quite. Because overloaded methods don't take those parameters, they
simply don't matter and aren't necessarily even used. When it comes to
overloads functionality definition is all that matters. I don't think the
same applies with defaults, as the actual *value* of a default is passed to
the method.
Another particular problem is that optional parameters do *nothing* to express constraints. A method with 4 parameters, of which any three can be
provided or where all 4 can be provided or only 2 can, or whatever just
doesn't work. <<

I agree here, sometimes parameters aren't just optional they're mutually
exclusive, in combinations that are impossible to represent with optional
parameters. However this is an obvious candidate for overloading... but
that
doesn't mean we shouldn't have optional parameters for all other
situations,
they easily complement one another.
I don't agree they easily compliment eachother. I would say the usage of
optional parameters is pretty constrained to *one* type of usage, but is
generally abused to bend them into another type. At the least, if a change
in the implementation of a optional method changes to where different
parameter combinations requires different logic, you can't easily change the
interface. With overloaded methods you don't have to change anything, as
long as that predefined pair exists already.

This goes against versioning.
Note I would consider it bad practice to check an optional parameter
for null and then assign a property a generic value based on that null(ya
know,
new MyObject()). <<

Yeah of course, I don't think anyone would advocate that, another good
reason to have optional parameters, rather than letting people try to
synthesize a half-baked optional parameter implementation themselves.

I don't know, some might. No optional means people write overloads or write
bad interfaces that look bad(I do think optional is one major failing of vb,
and a significant cause of the problems with VB libraries, the interfaces
are terrible but they dont' look that way to vb devs).

You should also probably absolutly avoid using optional parameters in
interfaces, abstract or virtual methods when you can't be absolutely
*CERTAIN* that no inheriter will ever have any interest in performing
anything but basic mapping. An optional parameter in an interface severely
constrains the actual possible implementation logic or force the bad designs
I've discussed. Its not a very good idea.
Optional parameters also have a particular limitation in that the
default value takes away one possible state...able to differentiate between a
default value x and the literal value y that happens to be equal to x may
be
relevent <<

Yeah, this can and has been solved in Visual Basic, where you have the
IsMissing keyword that indicates whether or not a parmeter was actually
specified. eg. if (isMissing(price)) price = 23;


I did some checking, IsMissing is *not* supported in VB.NET, as the CLS
doesn't directly support optional parameters. Default values are simply
metadata applied to a method, each language is responsible for loading those
values *directly* into client code, the runtime is entirely uninvolved.
I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty unreadable. <<

VBA actually has some nice optional parameter syntax, it allows you to
specify the name of the parameter(s) in the method call, eg. MyMethod(
category:=CitrusFruit, price:=1.45, weight:=6 );
C# could quite easily adopt this syntax, and allow it for non-optional
paramaterized methods also.


It could, but I think its ugly syntax as well. It doesn't solve anything and
it has the additional downside of hiding the fact that the method actually
takes 15 parameters.

I also worry that such syntax promotes writting bad method interfaces(as
I've expressed before). Instead of writing an overload, people would prefer
to modify the signature of the one method and simply have one huge method so
they never have to change client code. This is another major issue. Beyond that, the one implementation specific issue: optional parameters

don't version well. You have to recompile client code whenever the
parameter
values change as they are inserted into calling code directly. <<

I think the above method of specifying optional parameters would version
quite well, so long as a parameter names didn't change. In fact it would
probably version better than a regular method (because parameter
specifying
to parameter signature binding is explicit).


It doesn't solve the fact that client code has optionals baked in. That
there is no way to differentiate between a default parameter value and the
same value passed in(without significant changes to the runtime).
Don't forget the CLS. To support optional parameters to the extent you want
would either require adding support to the CLS(and every language) or
removing it totally(as it stands its optional) as every langauge would have
to support the new calling semantics involved to allow making calls with
no-value support(some form of special stack value would have to be used to
specify no value was passed, vs default value or a given value).
The results aren't pleasent for a feature that has limited usage, IMHO. As
I've shown, they are only of value in methods that won't be overloaded and
potentially constructors...what are the real values, outside of simply
making things easier in those rather rare situations where you can be sure
it'll never break anything?

Nov 16 '05 #14

P: n/a
>> Not quite. Because overloaded methods don't take those parameters, they
simply don't matter and aren't necessarily even used. When it comes to
overloads functionality definition is all that matters. I don't think the
same applies with defaults, as the actual *value* of a default is passed to
the method. <<

That's true for the instance where you actually *want* an overload. I think
there's quite a distinction between parameters that are truly optional
(and/or can be defaulted), and method signature permutations that call for
straight forward overloading.

If you agree with that, then you'd understand how intellisense would be
available to display the default values of missing parameters, and this
wouldn't be so easily achieved with overloaded functions trying to mimick
optional parameters. How much of my day do I spend looping through all the
permutations of parameters in overloads of a method, just to find the
combination I want? Some methods have 20 or more permutations!
I don't agree they easily compliment eachother. I would say the usage of optional parameters is pretty constrained to *one* type of usage, but is
generally abused to bend them into another type. <<

Anything can be abused if poorly understood, I don't think that's an
argument to throw out the feature for good. Interfaces can be used where an
abstract base class is used, methods can have out parameters where a return
value should be used, methods can be defined where properties should be
defined... etc. etc.
You should also probably absolutly avoid using optional parameters in interfaces, abstract or virtual methods when you can't be absolutely
*CERTAIN* that no inheriter will ever have any interest in performing
anything but basic mapping. <<

I tend to agree with that. Although I don't think the compiler should
necessarily enforce it.
I did some checking, IsMissing is *not* supported in VB.NET <<
Yeah I was aware of that.. I was referring to vb 6.
That there is no way to differentiate between a default parameter value and the same value passed in(without significant changes to the runtime). <<

I understand there are certainly CLS-related issues, cross language
interoperation issues. They had the same issues with implementing optional
parameters in COM.. and what did they do? They mandate that all optional
parameters are variants and therefore typeless, and a 'not specified' value
of the variant is used to specify missing parameters.

While I wouldn't advocate such a solution in the CLR, a variation on that
might be possible. For languages that have not been upgraded to support
optional parameters, the parameters are passed in as objects, and a special
object instance 'Missing' can be used for missing parameters.

For languages that do support optional parameters, extra meta data in the
method signature can be used to determine the actual type of the parameter,
along with information on the default values used if the value isn't
specified. This can be displayed in intellisense, and the language can be
extended to support a parameter-specifying syntax as mentioned from VBA
above.
As I've shown, they are only of value in methods that won't be overloaded

and potentially constructors <<

I'm not convinced. There are a vast number of patterns used in the plethora
of software applications available today, it would be difficult or
impossible for anyone to say that's the case.

Construction definitely (although as I mentioned in another post, I have
used the essence pattern to overcome some of these limitations).

Elsewhere? Well, look at dispatch based COM interfaces throughout Microsoft
products. Every other method in the object model uses optional parameters.
Take Excel for example. A method such as AutoFill on a sheet, taking the
destination as the first parameter, followed by the optional type of the
auto-fill operation as an enumerator. It tells you in intellisense what the
default value is, and that seems sensible to me. You just couldn't do that
with overloading -- how would I know what it does if it's not specified?

Nov 16 '05 #15

P: n/a
On Wed, 30 Jun 2004 10:22:11 -0400, John Wood wrote:
I still don't get why they didn't add optional parameters in C#...
Constructor overloads can get pretty messy, given all the permutations you
have to provide.


coming from a language which didnt have the overload concept (vb old) iam
thankfull everyday that C# does.

all it done was force brain bending logic to get things going.

--
-------------------------------------------
Steven H, 3rd Year B.I.T. Otago Polytechnic

..net Geek
Nov 16 '05 #16

P: n/a
On Wed, 30 Jun 2004 21:53:04 -0400, John Wood wrote:
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty
unreadable. <<

VBA actually has some nice optional parameter syntax, it allows you to
specify the name of the parameter(s) in the method call, eg. MyMethod(
category:=CitrusFruit, price:=1.45, weight:=6 );


iirc vb had it too, not that it matters im too lazy to type out all that.
C# could quite easily adopt this syntax, and allow it for non-optional
paramaterized methods also.


god i hope not.
--
-------------------------------------------
Steven H, 3rd Year B.I.T. Otago Polytechnic

..net Geek
Nov 16 '05 #17

P: n/a
On Wed, 30 Jun 2004 10:22:11 -0400, John Wood wrote:
I still don't get why they didn't add optional parameters in C#...
Constructor overloads can get pretty messy, given all the permutations you
have to provide.


coming from a language which didnt have the overload concept (vb old) iam
thankfull everyday that C# does.

all it done was force brain bending logic to get things going.

--
-------------------------------------------
Steven H, 3rd Year B.I.T. Otago Polytechnic

..net Geek
Nov 16 '05 #18

P: n/a
On Wed, 30 Jun 2004 21:53:04 -0400, John Wood wrote:
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message I also think that methods like MyMethod(a,,,,,,4,,,83,c) are pretty
unreadable. <<

VBA actually has some nice optional parameter syntax, it allows you to
specify the name of the parameter(s) in the method call, eg. MyMethod(
category:=CitrusFruit, price:=1.45, weight:=6 );


iirc vb had it too, not that it matters im too lazy to type out all that.
C# could quite easily adopt this syntax, and allow it for non-optional
paramaterized methods also.


god i hope not.
--
-------------------------------------------
Steven H, 3rd Year B.I.T. Otago Polytechnic

..net Geek
Nov 16 '05 #19

P: n/a
The short answer is no. The constructor constructs an instance of a class. A more correct 'if there is one' version of the example you have provided would be:

public class A
{
private int a = 0;
private int b = 0;
private int c = 0;

public A ()
{

// a, b, c are initialized by the default values. Calling another constructor
is not necessary.. }

public A (int a, int b, int c)
{
_a = a;
_b = b;
_c = c;
// Whatever code you want here.
}

public int A {
get {
return _a;
}
set {
_a = value;
}
}

// Accessors for B and C would be here
}

Hope this helps.

"Paul" wrote:
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul

Nov 16 '05 #20

P: n/a
A slightly longer answer is yes, by providing default values:

public class A {

public A(int a, int b, int c) {
...
}
public A() : this(1, 2, 3) {
...
}

}

--
Simon Smith
simon dot s at ghytred dot com
www.ghytred.com/NewsLook - NNTP Client for Outlook
On 06 Jul 2004 04:49, "Mark Round" wrote:
The short answer is no. The constructor constructs an instance of a class.
A more correct 'if there is one' version of the example you have provided
would be:

public class A
{
private int a = 0;
private int b = 0;
private int c = 0;

public A ()
{

// a, b, c are initialized by the default values. Calling another constructor
is not necessary.. }

public A (int a, int b, int c)
{
_a = a;
_b = b;
_c = c;
// Whatever code you want here.
}

public int A {
get {
return _a;
}
set {
_a = value;
}
}

// Accessors for B and C would be here
}

Hope this helps.

"Paul" wrote:
public class A
{
public A ()
{
// here I would like to call the second version of _ctor, how to
accomplish this ?
}

public A (int a, int b, int c)
{
// some code
}
}

Thanks for any advice,
Paul



--
Simon Smith
simon dot s at ghytred dot com
www.ghytred.com/NewsLook - NNTP Client for Outlook
Nov 16 '05 #21

P: n/a
I know that this might be getting away from the original post, but I have a question about optional paramters in C#.

I originally developed a COM DLL using VB.NET which had an optional parameter in one of the methods. I ported the entire project to C# (as I decided C# was the way to go) but I was unable to work out how to redefine the COM interface in C# with an optional COM parameter.

In the end the COM interface was defined in VB.NET and the rest of the project was written using C#. I know that this isn't a big deal, but it's been bugging me for a while now. Does anyone have any ideas on how to do this?

Thanks.

"John Wood" wrote:
Incidentally, I typically use the essence pattern for constructing complex
objects now.. saves having all those overloads cluttering the class.

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
> Yes you can - just as your code below, but using "this" instead of
> "base".
Yeah true you can (I admit I forgot), but I rarely use that because you have little control over when the referenced constructor is called (it always
runs before the constructor body).


That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly going
to the "full" one or going in stages. I believe this is fairly common.

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


Nov 16 '05 #22

P: n/a
As I start to dig into C#, this is one major issue that I have run into
also. According to the specs for C#, optional parameters are not
supported.

"Stano" <St***@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com:
I know that this might be getting away from the original post, but I have
a question about optional paramters in C#.

I originally developed a COM DLL using VB.NET which had an optional
parameter in one of the methods. I ported the entire project to C# (as I
decided C# was the way to go) but I was unable to work out how to redefine
the COM interface in C# with an optional COM parameter.

In the end the COM interface was defined in VB.NET and the rest of the
project was written using C#. I know that this isn't a big deal, but it's
been bugging me for a while now. Does anyone have any ideas on how to do
this?

Thanks.

"John Wood" wrote:
Incidentally, I typically use the essence pattern for constructing
complex
objects now.. saves having all those overloads cluttering the class.

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
John Wood <j@ro.com> wrote:
> > Yes you can - just as your code below, but using "this" instead
> > of
> > "base".
> Yeah true you can (I admit I forgot), but I rarely use that because
> you

have
> little control over when the referenced constructor is called (it
> always
> runs before the constructor body).

That doesn't mean it's not useful though. I use it all the time when
providing constructs which effectively default various values - each
constructor calls a version with more parameters, either directly
going
to the "full" one or going in stages. I believe this is fairly
common.

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



Nov 16 '05 #23

P: n/a
why not try not making them optional?

use overloaded constructors for all scenarios.

example vb:

public function DoSomething(x as string, y as string, z as optional string)
as string

converted to c#

public string DoSomething(string x, string y)
public string DoSomething(string x, string y, string z)

my vb syntax may not be completely correct but hopefully you get the point i
am trying to make

--
Frank Wisniewski MCSE 4.0, MCP+I, A+
f p w 2 3 @ h o t m a i l . c o m
<David Williams>; "VB.NET MVP" <da********************@earthlink.net> wrote
in message news:OQ**************@TK2MSFTNGP11.phx.gbl...
As I start to dig into C#, this is one major issue that I have run into
also. According to the specs for C#, optional parameters are not
supported.

"Stano" <St***@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com:
I know that this might be getting away from the original post, but I have a question about optional paramters in C#.

I originally developed a COM DLL using VB.NET which had an optional
parameter in one of the methods. I ported the entire project to C# (as I
decided C# was the way to go) but I was unable to work out how to redefine the COM interface in C# with an optional COM parameter.

In the end the COM interface was defined in VB.NET and the rest of the
project was written using C#. I know that this isn't a big deal, but it's been bugging me for a while now. Does anyone have any ideas on how to do
this?

Thanks.

"John Wood" wrote:
Incidentally, I typically use the essence pattern for constructing
complex
objects now.. saves having all those overloads cluttering the class.

--
John Wood
EMail: first name, dot, last name, at priorganize.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> John Wood <j@ro.com> wrote:
> > > Yes you can - just as your code below, but using "this" instead
> > > of
> > > "base".
> > Yeah true you can (I admit I forgot), but I rarely use that because > > you
have
> > little control over when the referenced constructor is called (it
> > always
> > runs before the constructor body).
>
> That doesn't mean it's not useful though. I use it all the time when
> providing constructs which effectively default various values - each
> constructor calls a version with more parameters, either directly
> going
> to the "full" one or going in stages. I believe this is fairly
> common.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Nov 16 '05 #24

P: n/a
It's a distant memory as this was some time ago, but I tried that, and as far as I am aware it didn't work as I was trying to keep the interface binary compatible with my previous definition in VB.NET, so that my clients could install the new version without having to change their code.

Anyway it's a distant memory now as all of my recent development has left the COM world behind, and should I develop any COM interfaces in the future I'll make sure that I keep away from Optional parameters. They're the devil's work ;)

Thanks.

"Frank Wisniewski" wrote:
why not try not making them optional?

use overloaded constructors for all scenarios.

example vb:

public function DoSomething(x as string, y as string, z as optional string)
as string

converted to c#

public string DoSomething(string x, string y)
public string DoSomething(string x, string y, string z)

my vb syntax may not be completely correct but hopefully you get the point i
am trying to make

--
Frank Wisniewski MCSE 4.0, MCP+I, A+
f p w 2 3 @ h o t m a i l . c o m
<David Williams>; "VB.NET MVP" <da********************@earthlink.net> wrote
in message news:OQ**************@TK2MSFTNGP11.phx.gbl...
As I start to dig into C#, this is one major issue that I have run into
also. According to the specs for C#, optional parameters are not
supported.

"Stano" <St***@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com:
I know that this might be getting away from the original post, but I have a question about optional paramters in C#.

I originally developed a COM DLL using VB.NET which had an optional
parameter in one of the methods. I ported the entire project to C# (as I
decided C# was the way to go) but I was unable to work out how to redefine the COM interface in C# with an optional COM parameter.

In the end the COM interface was defined in VB.NET and the rest of the
project was written using C#. I know that this isn't a big deal, but it's been bugging me for a while now. Does anyone have any ideas on how to do
this?

Thanks.

"John Wood" wrote:

> Incidentally, I typically use the essence pattern for constructing
> complex
> objects now.. saves having all those overloads cluttering the class.
>
> --
> John Wood
> EMail: first name, dot, last name, at priorganize.com
>
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> news:MP************************@msnews.microsoft.c om...
> > John Wood <j@ro.com> wrote:
> > > > Yes you can - just as your code below, but using "this" instead
> > > > of
> > > > "base".
> > > Yeah true you can (I admit I forgot), but I rarely use that because > > > you
> have
> > > little control over when the referenced constructor is called (it
> > > always
> > > runs before the constructor body).
> >
> > That doesn't mean it's not useful though. I use it all the time when
> > providing constructs which effectively default various values - each
> > constructor calls a version with more parameters, either directly
> > going
> > to the "full" one or going in stages. I believe this is fairly
> > common.
> >
> > --
> > Jon Skeet - <sk***@pobox.com>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
>
>
>


Nov 16 '05 #25

P: n/a
Sure you can do this, however it would not be the same COM signature as
the VB.NET code. If the OP is trying to maintain COM interface
compatibility, then this is not viable.

HTH

David

"Frank Wisniewski" <fp***@hotmail.com> wrote in message
news:40**********@Usenet.com:
why not try not making them optional?

use overloaded constructors for all scenarios.

example vb:

public function DoSomething(x as string, y as string, z as optional
string)
as string

converted to c#

public string DoSomething(string x, string y)
public string DoSomething(string x, string y, string z)

my vb syntax may not be completely correct but hopefully you get the point
i
am trying to make


Nov 16 '05 #26

P: n/a
Good Point, I didn't thing about breaking interfaces. I guess this is one
of those times where the small differences in the two languages will cause a
problem.
--
Frank Wisniewski MCSE 4.0, MCP+I, A+
f p w 2 3 @ h o t m a i l . c o m
"Stano" <St***@discussions.microsoft.com> wrote in message
news:D4**********************************@microsof t.com...
It's a distant memory as this was some time ago, but I tried that, and as far as I am aware it didn't work as I was trying to keep the interface
binary compatible with my previous definition in VB.NET, so that my clients
could install the new version without having to change their code.
Anyway it's a distant memory now as all of my recent development has left the COM world behind, and should I develop any COM interfaces in the future
I'll make sure that I keep away from Optional parameters. They're the
devil's work ;)
Thanks.

"Frank Wisniewski" wrote:
why not try not making them optional?

use overloaded constructors for all scenarios.

example vb:

public function DoSomething(x as string, y as string, z as optional string) as string

converted to c#

public string DoSomething(string x, string y)
public string DoSomething(string x, string y, string z)

my vb syntax may not be completely correct but hopefully you get the point i am trying to make

--
Frank Wisniewski MCSE 4.0, MCP+I, A+
f p w 2 3 @ h o t m a i l . c o m
<David Williams>; "VB.NET MVP" <da********************@earthlink.net> wrote in message news:OQ**************@TK2MSFTNGP11.phx.gbl...
As I start to dig into C#, this is one major issue that I have run into also. According to the specs for C#, optional parameters are not
supported.

"Stano" <St***@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com:
> I know that this might be getting away from the original post, but I

have
> a question about optional paramters in C#.
>
> I originally developed a COM DLL using VB.NET which had an optional
> parameter in one of the methods. I ported the entire project to C# (as I > decided C# was the way to go) but I was unable to work out how to

redefine
> the COM interface in C# with an optional COM parameter.
>
> In the end the COM interface was defined in VB.NET and the rest of the > project was written using C#. I know that this isn't a big deal, but

it's
> been bugging me for a while now. Does anyone have any ideas on how to do > this?
>
> Thanks.
>
> "John Wood" wrote:
>
> > Incidentally, I typically use the essence pattern for constructing
> > complex
> > objects now.. saves having all those overloads cluttering the class. > >
> > --
> > John Wood
> > EMail: first name, dot, last name, at priorganize.com
> >
> > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > news:MP************************@msnews.microsoft.c om...
> > > John Wood <j@ro.com> wrote:
> > > > > Yes you can - just as your code below, but using "this" instead > > > > > of
> > > > > "base".
> > > > Yeah true you can (I admit I forgot), but I rarely use that

because
> > > > you
> > have
> > > > little control over when the referenced constructor is called (it > > > > always
> > > > runs before the constructor body).
> > >
> > > That doesn't mean it's not useful though. I use it all the time when > > > providing constructs which effectively default various values - each > > > constructor calls a version with more parameters, either directly > > > going
> > > to the "full" one or going in stages. I believe this is fairly
> > > common.
> > >
> > > --
> > > Jon Skeet - <sk***@pobox.com>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too
> >
> >
> >


Nov 16 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.