C#'s sneaky typedef
-
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.
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary>();
FTFY Just to ensure that nobody use your
dictto find a way to a cathouse. Or something like that. BTW. I'd like to have this syntax:Dictionary<String, IList<DataColumn>> dict = new();
I'd have information on type in a more logical place and could concentrate on parameters passed to a constructor. And still no doubling.
Greetings - Jacek
-
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary>();
FTFY Just to ensure that nobody use your
dictto find a way to a cathouse. Or something like that. BTW. I'd like to have this syntax:Dictionary<String, IList<DataColumn>> dict = new();
I'd have information on type in a more logical place and could concentrate on parameters passed to a constructor. And still no doubling.
Greetings - Jacek
-
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary>();
FTFY Just to ensure that nobody use your
dictto find a way to a cathouse. Or something like that. BTW. I'd like to have this syntax:Dictionary<String, IList<DataColumn>> dict = new();
I'd have information on type in a more logical place and could concentrate on parameters passed to a constructor. And still no doubling.
Greetings - Jacek
Looks nice, but violates the (already violated) rule that the type of an expression is determined by its parts, not by the context in which it appears. Of course that rule is already broken by integer constants.. and null cheats with its "null type" that is implicitly convertible to many types. So I don't know.
-
Looks nice, but violates the (already violated) rule that the type of an expression is determined by its parts, not by the context in which it appears. Of course that rule is already broken by integer constants.. and null cheats with its "null type" that is implicitly convertible to many types. So I don't know.
-
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?