Can't to real Double to Integer cast in VB.NET?!?

[Samuel R. Neff]

We've been doing a little experimenting and it seems VB.NET doesn't
have a direct equivalent to a C# double to integer cast.

Dim d as Double = 2.5#
Dim i as Integer = CType(d, Integer)

Is decompiled to

double d = 2.5;
int i = (int)Math.Round(d);

and

Dim d as Double = 2.5#
Dim i as Integer = CType(Math.Floor(d),Integer)

Is decompiled to

double d = 2.5;
int i = (int)Math.Round(Math.Floor(d));
So how the heck can you do a straight cast in VB.NET? DirectCast
doesn't work on value types and the CType functions always add a
Math.Round call. CInt(d) gives same results as CType(d, Integer).

The Convert.ToInt32() function also does rounding.

Thanks,

Sam

[chanmmn]

If you get 2 in your integer then is nothing wrong because integer is not
supposed to have decimal.

chanmm

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:a3********************************@4ax.com...

We've been doing a little experimenting and it seems VB.NET doesn't
have a direct equivalent to a C# double to integer cast.

Dim d as Double = 2.5#
Dim i as Integer = CType(d, Integer)

Is decompiled to

double d = 2.5;
int i = (int)Math.Round(d);

and

Dim d as Double = 2.5#
Dim i as Integer = CType(Math.Floor(d),Integer)

Is decompiled to

double d = 2.5;
int i = (int)Math.Round(Math.Floor(d));
So how the heck can you do a straight cast in VB.NET? DirectCast
doesn't work on value types and the CType functions always add a
Math.Round call. CInt(d) gives same results as CType(d, Integer).

The Convert.ToInt32() function also does rounding.

Thanks,

Sam

[Peter Huang [MSFT]]

Hi

I think this is VB.NET's feature.

Conversions that are mostly pure IL statements. The best example here is
the conversion from Double to Integer. This compiles down to a call to
Math.Round and then a conv.i4.ovf instruction. The purpose of the extra
call is to implement banker's rounding, which the CLR doesn't natively
support. (In banker's rounding, a decimal number equidistant between two
whole numbers is rounded to the nearest even number. So 3.5 rounds to 4,
but 2.5 rounds to 2.) In this case, calling Convert.ToInt32(Double) is not
the same as CInt(Double), and you have to choose which semantic you desire.

Conversion operators in VB
http://www.panopticoncentral.net/arc...6/07/1200.aspx

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Samuel R. Neff]

But doesn't adding that Math.Round operation remove our options on how
to handle conversions and add extra unnecessary function calls and
processing? Certainly for someone working in both languages, it's
very confusing that a cast in C# does something different than a
"cast" in VB.NET.

Furthermore, the additional round operation adds extra functionality
and processing time that may be totally unnecessary. Take for example
this code:

C#:

int i = (int)2.5#;

VB.NET

Dim i as Integer = CType(Math.Floor(2.5),Integer)

In the C# case it's a cast so we know the decimal will be truncated
and i will have 2. in VB.NET, we have to know that CType does weird
non-standard casting behavior by adding a round function and therefore
have to call Floor ourselves before doing the conversion.
Furthermore, since we called Math.Floor() the call to Math.Round()
which is added by the compiler is totally useless--the result from
Math.Floor is already integral, it's just stored as a floating point
value.

Sam

On Wed, 26 Jan 2005 01:45:34 GMT, v-******@online.microsoft.com
("Peter Huang" [MSFT]) wrote:

Hi

I think this is VB.NET's feature.

Conversions that are mostly pure IL statements. The best example here is
the conversion from Double to Integer. This compiles down to a call to
Math.Round and then a conv.i4.ovf instruction. The purpose of the extra
call is to implement banker's rounding, which the CLR doesn't natively
support. (In banker's rounding, a decimal number equidistant between two
whole numbers is rounded to the nearest even number. So 3.5 rounds to 4,
but 2.5 rounds to 2.) In this case, calling Convert.ToInt32(Double) is not
the same as CInt(Double), and you have to choose which semantic you desire.

Conversion operators in VB
http://www.panopticoncentral.net/arc...6/07/1200.aspx

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Chris Dunaway]

The only way I could find to get rid of the call to Math.Round was to
use Convert.ToInt32 instead, but the IL was still not the same as the
C# code. I turned integer overflow checsk off as well.

[Herfried K. Wagner [MVP]]

"Samuel R. Neff" <bl****@newsgroup.nospam> schrieb:

Furthermore, the additional round operation adds extra functionality
and processing time that may be totally unnecessary. Take for example
this code:

C#:

int i = (int)2.5#;

VB.NET

Dim i as Integer = CType(Math.Floor(2.5),Integer)

I think the VB language designers weighted cost and value of this feature,
and then decided to add it to VB. I have never heard any complains about VB
rounding implicitly the way it does, so I would conclude that this
discussion is rather academical.

Just my 2 Euro cents...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Peter Huang [MSFT]]

Hi Samuel,

I agree with Herfried's suggestion.

Based on my understanding, although VB and C# are essentially language
alternatives for writing .NET applications. There is still a little that
differentiates the two on a feature by feature as well as development
experience basis. Over time, VB and C# will diverge, and each will
continue to develop their own personalities specifically targeted toward
their respective customer bases.

VB will not match C# feature by feature, although quite often, features
will appear in both. VB will differentiate on the low end, while C# will
differentiate on the high end. VB will have more features targeted at
simplifying application development, while C# will have power features
which may be complicated to use and understand. From a development
experience perspective, VB will focus on designing applications and adding
code secondarily, while C# will probably focus on writing code first.
Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter Huang [MSFT]]

Hi Samuel,

I agree with Herfried's suggestion.

Based on my understanding, although VB and C# are essentially language
alternatives for writing .NET applications. There is still a little that
differentiates the two on a feature by feature as well as development
experience basis. Over time, VB and C# will diverge, and each will
continue to develop their own personalities specifically targeted toward
their respective customer bases.

VB will not match C# feature by feature, although quite often, features
will appear in both. VB will differentiate on the low end, while C# will
differentiate on the high end. VB will have more features targeted at
simplifying application development, while C# will have power features
which may be complicated to use and understand. From a development
experience perspective, VB will focus on designing applications and adding
code secondarily, while C# will probably focus on writing code first.
Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Cor Ligthert]

Peter,

Is that the reason that
dim a as double = 99/50 *1
is more precise than
double a = 99/50 * 1;

:-)

As well can you tell me what you mean with this

VB will differentiate on the low end, while C# will differentiate on the
high end.

I think that it would be in your message, "The attitude from a VBNet
programmer is often that he starts using the designer tools provided by
Visual Studio Net to become productive, while the C# programmer has often an
attitude to ignore those".

Or did you mean something else?

Cor

[Cor Ligthert]

Peter,

Is that the reason that
dim a as double = 99/50 *1
is more precise than
double a = 99/50 * 1;

:-)

As well can you tell me what you mean with this

VB will differentiate on the low end, while C# will differentiate on the
high end.

I think that it would be in your message, "The attitude from a VBNet
programmer is often that he starts using the designer tools provided by
Visual Studio Net to become productive, while the C# programmer has often an
attitude to ignore those".

Or did you mean something else?

Cor

[Samuel R. Neff]

Thanks Peter, that's a good explanation and about what I expected.
Unfortunately the client's requiring VB.NET in this case so I'm stuck,
but will certainly stick to C# whenever I have the option.

Before taking the contract I researched all of the many threads about
VB.NET vs C# and they almost always boiled down to they're the same
language that compile to the same MSIL so there is no difference.
After using VB.NET for a few months, that appears not to be the case
and it's clear that VB.NET provides an easier experience by limiting
or providing non-standard functionality.

Best regards,

Sam
On Thu, 27 Jan 2005 02:09:54 GMT, v-******@online.microsoft.com
("Peter Huang" [MSFT]) wrote:

Hi Samuel,

I agree with Herfried's suggestion.

Based on my understanding, although VB and C# are essentially language
alternatives for writing .NET applications. There is still a little that
differentiates the two on a feature by feature as well as development
experience basis. Over time, VB and C# will diverge, and each will
continue to develop their own personalities specifically targeted toward
their respective customer bases.

VB will not match C# feature by feature, although quite often, features
will appear in both. VB will differentiate on the low end, while C# will
differentiate on the high end. VB will have more features targeted at
simplifying application development, while C# will have power features
which may be complicated to use and understand. From a development
experience perspective, VB will focus on designing applications and adding
code secondarily, while C# will probably focus on writing code first.
Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Samuel R. Neff]

Thanks Peter, that's a good explanation and about what I expected.
Unfortunately the client's requiring VB.NET in this case so I'm stuck,
but will certainly stick to C# whenever I have the option.

Before taking the contract I researched all of the many threads about
VB.NET vs C# and they almost always boiled down to they're the same
language that compile to the same MSIL so there is no difference.
After using VB.NET for a few months, that appears not to be the case
and it's clear that VB.NET provides an easier experience by limiting
or providing non-standard functionality.

Best regards,

Sam
On Thu, 27 Jan 2005 02:09:54 GMT, v-******@online.microsoft.com
("Peter Huang" [MSFT]) wrote:

Hi Samuel,

I agree with Herfried's suggestion.

Based on my understanding, although VB and C# are essentially language
alternatives for writing .NET applications. There is still a little that
differentiates the two on a feature by feature as well as development
experience basis. Over time, VB and C# will diverge, and each will
continue to develop their own personalities specifically targeted toward
their respective customer bases.

VB will not match C# feature by feature, although quite often, features
will appear in both. VB will differentiate on the low end, while C# will
differentiate on the high end. VB will have more features targeted at
simplifying application development, while C# will have power features
which may be complicated to use and understand. From a development
experience perspective, VB will focus on designing applications and adding
code secondarily, while C# will probably focus on writing code first.
Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Cor Ligthert]

Samuel,

Maybe are you searching for the Fix
dim a as integer = fix(1.9999999999999)

Gives the value 1

One problem, it will not work with option strict on.

Cor

[Cor Ligthert]

Samuel,

Maybe are you searching for the Fix
dim a as integer = fix(1.9999999999999)

Gives the value 1

One problem, it will not work with option strict on.

Cor

[Samuel R. Neff]

No, I'm not looking for a function call to get the value that I want,
I'm look for a away to do a cast without an unnecessary function call.

Thanks for the suggestion though..

Sam
On Thu, 27 Jan 2005 17:33:55 +0100, "Cor Ligthert"
<no************@planet.nl> wrote:

Samuel,

Maybe are you searching for the Fix
dim a as integer = fix(1.9999999999999)

Gives the value 1

One problem, it will not work with option strict on.

Cor

[Samuel R. Neff]

No, I'm not looking for a function call to get the value that I want,
I'm look for a away to do a cast without an unnecessary function call.

Thanks for the suggestion though..

Sam
On Thu, 27 Jan 2005 17:33:55 +0100, "Cor Ligthert"
<no************@planet.nl> wrote:

Samuel,

Maybe are you searching for the Fix
dim a as integer = fix(1.9999999999999)

Gives the value 1

One problem, it will not work with option strict on.

Cor

[Cor Ligthert]

Samuel,

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

In my opinion is for every type conversion is a function done, so what is
than "an unnecessary function call" I have not the idea that the fix does
baciscly something else than a type conversion except that you use the word
cast for a typeconversion.

Not that I find it the most elegant solution with that option strict of.

Cor

[Cor Ligthert]

Samuel,

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

In my opinion is for every type conversion is a function done, so what is
than "an unnecessary function call" I have not the idea that the fix does
baciscly something else than a type conversion except that you use the word
cast for a typeconversion.

Not that I find it the most elegant solution with that option strict of.

Cor

[Herfried K. Wagner [MVP]]

"Cor Ligthert" <no************@planet.nl> schrieb:

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

Didn't you read the whole thread? C# will use the 'conv.i4' IL instruction
to convert the double to an 'Int32' while VB.NET will additionally call
'System.Math.Round'.

..NET Framework Class Library -- 'OpCodes.Conv_I4' Field
<URL:http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemReflectionEmitOpCodesClassConv_I4Topic. asp>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

"Cor Ligthert" <no************@planet.nl> schrieb:

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

Didn't you read the whole thread? C# will use the 'conv.i4' IL instruction
to convert the double to an 'Int32' while VB.NET will additionally call
'System.Math.Round'.

..NET Framework Class Library -- 'OpCodes.Conv_I4' Field
<URL:http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemReflectionEmitOpCodesClassConv_I4Topic. asp>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert]

Herfried,

I don't understand that "unecessary", when you see how many instructions
there are used only because a property is used instead of direct a field,
than I don't botter about about a cycle more or less (as I stated in the C#
newsgroup the minimum we think about on computers to use in .Net enviroment
is .5 Ghz).

(And that is not even my old statement where I always say that with every
move of the cursor on a screen there are more cycles done than in normal
situations are done in a year with this kind of programmaparts)

I was disapointed by the way that you did not come with that "fix". It is
much more yours than mine.

I am not such a microsoftvisual basic guy.

Cor
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:eb**************@TK2MSFTNGP09.phx.gbl...

"Cor Ligthert" <no************@planet.nl> schrieb:

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

Didn't you read the whole thread? C# will use the 'conv.i4' IL
instruction to convert the double to an 'Int32' while VB.NET will
additionally call 'System.Math.Round'.

.NET Framework Class Library -- 'OpCodes.Conv_I4' Field
<URL:http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemReflectionEmitOpCodesClassConv_I4Topic. asp>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Cor Ligthert]

Herfried,

I don't understand that "unecessary", when you see how many instructions
there are used only because a property is used instead of direct a field,
than I don't botter about about a cycle more or less (as I stated in the C#
newsgroup the minimum we think about on computers to use in .Net enviroment
is .5 Ghz).

(And that is not even my old statement where I always say that with every
move of the cursor on a screen there are more cycles done than in normal
situations are done in a year with this kind of programmaparts)

I was disapointed by the way that you did not come with that "fix". It is
much more yours than mine.

I am not such a microsoftvisual basic guy.

Cor
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:eb**************@TK2MSFTNGP09.phx.gbl...

"Cor Ligthert" <no************@planet.nl> schrieb:

I'm look for a away to do a cast without an unnecessary function call.

You make me curious, what do yo mean with "a cast without an unnecessary
function call".

Didn't you read the whole thread? C# will use the 'conv.i4' IL
instruction to convert the double to an 'Int32' while VB.NET will
additionally call 'System.Math.Round'.

.NET Framework Class Library -- 'OpCodes.Conv_I4' Field
<URL:http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemReflectionEmitOpCodesClassConv_I4Topic. asp>

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Peter Huang [MSFT]]

Hi Cor,

You may take a look at link, I think this is because the VB target on
different scenario, e.g. the Banking rounding which is necessary for
Banking business.
Conversion operators in VB
http://www.panopticoncentral.net/arc...6/07/1200.aspx

I think you are right to some extent. VB.NET will target on the user that
will develop for RAD development usually they just use the designer more
than the coding. While C# programmer is similar with C++ which will write
code to do precise control, although VB can do that also.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter Huang [MSFT]]

Hi Cor,

You may take a look at link, I think this is because the VB target on
different scenario, e.g. the Banking rounding which is necessary for
Banking business.
Conversion operators in VB
http://www.panopticoncentral.net/arc...6/07/1200.aspx

I think you are right to some extent. VB.NET will target on the user that
will develop for RAD development usually they just use the designer more
than the coding. While C# programmer is similar with C++ which will write
code to do precise control, although VB can do that also.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter Huang [MSFT]]

Hi

Based on my experience, the additional call may not cause heavy performance
hit, of course invoke the additional call will add the operation time.
Also C# will be an alternative in this scenario, but I think if you did not
get obvious performance issue which is caused by the issue, we do not need
to care it.

If you still have any concern, please feel free to post here.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter Huang [MSFT]]

Hi

Based on my experience, the additional call may not cause heavy performance
hit, of course invoke the additional call will add the operation time.
Also C# will be an alternative in this scenario, but I think if you did not
get obvious performance issue which is caused by the issue, we do not need
to care it.

If you still have any concern, please feel free to post here.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Cor Ligthert]

Peter,

Now we agree again.

Although I think that (only) the banking rounding was a misser from
Microsoft (which will be corrected in the next version).

The style from C# is in my opinion because that is legacy and for one
company impossible to change. In that has the VB style language an advantage
on C languages. Not that I see any reason for that change by the way.

I did look at your links however I find this two better

Code C# and VB
http://www.harding.edu/USER/fmccown/...omparison.html

More general and than search the thirth "Cint" to get what I mean
http://msdn.microsoft.com/library/de...tinternals.asp

:-)

Cor

[Cor Ligthert]

Peter,

Now we agree again.

Although I think that (only) the banking rounding was a misser from
Microsoft (which will be corrected in the next version).

The style from C# is in my opinion because that is legacy and for one
company impossible to change. In that has the VB style language an advantage
on C languages. Not that I see any reason for that change by the way.

I did look at your links however I find this two better

Code C# and VB
http://www.harding.edu/USER/fmccown/...omparison.html

More general and than search the thirth "Cint" to get what I mean
http://msdn.microsoft.com/library/de...tinternals.asp

:-)

Cor

[Cor Ligthert]

>

I am not such a microsoftvisual basic guy.

namespace user guy

:-)

Cor

[Cor Ligthert]

>

I am not such a microsoftvisual basic guy.

namespace user guy

:-)

Cor

[Samuel R. Neff]

You're right, in a practical sense the extra call isn't waisting too
many cycles.. you'd have to be calling it a few million times to
notice, and we're only calling it a few hundred thousand times. :-)

But it's also an issue of attitude towards the languages and this type
of things makes it very clear that VB.NET is not on par with C# in
MS's own eyes (or more accurately, VB.NET developers are not on par
with C# developers and thus need the extra help--which is only true as
long as MS continues to perpetuate the myth by assuming intent and
allowing for such laziness).

Regarding the type of rounding (banker vs others) I really hope in the
future that the CLR will implement something similar to what's in the
new J2SE5 spec--they provide an enum to control rounding with 8
different rounding options.

Best regards,

Sam
On Fri, 28 Jan 2005 02:13:15 GMT, v-******@online.microsoft.com
("Peter Huang" [MSFT]) wrote:

Hi

Based on my experience, the additional call may not cause heavy performance
hit, of course invoke the additional call will add the operation time.
Also C# will be an alternative in this scenario, but I think if you did not
get obvious performance issue which is caused by the issue, we do not need
to care it.

If you still have any concern, please feel free to post here.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Samuel R. Neff]

You're right, in a practical sense the extra call isn't waisting too
many cycles.. you'd have to be calling it a few million times to
notice, and we're only calling it a few hundred thousand times. :-)

But it's also an issue of attitude towards the languages and this type
of things makes it very clear that VB.NET is not on par with C# in
MS's own eyes (or more accurately, VB.NET developers are not on par
with C# developers and thus need the extra help--which is only true as
long as MS continues to perpetuate the myth by assuming intent and
allowing for such laziness).

Regarding the type of rounding (banker vs others) I really hope in the
future that the CLR will implement something similar to what's in the
new J2SE5 spec--they provide an enum to control rounding with 8
different rounding options.

Best regards,

Sam
On Fri, 28 Jan 2005 02:13:15 GMT, v-******@online.microsoft.com
("Peter Huang" [MSFT]) wrote:

Hi

Based on my experience, the additional call may not cause heavy performance
hit, of course invoke the additional call will add the operation time.
Also C# will be an alternative in this scenario, but I think if you did not
get obvious performance issue which is caused by the issue, we do not need
to care it.

If you still have any concern, please feel free to post here.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Chris Dunaway]

Can you provide an example of the syntax for using that? How would you
specify the rounding when doing a cast?

[Peter Huang [MSFT]]

Hi

Thanks for your feedback. :)
Also you may also try to submit it to the mswish website and we will evalue
it and keep improving our product!
Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.