What might the reason be that .net doesn't support this

[Tony Johansson]

If I want to convert a string to Int32 I can't use cast like this
string s = 10;
int number = (int)s;

but have to use parse or Convert like this
Convert.ToInt32(s) or
Int32.Parse(s)

So why does not .NET support casting like this
string s = 10;
int number = (int)s;

//tony

 

[Arne Vajhøj]

If I want to convert a string to Int32 I can't use cast like this
string s = 10;
int number = (int)s;

but have to use parse or Convert like this
Convert.ToInt32(s) or
Int32.Parse(s)

So why does not .NET support casting like this
string s = 10;
int number = (int)s;

The tradition in the C/C++/Java/C# family of languages
is that the cast:
- does a conversion of simple numeric types
- does a type change without changing the value for pointers/references

So this is the expected behavior.

Arne

 

[Marcel Müller]

So why does not .NET support casting like this
string s = 10;
int number = (int)s;

Because the conversion is ambiguous.
Representing an integer number as a string requires first of all a
number system. Using the decimal number system is common, but not the
only way.

The int <-> string conversion suggests itself more like some kind of
serialization.


Marcel

 

[Brian Cryer]

If I want to convert a string to Int32 I can't use cast like this
string s = 10;
int number = (int)s;

but have to use parse or Convert like this
Convert.ToInt32(s) or
Int32.Parse(s)

So why does not .NET support casting like this
string s = 10;
int number = (int)s;

Actually what you mean is why doesn't C# support this, because VB.Net does.
So in VB.Net you could write

dim s as string = "10"
dim number as integer = s

and it works fine. If anything it works a little too well, because it means
you can mix your types and not notice - until your string no longer contains
a number and then you get a runtime exception thrown. So, from experience I
would say that your code is logically cleaner and clearer if it isn't
supported and you have to do the conversion explicitly if that's what you
want.

As for why (int)s isn't supported - I think both Arnie and Marcel have good
points. Paraphrasing, Arne said that casting is between similar data types,
and Marcel that the conversion is ambiguous - which is why I often don't use
Convert.ToInt32 because it doesn't quite do what I want with the data I'm
using.

 

[bradbury9]

El viernes, 13 de julio de 2012 11:40:03 UTC+2, Brian Cryer escribió:

Actually what you mean is why doesn't C# support this, because VB.Netdoes.
So in VB.Net you could write

dim s as string = &quot;10&quot;
dim number as integer = s

and it works fine. If anything it works a little too well, because it means ...

It does work under certain conditions. If you put option strict on it does not compile. It is pretty well explained in this link http://support.microsoft.com/kb/311329/en

 

[Arne Vajhøj]

Because the conversion is ambiguous.
Representing an integer number as a string requires first of all a
number system. Using the decimal number system is common, but not the
only way.

Some languages do convert - by assuming decimal.

Example in PHP:

<?php
$s = '2';
$st = gettype($s);
$i = (int)$s;
$it = gettype($i);
echo "$st $s $it $i\r\n"
?>

Arne

 

[Marcel Müller]

Some languages do convert - by assuming decimal.

Example in PHP:

....

Of course, but they tend to convert unparseable strings as well. This is
error prone. And there are more drawbacks.
Converting "x" to int gives 0, converting "x" to boolean gives true,
converting "x" to int and then to boolean gives false.


Marcel

 

[Arne Vajhøj]

Actually what you mean is why doesn't C# support this, because VB.Net
does. So in VB.Net you could write

dim s as string = "10"
dim number as integer = s

and it works fine.

If VB.NET is told not to prevent that type of code.

But VB.NET has a heritage that are different from C#.

If anything it works a little too well, because it
means you can mix your types and not notice - until your string no
longer contains a number and then you get a runtime exception thrown.
So, from experience I would say that your code is logically cleaner and
clearer if it isn't supported and you have to do the conversion
explicitly if that's what you want.

int.TryParse would work the same way.

Only int.TryParse has a definition that encourage
handling of invalid input.

Arne

 

[Arne Vajhøj]

...

Of course, but they tend to convert unparseable strings as well. This is
error prone. And there are more drawbacks.
Converting "x" to int gives 0, converting "x" to boolean gives true,
converting "x" to int and then to boolean gives false.

PHP has a relative relaxed type system.



Arne