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.Floo r(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****@newsgro up.nospam> wrote in message
news:a3******** *************** *********@4ax.c om...

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.Floo r(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.Floo r(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.m icrosoft.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****@newsgro up.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.Floo r(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