Optional Paramters- What really occurs?

[William Ryan]

I just picked up a copy of John Robbins' debugging book and started to look
at disassembled code. Anyway, I hate optional Parameters in VB, but I was
checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with only
static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell the
compiler to write some overloads for you. So, in the case of a Subroutine I
was looking at that had 15 optional parameters (and no, I didn't write it)
it looked like the IL was showing 15 overloaded methods. I'm by no means an
Expert, but if this is the case...am I right in that it's kind of scarry?
I mentioned this to the guy who wrote it and he said I'm off of my rocker.
According to him, this is one of the benefits of VB.NET over C# in that you
don't have to use extensive overloading and it's more efficient. From the
IL though, this looks like the opposite.

So without stirring a VB.NET vs. C# debate, am I write about this or am I
reading it wrong?

Thanks,

Bill

[Daniel O'Connell]

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look at disassembled code. Anyway, I hate optional Parameters in VB, but I was
checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with only static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell the compiler to write some overloads for you. So, in the case of a Subroutine I was looking at that had 15 optional parameters (and no, I didn't write it)
it looked like the IL was showing 15 overloaded methods. I'm by no means an Expert, but if this is the case...am I right in that it's kind of scarry?
I mentioned this to the guy who wrote it and he said I'm off of my rocker.
According to him, this is one of the benefits of VB.NET over C# in that you don't have to use extensive overloading and it's more efficient. From the
IL though, this looks like the opposite. From what I'm seeing from ildasm, the optional keyword doesn't provide
overloads (atleast not in this compiler), but instead inserts optional value
values directly into code.
I wrote this little program to play with optionals:
Module Module1
Sub Main()
Dim X As Class1 = New Class1
X.Cat(, "meow")
X.Dog()
End Sub
End Module
Class Class1
Public Function Cat(Optional ByVal S As String = "neko", Optional ByVal
sound As String = "Nyao") As Boolean
Console.WriteLi ne(S + sound)
End Function
Public Function Dog(Optional ByVal S As String = "inu") As Boolean
Console.WriteLi ne(S)
End Function
End Class

I then opened it in ildasm, it showed one instance each of Dog and Cat, and
the disassembled call line for X.Cat(,"Meow) was:
IL_0008: ldstr "neko"
IL_000d: ldstr "meow"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

for X.Dog() it was:
IL_0019: ldstr "inu"
IL_001e: callvirt instance bool VBOptionalTest. Class1::Dog(str ing)

the optional keyword appears to directly embed the values into the calling
code, making optional arguments value changes a binary breaking change.

I had heard this before, but this is the first time i've actually verified
it.
So without stirring a VB.NET vs. C# debate, am I write about this or am I
reading it wrong?

Thanks,

Bill

[Daniel O'Connell]

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look at disassembled code. Anyway, I hate optional Parameters in VB, but I was
checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with only static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell the compiler to write some overloads for you. So, in the case of a Subroutine I

Forgot to mention, I think it would have been better if the compiler did
generate overloads automatically instead of implicitly forcing the calling
code to embed the values, but I didn't design the langauge.
Can't say I'd be opposed to a C# optional parameter system that is simply a
shortcut to manually writing lots of overloads, assuming it was written
within bounds, but I wouldn't be particulary thrilled with the VB method.
Not to extol one language over the other, I just don't like this particular
design in any language, never have.
was looking at that had 15 optional parameters (and no, I didn't write it)
it looked like the IL was showing 15 overloaded methods. I'm by no means an Expert, but if this is the case...am I right in that it's kind of scarry?
I mentioned this to the guy who wrote it and he said I'm off of my rocker.
According to him, this is one of the benefits of VB.NET over C# in that you don't have to use extensive overloading and it's more efficient. From the
IL though, this looks like the opposite.

So without stirring a VB.NET vs. C# debate, am I write about this or am I
reading it wrong?

Thanks,

Bill

[William Ryan]

Daniel:

I totally appreciate the post. I don't have the IDE in front of me but
here's what I remember off of the top of my head. In your example for cat,
if you pass in "Neko" for S and nothing for sound, s:="Neko" or pass in
sound but not S, let alone make three calls, one with both params, one with
the first param but not the second, and one with the second param but not
the first, It looked like there were three different calls. I wish I had
the disassembly in front of me (and probably should quit posting until I do)
but it just seemed really weird b/c it looked like each of the cases was
being written differently. Let me check back when I get to wrok.

Thanks Again,

Bill

"Daniel O'Connell" <on******@comca st.net> wrote in message
news:dHK8b.3331 17$Oz4.122375@r wcrnsc54...

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look

at disassembled code. Anyway, I hate optional Parameters in VB, but I was checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with

only

static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell

the

compiler to write some overloads for you. So, in the case of a Subroutine I

was looking at that had 15 optional parameters (and no, I didn't write

it) it looked like the IL was showing 15 overloaded methods. I'm by no means an

Expert, but if this is the case...am I right in that it's kind of

scarry? I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in that

you

don't have to use extensive overloading and it's more efficient. From the IL though, this looks like the opposite.

From what I'm seeing from ildasm, the optional keyword doesn't provide
overloads (atleast not in this compiler), but instead inserts optional

value values directly into code.
I wrote this little program to play with optionals:
Module Module1
Sub Main()
Dim X As Class1 = New Class1
X.Cat(, "meow")
X.Dog()
End Sub
End Module
Class Class1
Public Function Cat(Optional ByVal S As String = "neko", Optional ByVal sound As String = "Nyao") As Boolean
Console.WriteLi ne(S + sound)
End Function
Public Function Dog(Optional ByVal S As String = "inu") As Boolean
Console.WriteLi ne(S)
End Function
End Class

I then opened it in ildasm, it showed one instance each of Dog and Cat, and the disassembled call line for X.Cat(,"Meow) was:
IL_0008: ldstr "neko"
IL_000d: ldstr "meow"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

for X.Dog() it was:
IL_0019: ldstr "inu"
IL_001e: callvirt instance bool VBOptionalTest. Class1::Dog(str ing)

the optional keyword appears to directly embed the values into the calling
code, making optional arguments value changes a binary breaking change.

I had heard this before, but this is the first time i've actually verified
it.

So without stirring a VB.NET vs. C# debate, am I write about this or am I reading it wrong?

Thanks,

Bill

[Michael Mayer]

As a further test, move Class1 into a dll. Leave your test "module" in a
separate .exe. Compile everything, copy the exe and dll to a new folder and
run it to prove it works. Then change the optional parameters in the dll
and copy this new dll over to the folder listed above. Do not move the .exe
(make sure you use the original one). If you run it, you'll find out that
you do not get the new defaults. That is, the default values are really
plugged into calling code (as shown in previous post). If you don't
recompile the calling code, it won't pick up the new defaults. Sometimes
this could be the desired behavior, but generally (IMO) if you are creating
new defaults, it's because you really want the default behavior to change.
With optional parameters you have to recompile everything, which may or may
not be a big undertaking (depends on if multiple vendors, etc).

To my understanding, this is why optional parameters were not included in
c#.

--
Mike Mayer
http://www.mag37.com/csharp/
mi**@mag37.com
"Daniel O'Connell" <on******@comca st.net> wrote in message
news:dHK8b.3331 17$Oz4.122375@r wcrnsc54...

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look

at disassembled code. Anyway, I hate optional Parameters in VB, but I was checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with

only

static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell

the

compiler to write some overloads for you. So, in the case of a Subroutine I

was looking at that had 15 optional parameters (and no, I didn't write

it) it looked like the IL was showing 15 overloaded methods. I'm by no means an

Expert, but if this is the case...am I right in that it's kind of

scarry? I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in that

you

don't have to use extensive overloading and it's more efficient. From the IL though, this looks like the opposite.

From what I'm seeing from ildasm, the optional keyword doesn't provide
overloads (atleast not in this compiler), but instead inserts optional

value values directly into code.
I wrote this little program to play with optionals:
Module Module1
Sub Main()
Dim X As Class1 = New Class1
X.Cat(, "meow")
X.Dog()
End Sub
End Module
Class Class1
Public Function Cat(Optional ByVal S As String = "neko", Optional ByVal sound As String = "Nyao") As Boolean
Console.WriteLi ne(S + sound)
End Function
Public Function Dog(Optional ByVal S As String = "inu") As Boolean
Console.WriteLi ne(S)
End Function
End Class

I then opened it in ildasm, it showed one instance each of Dog and Cat, and the disassembled call line for X.Cat(,"Meow) was:
IL_0008: ldstr "neko"
IL_000d: ldstr "meow"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

for X.Dog() it was:
IL_0019: ldstr "inu"
IL_001e: callvirt instance bool VBOptionalTest. Class1::Dog(str ing)

the optional keyword appears to directly embed the values into the calling
code, making optional arguments value changes a binary breaking change.

I had heard this before, but this is the first time i've actually verified
it.

So without stirring a VB.NET vs. C# debate, am I write about this or am I reading it wrong?

Thanks,

Bill

[Daniel O'Connell]

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:uk******** *****@TK2MSFTNG P11.phx.gbl...

Daniel:

I totally appreciate the post. I don't have the IDE in front of me but
here's what I remember off of the top of my head. In your example for cat, if you pass in "Neko" for S and nothing for sound, s:="Neko" or pass in
sound but not S, let alone make three calls, one with both params, one with the first param but not the second, and one with the second param but not
the first, It looked like there were three different calls. I wish I had
the disassembly in front of me (and probably should quit posting until I do) but it just seemed really weird b/c it looked like each of the cases was
being written differently. Let me check back when I get to wrok.
Hrmm, I'm curious about what you found, I added some extra calls (calling
Cat with both params, one of each, and no params all together) and the
resultant IL was:
IL_0008: ldstr "neko"
IL_000d: ldstr "Nyao"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0017: pop
IL_0018: ldloc.0
IL_0019: ldstr "neko"
IL_001e: ldstr "meow"
IL_0023: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0028: pop
IL_0029: ldloc.0
IL_002a: ldstr "Cat"
IL_002f: ldstr "Nyao"
IL_0034: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0039: pop
IL_003a: ldloc.0
IL_003b: ldstr "Cat"
IL_0040: ldstr "Meow"
IL_0045: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

Still showing the call to the same method with the same pattern. It is
curious, to say the least. I'm looking forward to seeing what it was you
found. Thanks Again, np
Bill

"Daniel O'Connell" <on******@comca st.net> wrote in message
news:dHK8b.3331 17$Oz4.122375@r wcrnsc54...

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look

at disassembled code. Anyway, I hate optional Parameters in VB, but I was checking them out to see what IL is created. I've done this before with Modules, and saw that <gasp> they behave just like sealed classes with

only

static members.

Anyway, it looks like Optional Parameters are nothing but a way to

tell

the

compiler to write some overloads for you. So, in the case of a Subroutine

I

was looking at that had 15 optional parameters (and no, I didn't write

it) it looked like the IL was showing 15 overloaded methods. I'm by no means

an

Expert, but if this is the case...am I right in that it's kind of

scarry? I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in

that you

don't have to use extensive overloading and it's more efficient. From the IL though, this looks like the opposite.

From what I'm seeing from ildasm, the optional keyword doesn't provide
overloads (atleast not in this compiler), but instead inserts optional

value

values directly into code.
I wrote this little program to play with optionals:
Module Module1
Sub Main()
Dim X As Class1 = New Class1
X.Cat(, "meow")
X.Dog()
End Sub
End Module
Class Class1
Public Function Cat(Optional ByVal S As String = "neko", Optional

ByVal

sound As String = "Nyao") As Boolean
Console.WriteLi ne(S + sound)
End Function
Public Function Dog(Optional ByVal S As String = "inu") As Boolean
Console.WriteLi ne(S)
End Function
End Class

I then opened it in ildasm, it showed one instance each of Dog and Cat,

and

the disassembled call line for X.Cat(,"Meow) was:
IL_0008: ldstr "neko"
IL_000d: ldstr "meow"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

for X.Dog() it was:
IL_0019: ldstr "inu"
IL_001e: callvirt instance bool VBOptionalTest. Class1::Dog(str ing)

the optional keyword appears to directly embed the values into the calling code, making optional arguments value changes a binary breaking change.

I had heard this before, but this is the first time i've actually verified it.

So without stirring a VB.NET vs. C# debate, am I write about this or

am I reading it wrong?

Thanks,

Bill

[Jay B. Harlow [MVP - Outlook]]

Daniel,
Check out the IL function definition itself. The parameters in the IL have
the [opt] attribute on them.

..method public static bool Cat([opt] string S,
[opt] string sound) cil managed
{
.param [1] = "neko"
.param [2] = "Nyao"
// Code size 16 (0x10)
.maxstack 2
.locals init ([0] bool Cat)

Hope this helps
Jay

"Daniel O'Connell" <on******@comca st.net> wrote in message
news:LD******** **********@rwcr nsc51.ops.asp.a tt.net...

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:uk******** *****@TK2MSFTNG P11.phx.gbl...

Daniel:

I totally appreciate the post. I don't have the IDE in front of me but
here's what I remember off of the top of my head. In your example for

cat,

if you pass in "Neko" for S and nothing for sound, s:="Neko" or pass in
sound but not S, let alone make three calls, one with both params, one

with

the first param but not the second, and one with the second param but not

the first, It looked like there were three different calls. I wish I had the disassembly in front of me (and probably should quit posting until I

do)

but it just seemed really weird b/c it looked like each of the cases was
being written differently. Let me check back when I get to wrok.

Hrmm, I'm curious about what you found, I added some extra calls (calling
Cat with both params, one of each, and no params all together) and the
resultant IL was:
IL_0008: ldstr "neko"
IL_000d: ldstr "Nyao"
IL_0012: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0017: pop
IL_0018: ldloc.0
IL_0019: ldstr "neko"
IL_001e: ldstr "meow"
IL_0023: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0028: pop
IL_0029: ldloc.0
IL_002a: ldstr "Cat"
IL_002f: ldstr "Nyao"
IL_0034: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)
IL_0039: pop
IL_003a: ldloc.0
IL_003b: ldstr "Cat"
IL_0040: ldstr "Meow"
IL_0045: callvirt instance bool VBOptionalTest. Class1::Cat(str ing,
string)

Still showing the call to the same method with the same pattern. It is
curious, to say the least. I'm looking forward to seeing what it was you
found.

Thanks Again,

np

Bill

"Daniel O'Connell" <on******@comca st.net> wrote in message
news:dHK8b.3331 17$Oz4.122375@r wcrnsc54...

"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..
> I just picked up a copy of John Robbins' debugging book and started to look
> at disassembled code. Anyway, I hate optional Parameters in VB, but I

was

> checking them out to see what IL is created. I've done this before with > Modules, and saw that <gasp> they behave just like sealed classes

with only
> static members.
>
> Anyway, it looks like Optional Parameters are nothing but a way to

tell the
> compiler to write some overloads for you. So, in the case of a

Subroutine

I
> was looking at that had 15 optional parameters (and no, I didn't write it)

> it looked like the IL was showing 15 overloaded methods. I'm by no

means

an
> Expert, but if this is the case...am I right in that it's kind of

scarry?

> I mentioned this to the guy who wrote it and he said I'm off of my

rocker.

> According to him, this is one of the benefits of VB.NET over C# in that you
> don't have to use extensive overloading and it's more efficient.

From

the

> IL though, this looks like the opposite.
From what I'm seeing from ildasm, the optional keyword doesn't provide
overloads (atleast not in this compiler), but instead inserts optional

value

values directly into code.
I wrote this little program to play with optionals:
Module Module1
Sub Main()
Dim X As Class1 = New Class1
X.Cat(, "meow")
X.Dog()
End Sub
End Module
Class Class1
Public Function Cat(Optional ByVal S As String = "neko", Optional

ByVal

sound As String = "Nyao") As Boolean
Console.WriteLi ne(S + sound)
End Function
Public Function Dog(Optional ByVal S As String = "inu") As Boolean
Console.WriteLi ne(S)
End Function
End Class

I then opened it in ildasm, it showed one instance each of Dog and

Cat, and

the disassembled call line for X.Cat(,"Meow) was:
IL_0008: ldstr "neko"
IL_000d: ldstr "meow"
IL_0012: callvirt instance bool

VBOptionalTest. Class1::Cat(str ing, string)
for X.Dog() it was:
IL_0019: ldstr "inu"
IL_001e: callvirt instance bool VBOptionalTest. Class1::Dog(str ing)
the optional keyword appears to directly embed the values into the

calling code, making optional arguments value changes a binary breaking change.
I had heard this before, but this is the first time i've actually verified it.
>
> So without stirring a VB.NET vs. C# debate, am I write about this or

am

I

> reading it wrong?
>
> Thanks,
>
> Bill
>
>

[Jay B. Harlow [MVP - Outlook]]

William,

I mentioned this to the guy who wrote it and he said I'm off of my rocker.
According to him, this is one of the benefits of VB.NET over C# in that you don't have to use extensive overloading and it's more efficient. From the I would think overloading would be more efficient! (depending on are you
defining efficiency to be code size or speed).

If I have a function that has 15 optional parameters, and I call that
function with 1 parameter 50 times. All 50 times all 15 parameters need to
be pushed on the stack, which causes my assembly to be larger. Where as with
overloading all 50 calls would push 1 parameter, which would be smaller
code. Now most of my functions with overloaded parameters would only have 1
to 3 parameters that they are overloaded on, which I would suspect would
cause those functions to be in-lined by the JIT. Hence I would expect that
with overloaded I get smaller assemblies, plus the 'same' efficiency as the
optionals...

If you actually have a function with 15 overloaded parameters I would
suggest the Introduce Parameter Object Refactoring:
http://www.refactoring.com/catalog/i...terObject.html

Just a thought
Jay
"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. .. I just picked up a copy of John Robbins' debugging book and started to look at disassembled code. Anyway, I hate optional Parameters in VB, but I was
checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with only static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell the compiler to write some overloads for you. So, in the case of a Subroutine I was looking at that had 15 optional parameters (and no, I didn't write it)
it looked like the IL was showing 15 overloaded methods. I'm by no means an Expert, but if this is the case...am I right in that it's kind of scarry?
I mentioned this to the guy who wrote it and he said I'm off of my rocker.
According to him, this is one of the benefits of VB.NET over C# in that you don't have to use extensive overloading and it's more efficient. From the
IL though, this looks like the opposite.

So without stirring a VB.NET vs. C# debate, am I write about this or am I
reading it wrong?

Thanks,

Bill

[William Ryan]

Jay:

I don't use the things, but a co-worker and friend of mine uses them
extensively. As a matter of fact, I think some of those functions he has
use more like 20-30 optionals. I'm going the check out your article
reference right now...thanks. In these regards, I usually just pass in one
object or structure that has the values I want, but different people code
differently.

Thanks again

Billl
"Jay B. Harlow [MVP - Outlook]" <Ja********@ema il.msn.com> wrote in message
news:eC******** ******@TK2MSFTN GP10.phx.gbl...

William,

I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in that you

don't have to use extensive overloading and it's more efficient. From the I would think overloading would be more efficient! (depending on are you
defining efficiency to be code size or speed).

If I have a function that has 15 optional parameters, and I call that
function with 1 parameter 50 times. All 50 times all 15 parameters need to
be pushed on the stack, which causes my assembly to be larger. Where as with overloading all 50 calls would push 1 parameter, which would be smaller
code. Now most of my functions with overloaded parameters would only have 1 to 3 parameters that they are overloaded on, which I would suspect would
cause those functions to be in-lined by the JIT. Hence I would expect that
with overloaded I get smaller assemblies, plus the 'same' efficiency as the optionals...

If you actually have a function with 15 overloaded parameters I would
suggest the Introduce Parameter Object Refactoring:
http://www.refactoring.com/catalog/i...terObject.html

Just a thought
Jay
"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to look

at disassembled code. Anyway, I hate optional Parameters in VB, but I

was checking them out to see what IL is created. I've done this before with
Modules, and saw that <gasp> they behave just like sealed classes with

only

static members.

Anyway, it looks like Optional Parameters are nothing but a way to tell

the

compiler to write some overloads for you. So, in the case of a Subroutine I

was looking at that had 15 optional parameters (and no, I didn't write

it) it looked like the IL was showing 15 overloaded methods. I'm by no means an

Expert, but if this is the case...am I right in that it's kind of

scarry? I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in that

you

don't have to use extensive overloading and it's more efficient. From the IL though, this looks like the opposite.

So without stirring a VB.NET vs. C# debate, am I write about this or am I reading it wrong?

Thanks,

Bill

[Jay B. Harlow [MVP - Outlook]]

William,

I don't use the things, but a co-worker and friend of mine uses them
extensively. In VB6 I used optional parameters all the time, in VB.NET I favor Overloaded
parameters. For the reasons I listed earlier.
In these regards, I usually just pass in one
object or structure that has the values I want, You already understand the Introduce Parameter Object ;-)

Jay
"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:O3******** ******@tk2msftn gp13.phx.gbl... Jay:

I don't use the things, but a co-worker and friend of mine uses them
extensively. As a matter of fact, I think some of those functions he has
use more like 20-30 optionals. I'm going the check out your article
reference right now...thanks. In these regards, I usually just pass in one object or structure that has the values I want, but different people code
differently.

Thanks again

Billl
"Jay B. Harlow [MVP - Outlook]" <Ja********@ema il.msn.com> wrote in message news:eC******** ******@TK2MSFTN GP10.phx.gbl...

William,

I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in that

you

don't have to use extensive overloading and it's more efficient. From the

I would think overloading would be more efficient! (depending on are you
defining efficiency to be code size or speed).

If I have a function that has 15 optional parameters, and I call that
function with 1 parameter 50 times. All 50 times all 15 parameters need to be pushed on the stack, which causes my assembly to be larger. Where as with

overloading all 50 calls would push 1 parameter, which would be smaller
code. Now most of my functions with overloaded parameters would only have 1

to 3 parameters that they are overloaded on, which I would suspect would
cause those functions to be in-lined by the JIT. Hence I would expect

that with overloaded I get smaller assemblies, plus the 'same' efficiency as

the

optionals...

If you actually have a function with 15 overloaded parameters I would
suggest the Introduce Parameter Object Refactoring:
http://www.refactoring.com/catalog/i...terObject.html

Just a thought
Jay
"William Ryan" <do********@nos pam.comcast.net > wrote in message
news:ud******** ********@TK2MSF TNGP12.phx.gbl. ..

I just picked up a copy of John Robbins' debugging book and started to

look

at disassembled code. Anyway, I hate optional Parameters in VB, but I was checking them out to see what IL is created. I've done this before

with Modules, and saw that <gasp> they behave just like sealed classes with

only

static members.

Anyway, it looks like Optional Parameters are nothing but a way to

tell the

compiler to write some overloads for you. So, in the case of a Subroutine

I

was looking at that had 15 optional parameters (and no, I didn't write

it) it looked like the IL was showing 15 overloaded methods. I'm by no means

an

Expert, but if this is the case...am I right in that it's kind of

scarry? I mentioned this to the guy who wrote it and he said I'm off of my rocker. According to him, this is one of the benefits of VB.NET over C# in

that you

don't have to use extensive overloading and it's more efficient. From

the IL though, this looks like the opposite.

So without stirring a VB.NET vs. C# debate, am I write about this or

am I reading it wrong?

Thanks,

Bill