what is the use of over loaded functions.

  • Thread starter Thread starter veebhudhi.chandramouli
  • Start date Start date
V

veebhudhi.chandramouli

Instead of using same name i can use different name,
is there any specific purpous is there to define the polymorphic
overloaded functions in c#
 
Instead of using same name i can use different name,
is there any specific purpous is there to define the polymorphic
overloaded functions in c#

For constructors, you can't change the name to start with.
For everything else - it's just more convenient not to have to create
lots of different method names.

Look at the overloads for Console.WriteLine, for example - would you
really want that many different method names?

Jon
 
One use of overloaded is to provide default parameter values.

Consider a function that takes three parameters with one parameter being
the same for 90% of the calls.
You could overload that function with one that takes two parameters and
delegate the call to your original function providing the third value
yourself.

My 2c.
 
Am Mon, 30 Jul 2007 13:02:26 +0100 schrieb Mark Rae [MVP]:
It allows you to define different "versions" of the same function with
different signatures - other languages did something similar with optional
parameters, but C# doesn't, thank God!
Optional parameters:
Why do you prefer

void f ( int data )
void f ( int data, bool withLogging )
over

void f( int data, bool withLogging = false )

???
 
void f( int data, bool withLogging = false )

That isn't an optional parameter - it's a parameter with a default value...

Not the same thing at all!
 
That isn't an optional parameter - it's a parameter with a default value...

Not the same thing at all!

I certainly see the two as being equivalent. There's no point in
having a default value unless the parameter is optional, and if it's
optional then surely it needs a default value.

What's the practical difference between the two in your view?

Jon
 
I certainly see the two as being equivalent. There's no point in
having a default value unless the parameter is optional, and if it's
optional then surely it needs a default value.

What's the practical difference between the two in your view?

There's no practical difference, but an optional parameter (certainly in the
VB utilisation) doesn't actually have to exist...
 
There's no practical difference, but an optional parameter (certainly in the
VB utilisation) doesn't actually have to exist...

What exactly does that mean? What does a parameter which doesn't exist
look like?

Jon
 
Jon Skeet said:
What exactly does that mean? What does a parameter which doesn't exist
look like?

Private Sub Draw(Optional X As Variant, Optional Y As Variant)
If IsMissing(X) Then X = 720
If IsMissing(Y) Then Y = 2880
Cls
Circle (X, Y), 700
End Sub

Draw()
Draw(600)
Draw(600, 1500)
 
Private Sub Draw(Optional X As Variant, Optional Y As Variant)
If IsMissing(X) Then X = 720
If IsMissing(Y) Then Y = 2880
Cls
Circle (X, Y), 700
End Sub

Draw()
Draw(600)
Draw(600, 1500)

And what does that compile to in IL? Is "IsMissing" effectively the
same as "IsNothing" or whatever the VB terminology is? Does it work
for types other than Variant?

Jon
 
And what does that compile to in IL? Is "IsMissing" effectively the
same as "IsNothing" or whatever the VB terminology is?

I have no idea - that's actually an old bit of VB code - no idea at all if
it would work in VB.NET... :-)
Does it work for types other than Variant?

It didn't in VB...
 
I have no idea - that's actually an old bit of VB code - no idea at all if
it would work in VB.NET... :-)

Ah. Looking in MSDN for VB.NET, it specifies:

<quote>
Every optional parameter in the procedure definition must specify a
default value.
</quote>

So at least in VB.NET, they *are* the same thing after all. That's a
relief in terms of my mental model, at the very least :)
It didn't in VB...

I suspect that it was just a "default default" value which was the
equivalent of Nothing, or some singleton "missing value".

Jon
 
Jon said:
Ah. Looking in MSDN for VB.NET, it specifies:

<quote>
Every optional parameter in the procedure definition must specify a
default value.
</quote>

Yes, in fact "optional parameter" is a misleading term. I remember a
long thread back around 2000 in this ng, back when C# was new and some
people had a real issue with C# not having VB's concept of a so-called
"optional parameter" (and, indeed, VB.NET not supporting optional
parameters a la VB6). They aren't optional parameters but are hard-coded
default values.

IIRC, they are not fun to use because they are like a C# public const
variable vs. a readonly variable. With the former, the const value is
actually pulled out of the referenced assembly and inserted directly
into the consuming assembly; with the latter, a reference to the
readonly variable is deposited into the consuming assembly. Why is this
important. Well if you set your const to 12 and then change it to 13
then each and every assembly that references that public const must then
be recompiled to get the new 13 value. VB.NET's so-called optional
parameters work the same way. Avoid them! :-)

Here's what I could find with Google.

Real optional params (i.e., much of what has been discussed again in
this thread and real optional parameters with C#'s params keyword):

http://groups.google.com/group/micr...er+default+hard-coded&rnum=1#4be95c94bf945e2d

Pointed to from a thread in this ng - calling COM objects that have
optional parameters:

http://support.microsoft.com/default.aspx?scid=kb;en-us;305814

And I joined in the fray here:

http://groups.google.com/group/micr...rameter+default+glenn&rnum=1#fbfa58605ebd935e

Lastly, another thread I just read points out that VB.NET optional
parameters are not CLS-compliant so, for example, an optional parameter
to a VB.NET method would only be optional to other VB.NET code, to C#
and other non-VB.NET languages the parameter would not be optional.

HTH.
 
Ah. Looking in MSDN for VB.NET, it specifies:

<quote>
Every optional parameter in the procedure definition must specify a
default value.
</quote>

So at least in VB.NET, they *are* the same thing after all. That's a
relief in terms of my mental model, at the very least :)

I couldn't agree more! I always hated that whole VB "sloppiness"...
I suspect that it was just a "default default" value which was the
equivalent of Nothing, or some singleton "missing value".

No doubt.
 
Paul Werkowitz said:
Am Mon, 30 Jul 2007 13:02:26 +0100 schrieb Mark Rae [MVP]:
Optional parameters:
Why do you prefer

void f ( int data )
void f ( int data, bool withLogging )
over

void f( int data, bool withLogging = false )
And what about
void f(int data)
void f(int data, bool withLogging)
void f(int data, string loggingSource)

There are many similar examples in the CRL

Christof
 
Paul Werkowitz said:
Am Mon, 30 Jul 2007 13:02:26 +0100 schrieb Mark Rae [MVP]:
Optional parameters:
Why do you prefer

void f ( int data )
void f ( int data, bool withLogging )
over

void f( int data, bool withLogging = false )

???

Another Point:
In your second case the callee can't react on the missing parameter in a
more dynamic way, wich is possible with overloads aswell as with the VB
style optional parameters without default values.

Christof
 
Christof said:
And what about
void f(int data)
void f(int data, bool withLogging)
void f(int data, string loggingSource)

There are many similar examples in the CRL

Christof

Nothing wrong with doing that!

The pattern I use for this type of situation is like this:

public void f(int data)
: this(data, false, null) {}

public void f(int data, bool withLogging)
: this(data, withLogging, null) {}

public void f(int data, string loggingSource)
: this(data, true, loggingSource) {}

public void f(int data, bool withLogging, string loggingSource) {}

These are all basically convenience overloads for the caller.

The first one means "call f and don't do any logging at all."

The second one means "call f and log or don't depending on the
withLogging parameter's value; if withLogging is true log to the default
log source."

The third is "call f and log or don't log depending on the withLogging
parameter's value, and further if withLogging is true then log to the
source specified in loggingSource (unless the caller explicitly
specified null in which case log to the default log source)."

And sometimes the 4th one is private if I don't want to expose that
variant of the constructor. I also use this same pattern with method
overloads quite frequently as well.

There is a bit of an art to coming up with good, useful overloads and
not just overloading for the sake of it.
 
Christof said:
Another Point:
In your second case the callee can't react on the missing parameter in a
more dynamic way, wich is possible with overloads aswell as with the VB
style optional parameters without default values.

Christof

First off, VB.NET doesn't have optional parameters without defaults,
they must always have defaults. Are you referring to the optional
parameters as implemented by VB6 and earlier?

In either case, can you elaborate on what you mean by "can't react on
the missing parameter in a more dynamic way," since there are no missing
parameters in the f example, and I don't get what you mean. Thanks!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top