|
Now it gets confusing. The MSDN does not mention any of this at first glance for the String class. They use string in their samples when they want to use it as a value type and describe how initializing a string with a literal leads to the generation of code that uses one of String's constructors in MISL.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Well it's built-in, so it's always going to be a bit odd.
Still, you can tell it's not a value type by cheating, if it was actually a value type it should be impossible to change the original, but as this experiment shows it is only made "impossible" by the immutability.
|
|
|
|
|
I have just gotten the answer to this little riddle. Int32 is a struct, not a class, while String really is a class and string is just treated as a value type.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
It's not even that it's being treated like a value type. The reason it can accept literals like that is because of an implicit conversion operator.
public class ImplicitString
{
public string Value { get; private set; }
public ImplicitString(string x)
{
Value = x;
}
public static implicit operator ImplicitString(string x)
{
return new ImplicitString(x);
}
}
ImplicitString s = "Hello.";
|
|
|
|
|
|
Forogar wrote: It all compiles to the same IL code anyway so it was just a matter of style really.
That's all that needs to be said, right?
Forogar wrote:
What do you think?
I think it's getting late on Friday afternoon and I'm already past the point where I can afford to waste the brain cells I'd need for something like this...
|
|
|
|
|
|
I believe the reason it suggests to simplify the name is because string, int, etc do not require the System namespace include while String, Int32, etc still do. It can help clean up your namespace includes if that file doesn't use the System namespace for things other than simple types  I'm sure there are other reasons to suggest simplification but that's the one that immediately comes to mind.
EDIT: Now that I think about it, in a way the simple names "decouple" the developer from the exact underlying type too. They could transparently change int to map to Int64 in the future, for example.
|
|
|
|
|
Jon McKee wrote: They could transparently change int to map to Int64 in the future, for example
They could, but won't. There are way too many things that would go crash-bang-BOOM if they did.
Software Zen: delete this;
|
|
|
|
|
True. More of a thought on possibility rather than implementation 
|
|
|
|
|
Well, if someone ports .net to an 8-bit OS...
|
|
|
|
|
I used to do the same, string variable and String.Format(...) and int variable and Int32.Parse(...).
There was a good reason I did that though, Microsoft recommended doing it!
Until I switched to Visual Studio 2015 and all of a sudden it started giving me "tips" to simplify String to string and Int32 to int...
Thanks Microsoft, for sticking to your own guidelines 
For the same reason I stopped using this and base (unless necessary) and TheClassImIn.StaticMethod instead of simply StaticMethod.
And yes, I know I can turn off those rules, but I like sticking to defaults
|
|
|
|
|
Great, if you think String and string and int and Int32 are comparable ....
modified 19-Jan-21 21:04pm.
|
|
|
|
|
They are, just read the documentation!
Both implement IComparable and IComparable<T>.
They implement some other interfaces too, like IEquatable and IConvertible.
|
|
|
|
|
I did not mean this Kind of comparable (IComparable etc)  I meant compare the two Scenarios 
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I know what you meant, I just to chose to interpret it differently 
|
|
|
|
|
So, this is the way you making fun of an old man
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Switch to Java. Problem solved
-NP
Never underestimate the creativity of the end-user
|
|
|
|
|
That's liked curing a headache by shooting yourself in the head!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Actually, that's where the problems begin. Lower and upper-case primitives in Java do completely different things.
|
|
|
|
|
I write process control applications, so I have to deal with lots of values that are defined as a particular number of bits in a network interface or a hardware register. For that reason I use Int32, UInt16, and so on. While I realize the chances of the aliases changing underlying type in .NET are effectively zero, I have too many battle scars from prior apps written in C. A variable declared as an int could be 16 bits, 32 bits, 64 bits, or something else.
That said, string's are another story entirely. Character sets, code pages, encoding, decoding, you still end up doing conversions of one sort or another regardless of your 'native' representation. I don't think I've ever declared a String in almost 10 years of C#. I always use the string alias.
Software Zen: delete this;
|
|
|
|
|
I think I will be explicit if the (Win) API is requiring an Int32, and non-specific in the code where I need an int.
One can change, the other will not.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Given all the confusion, I think I'll just override String and string, in future, with an array (which is all a string is meant to be, anyway).
I wanna be a eunuchs developer! Pass me a bread knife!
modified 18-Feb-17 9:30am.
|
|
|
|
|
What I find amusing is that VS2015 says that String.Empty can be simplified to string.Empty
Riiight.
Marc
|
|
|
|
|
Indeed a kind amusing. But if you claim this to MS the Chance is there that a over all "empty I can be everything" will be defined ... and after they will make c# a Java language. No, please not
modified 19-Jan-21 21:04pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Just kill it, PLEASE 
