String or string?
-
CDP1802 wrote:
Classes are reference types, (many) aliases are treated like value types.
Nope. There is absolutely no difference between using the type name (
Int32) and the alias (int). They are exactly the same thing. They compile to the same IL.int x = new int();
Int32 y = 42;
Console.WriteLine($"{x}, {y}");
// Output: 0, 42Java differentiates between the primitive types and their reference type equivalents. In .NET, there is no difference. It sounds like whoever wrote that book was confused, and managed to spread the confusion. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
We already got that sorted out, I think. Int32 is not a class, it's a struct. Now it makes sense and you are right. It makes no difference.
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 fucking 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. -
CDP1802 wrote:
Then I'm right what String and string are concerned
Nope again. :)
Stringandstringare exactly the same - an immutable reference type. The only reason you don't typically need to usenewwith a string is because the compiler has a deep knowledge of it. string.cs - Reference Source[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Drat! :-)
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 fucking 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. -
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
I used to do the same,
string variableandString.Format(...)andint variableandInt32.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 simplifyStringtostringandInt32toint... Thanks Microsoft, for sticking to your own guidelines :~ For the same reason I stopped usingthisandbase(unless necessary) andTheClassImIn.StaticMethodinstead of simplyStaticMethod. And yes, I know I can turn off those rules, but I like sticking to defaults :)Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
There is a tiny difference, remember? Classes are reference types while the aliases are made to appear like value types for convenience.
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 fucking 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.No, there is no difference.
-
We already got that sorted out, I think. Int32 is not a class, it's a struct. Now it makes sense and you are right. It makes no difference.
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 fucking 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.structs are also classes... (PIEBALD exits quickly...)
-
No, there is no difference.
Ok, then it's time to do some reading.
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 fucking 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. -
PIEBALDconsult wrote:
What I find crazy is that when specifying the underlying type for an enumeration, you must use the alias. X|
Not if you're using the Roslyn (C# 6 / VS2015) compiler:
enum Foo : Int32
{
Bar,
Baz,
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
No thanks. I prefer to write backward-compatible code unless there's a real reason to do otherwise.
-
structs are also classes... (PIEBALD exits quickly...)
I know, but they are not treated as reference types and ... I have a better idea. here its past 11 PM now. Do you have something to drink?
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 fucking 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. -
Even though we use the String, Int32, etc... correctly per Microsoft website, in VS, Intellisense will display suggestion "name can be simplified", "Show potential fixes", IDE0001 C# Name can be simplified. Isn't that "Show potential fixes" = there is a bug and here is the potential fix? Why Microsoft didn't fix it to clear this confusion? After all VS is Microsoft product right? Maybe there is a reason behind it, and we all going to like it ;P ;P ;P
Bryian Tan
I believe the reason it suggests to simplify the name is because
string,int, etc do not require theSystemnamespace include whileString,Int32, etc still do. It can help clean up your namespace includes if that file doesn't use theSystemnamespace for things other than simple types :thumbsup: 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 changeintto map toInt64in the future, for example. -
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
-
We already got that sorted out, I think. Int32 is not a class, it's a struct. Now it makes sense and you are right. It makes no difference.
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 fucking 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. -
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
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 anintcould 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 aStringin almost 10 years of C#. I always use thestringalias.Software Zen:
delete this; -
I believe the reason it suggests to simplify the name is because
string,int, etc do not require theSystemnamespace include whileString,Int32, etc still do. It can help clean up your namespace includes if that file doesn't use theSystemnamespace for things other than simple types :thumbsup: 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 changeintto map toInt64in the future, for example.Jon McKee wrote:
They could transparently change
intto map toInt64in the future, for exampleThey could, but won't. There are way too many things that would go crash-bang-BOOM if they did.
Software Zen:
delete this; -
I used to do the same,
string variableandString.Format(...)andint variableandInt32.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 simplifyStringtostringandInt32toint... Thanks Microsoft, for sticking to your own guidelines :~ For the same reason I stopped usingthisandbase(unless necessary) andTheClassImIn.StaticMethodinstead of simplyStaticMethod. And yes, I know I can turn off those rules, but I like sticking to defaults :)Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
Jon McKee wrote:
They could transparently change
intto map toInt64in the future, for exampleThey could, but won't. There are way too many things that would go crash-bang-BOOM if they did.
Software Zen:
delete this; -
I believe the reason it suggests to simplify the name is because
string,int, etc do not require theSystemnamespace include whileString,Int32, etc still do. It can help clean up your namespace includes if that file doesn't use theSystemnamespace for things other than simple types :thumbsup: 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 changeintto map toInt64in the future, for example.Well, if someone ports .net to an 8-bit OS...
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
-
They are, just read the documentation! Both implement IComparable and IComparable<T>. They implement some other interfaces too, like IEquatable and IConvertible.
Best, Sander arrgh.js - Bringing LINQ to JavaScript SQL Server for C# Developers Succinctly Object-Oriented Programming in C# Succinctly
-
When writing my C# code I was in the habit of using string (all lowercase) for strings declarations, etc. and String (capitalized) for method calls such as String.Empty and String.Format just as a sort of aide memoir that I was calling an object method. As I started to create String extension methods I reviewed this habit of mine and decided this was a pointless differentiation and switched to just using string all the time. At the same time I decided that my using Int32 for methods such as Int32.TryParse and just int in declarations, etc. was also pointless and perhaps confusing to others and so switched to using int all the time instead. It all compiles to the same IL code anyway so it was just a matter of style really. What do you think?
- I would love to change the world, but they won’t give me the source code.
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!
-
Cornelius Henning wrote:
I believe at some point in the past this was the case??
Nope, never. It's just an alias.
string
Visual Studio .NET 2003
The string type represents a string of Unicode characters. string is an alias for System.String in the .NET Framework.:thumbsup:
