optional parameter in function definitions?

[Guest]

I'll ask, how do you do it?

--
(i''ll be asking a lot of these, but I find C# totally way cooler than vb
and there''s no go''n back!!!)
thanks (as always)

kes

 

[Chris Shepherd]

I'll ask, how do you do it?

Overload the function.

Chris.

 

[pedrito]

public void MyMethod(params object[] myParams)
{
}

Then just iterate through params. If you know all the arguments are going to
be strings, or integers, or whatever, you can replace object with whatever
the type is. Otherwise just go with object[] and iterate through...

 

[Peter Duniho]

Overload the function.

For example:

void MyMethod(int required, int optional)
{
}

void MyMethod(int required)
{
MyMethod(required, 0 /* put correct default value here */);
}

I would say that the reply from "pedrito" is more suitable in what one
would consider a "variable parameter list". That is, it's not so much
that a given parameter is optional as it is that you don't even know in
advance what the parameters would be (eg similar to the CRT printf()
function).

I would stick to overloading rather than the more complicated variable
parameter list unless you really need the general-purpose behavior that
the "params object[]" technique provides.

Pete

 

[pedrito]

Overload the function.

Chris.

Ah, that too... I was thinking in terms of an indeterminate number of
parameters....

 

[pedrito]

Overload the function.

For example:

void MyMethod(int required, int optional)
{
}

void MyMethod(int required)
{
MyMethod(required, 0 /* put correct default value here */);
}

I would say that the reply from "pedrito" is more suitable in what one
would consider a "variable parameter list". That is, it's not so much
that a given parameter is optional as it is that you don't even know in
advance what the parameters would be (eg similar to the CRT printf()
function).

Exacto!

I would stick to overloading rather than the more complicated variable
parameter list unless you really need the general-purpose behavior that
the "params object[]" technique provides.

Yes!

 

[Chris Shepherd]

Ah, that too... I was thinking in terms of an indeterminate number of
parameters....

I hadn't considered that. To me optional was a VB keyword that you could
use in such cases (since it didn't support overloading), so I just
assumed that was what the OP was after.

Good call on covering all the bases though!

Chris.

 

[sloan]

I would not do this method of an array of objects.

Too much boxing and unboxing.

Look at this post as well.

http://groups.google.com/group/microsoft.public.dotnet.framework.aspnet/msg/f45b5081c9d62db3?hl=en&

public void MyMethod(params object[] myParams)
{
}

Then just iterate through params. If you know all the arguments are going
to be strings, or integers, or whatever, you can replace object with
whatever the type is. Otherwise just go with object[] and iterate
through...

I'll ask, how do you do it?

--
(i''ll be asking a lot of these, but I find C# totally way cooler than vb
and there''s no go''n back!!!)
thanks (as always)

kes

 

[Jon Skeet [C# MVP]]

I would not do this method of an array of objects.

Too much boxing and unboxing.

There's only boxing and unboxing involved if you use value types.
Anyway, boxing and unboxing aren't *that* expensive: if params ended up
being the most readable solution and you weren't in a performance
critical situation (and let's face it, most situations *aren't*
performance critical) then I wouldn't deem the performance hit of
boxing and unboxing to be relevant to the decision.

 

[pedrito]

I would not do this method of an array of objects.

Too much boxing and unboxing.

There are 2 axioms to program optimization that you should always keep in
mind.

1> 95% of the time is spent in 5% of the code. This is generally pretty
accurate. A little extra time spent calling a function that only gets called
a few times won't make a bit of difference.

2> That 5% of the code is rarely where you expect it to be.

Sometimes it is, but I'm often surprised to find that my time is spent in a
function that I didn't realize would be time consuming. Sometimes I'm not
surprised, and part of that has to do with how much time one has spent
optimizing code. As with anything else, more experience tends to make you
better at it.

Unless someone says they need time-critical code, I rarely consider it in my
answers.

I NEVER consider boxing and unboxing unless something is really time
critical. It's such a convenience and it's really not all that time
consuming.

 

[pedrito]

I hadn't considered that. To me optional was a VB keyword that you could
use in such cases (since it didn't support overloading), so I just assumed
that was what the OP was after.

Good call on covering all the bases though!

Chris.

Well, C++ has optional parameters as well. That is, you can assign default
values to parameters and if they're not passed, then they'll get the
default. I kind of miss it in C# because you end up creating various
overrides that all just end up calling the method with the most parameters
and assigning defaults. It'd be nice (and cleaner in the code) if the
compiled just did it for you, I think.

 

[Jon Skeet [C# MVP]]

Well, C++ has optional parameters as well. That is, you can assign default
values to parameters and if they're not passed, then they'll get the
default. I kind of miss it in C# because you end up creating various
overrides that all just end up calling the method with the most parameters
and assigning defaults. It'd be nice (and cleaner in the code) if the
compiled just did it for you, I think.

One alternative if you've got lots of parameters is to encapsulate them
as properties in a class. This is made particularly simple with C# 3's
object initalizer syntax. You can do:

CallSomeMethod (new SomeMethodParameters { First=10, Third=20 })

(that will leave Second as its default value, assuming parameters of
First, Second and Third).