Overload Resolution

N

Nick Hall

I'm getting what I think is a bug in the way the VB compiler determines the
correct overloaded method to call. I have written a class to wrap
System.Configuaration.ConfigurationSettings with some type-safe methods -
for instance two methods are : -

Public Overloads Shared Function GetInt32(ByVal key As String, ByVal
defaultValue As Integer) As Integer
....
End Function

Public Overloads Shared Function GetInt32(ByVal key As String, ByVal style
As NumberStyles) As Long
....
End Function

(There are several other overloads but these are the two that are causing me
grief)

To me, the logical way to call this from my application class would be as
follows: -

Private Shared ReadOnly s_MyInteger As Integer =
ConfigurationSettings.GetInt32("IntegerKey", 0) 'This calls
GetInt32(String, NumberStyles)!!

However, when I do this, the compiler binds to the overload that takes a
NumberStyles parameter instead of the one that takes an integer! This seems
crazy to me as you would think the compiler would favour an exact match over
one that requires a conversion. Using CInt or the I suffix does not alter
this behaviour. The only work around is to declare a constant or a variable
with a suitable value and pass that instead: -

Private Const blankValue As Integer = 0
Private Shared ReadOnly s_MyInteger As Integer =
ConfigurationSettings.GetInt32("IntegerKey", blankValue) 'This calls
GetInt32(String, Integer) CORRECT!

Am I correct in thinking this is a compiler bug or am I missing some
subtlety in the resolution rules?

Regards,

Nick Hall
 
N

Nick Hall

OK did this in completely the wrong order by posting here and THEN checking
Google :)

It would seem that this issue centres around the treatment of the value 0 by
the VB compiler in this situation. It would seem that VB treats it as an
implicit widening conversion in this case as 0 is the value that is
automatically assigned to an uninitialised enumeration variable. I've got a
work around for this issue right now but I would like to see this behaviour
(preferably) fixed or at least documented. This is especially the case
since there is no way to alter the compiler's decision (short of explicitly
passing variables/constants).

Regards,

Nick Hall
 

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

Top