C#'s sneaky typedef
-
I don't think that's really a rule any more. What's the type of the lambda
x => x + 1? You can't tell without looking at the calling context. -
I haven't used var except where essential in almost 10 years. :-D
Why 10 years? Var was introduced with C# 3.0, which was released about 6 years ago. I hope you weren't trying to use it before then. :doh:
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
-
I haven't used var except where essential in almost 10 years. :-D
Simon O'Riordan from UK wrote:
I haven't used var except where essential in almost 10 years.
Wow, you must be really advanced. When I took C# training in 2005 var never came up and I read the manuals from cover to cover and never saw the command. I was under the impression it was introduced in 2005. (I can easily be totally wrong about that.) When is it ever essential? There is always:
object x = ...
-
I don't like it except in type declaration plus initialise statements ... there's no point doubling up the type information in
var dict = new Dictionary<String, IList<DataColumn>>();
But of course one of the places you can't use it is in field declarations which is where you want to do that a lot! It's also a bit ugly writing code that saves a Linq query if you declare the type (IQueryable<T>, right?). It seems to be standard to use var there, although I've been known to put the actual type instead.
-
Why 10 years? Var was introduced with C# 3.0, which was released about 6 years ago. I hope you weren't trying to use it before then. :doh:
Long ago, in a galaxy far far away, was something called Visual Basic.
-
Simon O'Riordan from UK wrote:
I haven't used var except where essential in almost 10 years.
Wow, you must be really advanced. When I took C# training in 2005 var never came up and I read the manuals from cover to cover and never saw the command. I was under the impression it was introduced in 2005. (I can easily be totally wrong about that.) When is it ever essential? There is always:
object x = ...
It was present in Visual Basic. Before .Net was a squirt in a squirts imagination.
-
Long ago, in a galaxy far far away, was something called Visual Basic.
You are thinking of the VB.NET variant type, which is not the same thing as C#'s implicitly typed "var". In C#, a var variable will have a compile-time type defined by the type on the right hand side of the assignment. In VB.NET, a variant type can change at runtime (unlike in C#). However, VB.NET now has the ability to implicitly type variables, just as with C#'s var. However, I think in VB.NET, you just do that by leaving off the type (e.g.,
Dim x = 5). Variants are an abomination. Implicitly typed variables are necessary (e.g., for anonymous types), and can be nice (e.g., for very long type declarations). You can read more about implicitly typed variables here. The closest thing to VB.NET's variant type in C# would be a variable of type "Object". -
You are thinking of the VB.NET variant type, which is not the same thing as C#'s implicitly typed "var". In C#, a var variable will have a compile-time type defined by the type on the right hand side of the assignment. In VB.NET, a variant type can change at runtime (unlike in C#). However, VB.NET now has the ability to implicitly type variables, just as with C#'s var. However, I think in VB.NET, you just do that by leaving off the type (e.g.,
Dim x = 5). Variants are an abomination. Implicitly typed variables are necessary (e.g., for anonymous types), and can be nice (e.g., for very long type declarations). You can read more about implicitly typed variables here. The closest thing to VB.NET's variant type in C# would be a variable of type "Object".Ah, I see. Thanks for that. Agree, variants are awful; implicit typing? Doesn't sound too helpful for complex walkthrough's, although I love it in Python.
-
Ah, I see. Thanks for that. Agree, variants are awful; implicit typing? Doesn't sound too helpful for complex walkthrough's, although I love it in Python.
Not sure what you mean by "complex walkthroughs".
-
Not sure what you mean by "complex walkthroughs".
One job I had meant examining code by eye for the most part. Would have meant a lot of extra difficulty if the variables had not been explicitly declared. It was a mixture of VC6 and C# interop. The VC6 couldn't be unit tested, it was a 500,000 LOC chunk that could be run through the VS6 debugger, but not split up. Horrible code.
-
It was present in Visual Basic. Before .Net was a squirt in a squirts imagination.
Er, no it wasn't. VB 6 had variant's but that's a different and altogether more abhorrent kettle of fish[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Er, no it wasn't. VB 6 had variant's but that's a different and altogether more abhorrent kettle of fish[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Yes. We sorted all that out last week. Do try and keep up 007.
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
What's old is new. I found the following:
#define void int
in some C code when I started my current job.
Software Zen:
delete this; -
Simon O'Riordan from UK wrote:
I haven't used var except where essential in almost 10 years.
Wow, you must be really advanced. When I took C# training in 2005 var never came up and I read the manuals from cover to cover and never saw the command. I was under the impression it was introduced in 2005. (I can easily be totally wrong about that.) When is it ever essential? There is always:
object x = ...
Sorry for adding a late comment - couldn't let your "object x =" stand there. This is NOT the same as using var (because in C# var means "I don't want to type - compiler look it up", or "I have an anonymouse type the compiler will know it's name later - but I don't!". Where holding a value as it's base type (in C# object is the base type of all reference types) is a complete other story!
-
Sorry for adding a late comment - couldn't let your "object x =" stand there. This is NOT the same as using var (because in C# var means "I don't want to type - compiler look it up", or "I have an anonymouse type the compiler will know it's name later - but I don't!". Where holding a value as it's base type (in C# object is the base type of all reference types) is a complete other story!
johannesnestler wrote:
couldn't let your "object x =" stand
In no way did I intend to imply it was equivalent. I did mean to imply they are equivalent in the sense of "I'm too lazy to look up or care what object I am dealing with." I have to admit I am too lazy to look it up now, but if you are passed an object field and set "var x = field". I know the true class isn't ever lost, but is x now the true object type?
-
johannesnestler wrote:
couldn't let your "object x =" stand
In no way did I intend to imply it was equivalent. I did mean to imply they are equivalent in the sense of "I'm too lazy to look up or care what object I am dealing with." I have to admit I am too lazy to look it up now, but if you are passed an object field and set "var x = field". I know the true class isn't ever lost, but is x now the true object type?
The "var" thing in C# is often miss-interpreted. Because everyone thinks of runtime type identification (VB...). But in C# it's not - it's only syntactic sugar if you don't want to retype complicated Type-names like: Dictionary, List>>, but the compiler always knows what type it is - it's normal strong compile-time type checking. Even the IntelliSense knows the type. But there are situations it is neccessary: you - as the programmer - sometimes do not know which type an expression will give back (anonymouse types), but the compiler will create a class for the anonymouse type during compilation and can fill in the missing type instead of the var keywords - but again: AT COMPILE TIME. So in your example: object field = new SomeClass(); var x = field; will result in x interpreted as object not SomeClass. Don't mix that up with GetType() or typeof operator in c# - you can always ask an object for it's type - AT RUNTIME. This is an better example: object field1 = new SomeClass(); var field2 = new SomeClass(); Where for field1 you are holding a SomeClass-instance as a base class reference (everything derives from object) where field2 is totally equivalent to: SomeClass field2 = new SomeClass(); If you want my personal opinion: I just use it where needed (anonymouse types) or for LINQ (there you often have those ugly long typenames). For me it had another nice side-effect I didn't think of in the first place: If you have specific algorithms or snippets and used the var keyword instead of the real type, you get code that is great for copy-pasting arround. This sometimes helps to focus on the underlaying constructs - and it helped me "to see" how repetitive code can be unified. var regards = from reg in AllRegards where reg.Quality = "best" select new { Regards=reg, Quality=reg.Quality }; (this would be valid C# (LINQ) giving back an anonymouse type - you can not know it's Name, so use of var keyword is mandatory...)