|
|
Thanks for reading and voting it up
|
|
|
|
|
you are wellcome 
|
|
|
|
|
|
|
This should be posted in Tips & Tricks. I did not vote
|
|
|
|
|
Several errors have been fixed, but it's still far from being precise.
|
|
|
|
|
thanks for reading can you plz tell the errors so that i can update it
|
|
|
|
|
p.1.var: Just a remark, you don't need to put a real object to a var variable:
var x = (string)null;
I've already written:
"And if we speak about performance in p.4, then it should mention that dynamic variables are obviously the most expensive, since they require a lot of run-time code for call target resolution, verification and execution, while casting object to another type is almost free."
I still think that you should either denote the performance hit related to dynamic, or remove performance note from object section. Otherwise it's not a fair comparison.
There are typos in p.3/dynamic and p.3/var: "function also can return dynamic object type", "function can not return var object type"
Moreover, I'm sure that the article misses the key point: there are types of instances and types of variables which are different things. The trick is, only object can be an instance type, but neither dynamic, nor var. There are not such types as System.Var or System.Dynamic wherever in the CLR. But all 3 can be used as variable types.
This leads to questions about casting. Casting relates to instance types only. So, speaking about casting dynamic or var doesn't make much sense: the first is an object actually, while the second has the type of its initial value.
On the other hand, you still may need casting when assigning to a variable declared as var:
var a = 1;
int? b = 2;
a = b;
But since var is actually just a placeholder for a compiler-derived type and is equivalent to declaring a strongly-typed variable, you may harness all built-in and user-defined cast operators and conversions (like implicit operator X to cast smth. to type X)
Furthermore, when assigning to dynamic, you actually are casting:
dynamic a = 1;
dynamic b = "qwe";
And some more difficult examples:
var a = 1;
dynamic b = a;
a = b
var c = (object)null;
c = a;
a = c;
b = "qwe";
c = 1.3m;
b = c;
c = b;
|
|
|
|
|
|
|
"Var type can not be passed as function argument and function can not return object type"
I would say something different:
Var type can not be used in a function argument declaration...
because the first sentence is ambiguous, like in the following situation:
var x = 5.0;
SomeMethod(x);
You can say that a var has been passed as a function argument. The second sentence is more explicit about the real constraint:
void SomeMethod(var x)
Best regards,
Jaime.
|
|
|
|
|
The article is poor. I won't touch the language quality of the article, although it's rather poor English. I will cover technical errors. In my comment, quotations will start with [x.n] tags which mean 'column x (Object|Dynamic|Var), row n'.
[Object.2] Compiler has little information about the type
That's not absolutely true. The compiler has all information about the variable type - it knows that it's System.Object. It might not know the type of the instance the variable holds reference to, but the same is true for a variable of any type referencing an instance of a child type. In any case, compiler knows the type and verifies our code according to that information - it will only allow us use the System.Object members safely.
[Dynamic.2] It's compiler safe i.e compiler has all information about the stored value
Totally wrong. Compiler has no information on the referenced instance. It compiles dynamic variables into local variables of type System.Object in Common Intermediate Language (CIL). The reason why the compiler will never issue an error when calling methods of a dynamic variable is that it doesn't care. When I define a dynamic variable, I tell the compiler 'Hey, I don't want you to resolve the call target at compile-time, I want you to generate code which will do that at run-time.' dynamic keyword shifts usually statically typed c# towards dynamically typed languages like JavaScript, Python, Ruby, etc.
[Dynamic.2] so that it doesn't cause any issue at run-time.
Again totally wrong. A call on a dynamic variable will generate run-time target resolution code which will throw an exception if the call target cannot be resolved. That's a huge caveat of dynamically typed languages - you won't know if your code is wrong until you test all code paths.
[Var.2] Compiler doesn't have any information about the this type of variable.
Wrong. var is not even a variable type. It's a keyword that makes the compiler define the type of a variable implicitly based on the knowledge of the type of the initial value of the variable. Writing
var i = 1;
instead of
int i = 1;
just means 'Hey, compiler, I want you to analyze the initial value of the i and determine its type'. In CIL, however, both cases will compile into a variable of type System.Int32. Moreover, the following will compile:
dynamic x = 0;
var y = x;
y.CallMethodThatDoesntExist();
[Dynamic.3] Dynamic type can be passed as function argument and function also can return object type
Supposedly, the sentence should read as 'Dynamic type can be passed as function argument and function also can return dynamic type'.
Well, technically it's true, but developer must realize that dynamic cannot be passed as function argument, because CIL doesn't know such a type. It's object that is passed to a function, since a dynamic variable is an object variable with static code verification turned off. The only difference is that there will be DynamicAttributes attached to parameters and return value to indicate their dynamic nature. But still, another .NET language that doesn't know about dynamic typing might see that a method
dynamic M(dynamic x){...}
is actually a
object M(object x){...}
[Var.3] Var type can not be passed as function argument and function can not return object type. This type of variable can work in the scope where it defined.
Again, this should read as 'Var type can not be passed as function argument and function can not return var type. This type of variable can work in the scope where it defined.'
I would rephrase this. A var variable can be passed into a method, because the compiler will infer the actual variable type, but you cannot define a method that takes a var parameter or returns a var.
[Object.4] Require to cast object variable to original type before using it
Well, I can cast it to any type. The only thing is that if the instance type doesn't inherit from or imlements the cast target, I will get an InvalidCastException.
[Object.4] So this assigning to object type and converting to original type called as Boxing and Un-Boxing.
Wrong. It's called 'Type Casting' and can be applied from any type and to any type. Boxing/unboxing relates only to value types. The difference is that when casting types, we just get a new reference to the same object, without affecting the object. But when boxing/unboxing, we move a value type instance from stack to heap or vice-versa, which means physical copying of the instance data between 2 memory regions.
[Object.4] It's actually increasing the overhead when we do this both operation.
Yes, it includes a couple of additional CPU instructions, but I wouldn't pay attention to this fact. Far worse problem is that when you use object variables and type casting, you cannot rely on the compiler to check your code. You won't know if your code is correct until you test all code paths. (From this point of view, using too many object variables is similar to using too many dynamic variables)
[Var.6] Useful when getting result out of the linq queries.
Well, not only. It's most useful when we work with anonymous types anywhere, because we cannot declare a variable of an anonymous type, so we have to declare it as var. And anonymous types are now used increasingly wide: RX library (IObservables and IQbservables), various DAL frameworks (LINQ to SQL, Entity Framework (well, this is LINQ), NHibernate), etc.
|
|
|
|
|
about point 2 its updated now I am checking about the other points.
point 4 is updated
point 6 usefulness of var type that I wrote the linq its true that i can be used the others well but i wrote where it is most useful and purpose of the introducing type in the framework.
|
|
|
|
|
p.2 is correct now, I agree. I understand that you've simply misplaced the two table cells, but at first I was surprised by the mistake.
p.4 is still not good: boxing/unboxing is related to value types. The term 'primitive' is not widely and unambigously used. MSDN and best books (e.g. 'C# N Unleashed') tend to use 'built-in types'. But built-in types are not only value types like System.Int32. System.String and System.Object are also built-in types, but they are reference types and they cannot be boxed or unboxed.
And if we speak about performance in p.4, then it should mention that dynamic variables are obviously the most expensive, since they require a lot of run-time code for call target resolution, verification and execution, while casting object to another type is almost free.
I agree with you on p.6. I didn't mean you were wrong there, I just extended your answer.
|
|
|
|
|
Good one.I like the way you explain and comparision  however i have one question:-
For 'Var' you written:-
1.Compiler doesn't have any information about the this type of variable.
2.No need to cast because compiler has all information to perform operation.
3.Doesn't cause problem because compiler has all info about stored value.
Don't you think so they are contradictory statement and even if 1 point is correct could you please explain how then it work for point 2 and point 3 ? 
Regards,
Anil Saran
|
|
|
|
|
Anil_Saran - hey its misplaced now its updated................
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
