page 1 of 3
Comments: 52 | Views: 1949
#Jun 19th @ 7:00 AM
Bas
Bas
It finds lightbulbs.
I know there's probably a really good reason for this, but I can't think of what it is, and it keeps bugging me. Why can't you do

int x = 10;
string y = (string)x;

in C#? I mean, you could simply use x.ToString(), but why doesn't the explicit cast do the same?
#Jun 19th @ 7:29 AM
littleguru
littleguru
allein, allein,... allein, allein!
Because the explicit cast isn't implemented... ToString() is a general method (implemented in System.Object) and if string would implement the cast that would beg the question if all other classes need to implement it too...
#Jun 19th @ 7:38 AM
Bas
Bas
It finds lightbulbs.
That's my point. Why isn't that cast implemented? Implementing it for all classes obviously wouldn't work, but why not all numeric value types? They implemented a ToString() method for all numeric value types too, after all. Why not use the same code to implement an explicit cast for those types?
#Jun 19th @ 7:43 AM
Sven Groot
Sven Groot
You can't have everything; after all, where would you put it?
I would guess it's because of locale and formatting issues. I never use CStr in VB because I'm just not quite sure what it'll end up doing.

I think this is the righ decision. Casts should be for straight type conversions, not for lexical conversions. That's just my opinion, though.
#Jun 19th @ 7:56 AM
Yggdrasil
Yggdrasil
Pour me a cab, 'cause I can't drink no more.
I'm with Sven here. Casts aren't conversions, even though they could be overloaded to provide the same semantics, I think it's confusing. Casts should be just changing the glasses with which you look at a given object, rather than creating a new, different object. Like the way it works with interfaces or base classes. I'm not even fond of casts for native numeric types, like narrowing long->int casts. I would rather have a myLong.ToInt32() method, which is more explicit and less confusing. You can even add a ThrowOnNarrowingConversion argument if you'd like.
As you mentioned, implementing it for every class can't work, so they'd rather keep a coherent interface with ToString() rather than have you wonder whether a given type has implemented the explicit (string) cast or not.
#Jun 19th @ 8:01 AM
littleguru
littleguru
allein, allein,... allein, allein!
That's also what I thought first... I only didn't write it because ToString() without parameters says also as much as a to-string-cast... But if we think about casts in general they are only there if you can easily convert types but not for things where you take external information into consideration to do the conversion; like cultural information etc.
#Jun 19th @ 9:25 AM
Bas
Bas
It finds lightbulbs.
Technically, those are good points. But in this particular case, I don't really see the harm What, exactly, could go wrong when providing syntactic sugar like (string)int from a pure convenience perspective?
#Jun 19th @ 10:08 AM
figuerres
figuerres
???
well int to string is probably the one case that would work 99% of the time...

but say it was a case of DateTime to string.....

thre are about a zillion possible formats to use and many of the would be wrong most of the time....

that's why.
#Jun 19th @ 11:37 AM
Bas
Bas
It finds lightbulbs.
Sure, for dates, and other more complex types. But what about just limiting it to numeric value types?
#Jun 19th @ 12:18 PM
littleguru
littleguru
allein, allein,... allein, allein!
I guess they wanted to keep the whole framework consistent and therefore didn't implement it... and, for me, one great plus of the .NET Framework is its consistency; you really see that all seem to have followed the guidelines... not like other frameworks *cough* java *cough*

Edit: you know to avoid questions like: why is this working on int and not on datetime etc.
#Jun 19th @ 12:30 PM
figuerres
figuerres
???

several reasons why ....

first off C# is not VB, some folks would howl and screem right there.

C family has always worked in a way that this case follows so this brings up a few questions like:

who would benefit? how much would they gain ?

what about explaining and teaching this to new programmers ?
very much an area that many would view as "not consistant" with the rest of the language.

also in what cases do you make it work / not work?

for example decimal, float and other numeric types when cast to a string might need to be formated as money
different cultures have different rules for that....
how does the compiler know what the right format is ??
how will it know what the runtime culture setting will be?
do you add that to the code you emit?
how much code does that add to the size of the dll / exe ?
how often will that be used if added (per call how often will the default work etc..)

even an int may need formating like "123,456"

granted you could "string it" then let the programmer parse the sting and then use it but then they would have been better off using a .ToString("") method in the first place.

so yes it might help with a few simple cases here and there but I think it would create more issues than it would solve.

it's part of why you and I still have a job... cause we can figure out which way to do this stuff  Smiley

#Jun 19th @ 12:37 PM
littleguru
littleguru
allein, allein,... allein, allein!
Your reply lacks two things:
1) it's not the compiler who casts, but you implement a method to do that.
2) ToString() of Int32 is also doing some magic behind the scenes and you also need the knowledge that it will use the default culture.

Still, I wouldn't do it because ToString() is more explicit and you can see that it comes with overloads whereas the cast is something that should only cover simple cases...
#Jun 19th @ 12:42 PM
Dexter
Dexter

I'll just answer with another question:

Why would you add another function (because explict casts are just functions anyway) that does exactly the same thing as ToString()?



And since I don't remember seeing a guideline about "explicit" we can take a look at the .NET Framework and see where it's most commonly used: Decimal, IntPtr, UIntPtr.

Why are these types using "explicit"? To allow casting to and from other numeric types. 
Is it OK that "explicit" is used? I'd say yes because conceptually all these types are just different implementations of a Number class so casting is done between "related" types.

Other cases of "explicit" in .NET Framework are Point <-> Size <-> Vector, Point3D <-> Size3D <-> Vector3D. Again we have strongly related types (so related that some other frameworks only have a Vector type).

The last case of "explict" usage is Nullable<T>. Needless to say, we have again a cast between related types.


Just my 2 (long) cents Smiley

#Jun 19th @ 2:37 PM
Matthew van Eerde
Matthew van Eerde
AKA Maurits
Does
    string y = "" + x;
work?
#Jun 19th @ 4:15 PM
Dexter
Dexter
That works. By dubious means.

The compiler tends to replace s1 + s2 + s3 ... with a call to String.Concat(s1, s2, s3...). String.Concat also has an overload which takes objects so you can concatenate a string with pretty much anything at the cost of boxing any involved value types. Better do x.ToString().
#Jun 19th @ 5:16 PM
figuerres
figuerres
???

In any case it comes back to the same thing.

better to know what your conversion is doing than to guess.

and Casts are best for very basic / well defined types like number widening, or truncation

like

int16 y= 1024;

// super size me
 Int64  x = (Int64)y;

#Jun 22nd @ 6:39 PM
evildictaitor
evildictaitor
How could you use the adjective "indescribable" truthfully?
There are those of us who work in compilers who strangle programmers who write things like that because it translates to

ldstr ""
ldtemp [x]
callvirt int32.ToString()
callvirt String.Concat()
sttemp [y]
#Jun 23rd @ 1:06 AM
Bas
Bas
It finds lightbulbs.
"Why would you add another function (because explict casts are just functions anyway) that does exactly the same thing as ToString()?"

For the same reason that you shouldn't just call Dispose() because you know that it'll just call Close() on the object. You should still call Close() before calling Dispose(), because you shouldn't rely on the fact that Dispose does exactly the same thing.

For the same reason, I don't like calling ToString() on an int to convert it. ToString() is used to provide a human readable string representation, for debugging purposes. Sure, it may return exactly what I want in this particular case, but should you really rely on that? Who says they won't return more information about the object than just the numeric value?
I'd rather use Convert.ToString(int) because contrary to int.ToString(), it's actually intended to be used that way. I have no way of knowing wether int.ToString() is going to return other information about the int than just its value, whereas Convert.ToString(int)'s purpose is to just return the int's value as a string.

Anyway, good points all round. I guess converting ints to strings is one of the things I do most, and I'm just clamoring for some syntactic sugar on it.

#Jun 23rd @ 1:09 AM
littleguru
littleguru
allein, allein,... allein, allein!
Then use Convert.ToString(Int32) Tongue Out
#Jun 23rd @ 1:12 AM
Bas
Bas
It finds lightbulbs.
I just edited my post to say that. Tongue Out I got Ninja'd!
#Jun 23rd @ 2:26 AM
littleguru
littleguru
allein, allein,... allein, allein!
You could implement an Extension Method to Int32: ToWellKnownString() Wink
#Jun 23rd @ 5:26 AM
evildictaitor
evildictaitor
How could you use the adjective "indescribable" truthfully?
While in general you can't rely on undocumented features, you can be absolutely 100% sure that Microso