can I call from one constructor another constructor ?

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

John
Wed Jun 30 07:48:48 CDT 2004

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_spam@dupa.com> wrote in message
news:u3gtZ7pXEHA.644@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
>
>

AlexS
Wed Jun 30 07:46:54 CDT 2004

Paul.

use this to reference current instance.

E.g.

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

HTH
Alex

"Paul" <no_spam@dupa.com> wrote in message
news:u3gtZ7pXEHA.644@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
>
>

Chris
Wed Jun 30 07:52:10 CDT 2004

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

Chris

"Paul" <no_spam@dupa.com> wrote in message
news:u3gtZ7pXEHA.644@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
>
>

Jon
Wed Jun 30 08:05:29 CDT 2004

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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jon
Wed Jun 30 08:04:38 CDT 2004

Paul <no_spam@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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

John
Wed Jun 30 09:09:45 CDT 2004

> 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).

Jon
Wed Jun 30 09:15:54 CDT 2004

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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

John
Wed Jun 30 09:22:11 CDT 2004

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]" <skeet@pobox.com> wrote in message
news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> 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 - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

John
Wed Jun 30 11:36:22 CDT 2004

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]" <skeet@pobox.com> wrote in message
news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> 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 - <skeet@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

Daniel
Wed Jun 30 18:43:58 CDT 2004


"John Wood" <j@ro.com> wrote in message
news:uhEOi2qXEHA.2944@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]" <skeet@pobox.com> wrote in message
> news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
>> 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 - <skeet@pobox.com>
>> http://www.pobox.com/~skeet
>> If replying to the group, please do not mail me too
>
>

Jeff
Wed Jun 30 20:28:45 CDT 2004

Paul... You can also use static factory methods.

http://www.geocities.com/jeff_louie/OOP/oop4.htm

Regards,
Jeff

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!

John
Wed Jun 30 20:53:04 CDT 2004

"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:u3jrcwvXEHA.644@TK2MSFTNGP10.phx.gbl...
>
> "John Wood" <j@ro.com> wrote in message
> news:uhEOi2qXEHA.2944@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]" <skeet@pobox.com> wrote in message
> > news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> >> 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 - <skeet@pobox.com>
> >> http://www.pobox.com/~skeet
> >> If replying to the group, please do not mail me too
> >
> >
>
>

Daniel
Wed Jun 30 22:22:21 CDT 2004



>
> 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?

John
Wed Jun 30 23:03:41 CDT 2004

>> 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?

Steven
Fri Jul 02 19:16:34 CDT 2004

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

Steven
Fri Jul 02 19:19:55 CDT 2004

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

Mark
Mon Jul 05 22:49:01 CDT 2004

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
Tue Jul 06 01:39:56 CDT 2004

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

Stano
Tue Jul 13 20:46:01 CDT 2004

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]" <skeet@pobox.com> wrote in message
> news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> > 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 - <skeet@pobox.com>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
>
>
>

Stano
Wed Jul 14 00:00:02 CDT 2004

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" <davidd.NOSPAM.williams@earthlink.net> wrote
> in message news:OQhAivUaEHA.2816@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" <Stano@discussions.microsoft.com> wrote in message
> > news:66BE422F-0C22-4DED-9EF2-0BB2287B6B24@microsoft.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]" <skeet@pobox.com> wrote in message
> > > > news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> > > > > 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 - <skeet@pobox.com>
> > > > > http://www.pobox.com/~skeet
> > > > > If replying to the group, please do not mail me too
> > > >
> > > >
> > > >
> >
>
>
>

Frank
Wed Jul 14 08:29:00 CDT 2004

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" <Stano@discussions.microsoft.com> wrote in message
news:D4CEC119-4483-47CB-AFFA-C43C7A6671D1@microsoft.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" <davidd.NOSPAM.williams@earthlink.net>
wrote
> > in message news:OQhAivUaEHA.2816@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" <Stano@discussions.microsoft.com> wrote in message
> > > news:66BE422F-0C22-4DED-9EF2-0BB2287B6B24@microsoft.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]" <skeet@pobox.com> wrote in message
> > > > > news:MPG.1b4cdb754a08b4ef98ae11@msnews.microsoft.com...
> > > > > > 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 - <skeet@pobox.com>
> > > > > > http://www.pobox.com/~skeet
> > > > > > If replying to the group, please do not mail me too
> > > > >
> > > > >
> > > > >
> > >
> >
> >
> >