|
If your using .NET 3.5
Try to use XElement using System.Xml.Linq
its pretty easy, fast and convinient when compared to DOM
Regards,
Vythees
Miles to go before sleep...
|
|
|
|
|
Thanks Vythees,
I need to use .Net 2.0 in current project, do you have any suggestions?
regards,
George
|
|
|
|
|
Go for XMLDocument since its easy to maintain, futuristic, and supports XPath queries.
Regards,
Vythees
Miles to go before sleep...
|
|
|
|
|
Thanks Vythees,
What do you think the pros and cons compared with XMLDocument and XMLTextWriter from functional and performance perspective?
regards,
George
|
|
|
|
|
Hello everyone,
When dealing with value types, I met with two conflicting points,
1. We can not inherit one value type from another, for example, we can not make a struct inherit from another struct; -- I think it means there is no inheritance or derivation for value types.
2. All value types are inherits from ValueType, and ValueType is inherits from Object, seems value types could have inheritance or derivation?
How do you understand the two conflicting points? 
thanks in advance,
George
|
|
|
|
|
I haven tested it but Id guess that the restriction is in C#
While it might perfectly possible to inherit valuetypes in CIL code
There are other similair things you might find.
Eg delegates seems to be some sort of beast of their own in C#.
But in CIL they are just classes that derive from delegate..
|
|
|
|
|
Thanks Roger,
1.
Roger Alsing wrote: that the restriction is in C#
You mean the restriction is we can not derive one struct from another?
2.
Roger Alsing wrote: beast of their own in C#.
Why do you think delegate is beast of C#?
regards,
George
|
|
|
|
|
because it is simply a language construct (a C# one) that hides CIL details (i.e. standard class derivation and so on...). If I remember well, Andrew Troelsen calls it 'syntactic sugar'.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Do you agree with all value types are inherits from ValueType, and ValueType is inherits from Object, correct? I can not believe int and long are also inherits from ValueType/Object?
regards,
George
|
|
|
|
|
George_George wrote: I can not believe int and long are also inherits from ValueType/Object?
Of course they don't, see [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Great link! Why you can always find good stuff, do you have any magic powers?  
BTW, three further questions,
1.
"The .NET Framework defines built-in value types, such as System.Int32 and System.Boolean, which correspond and are identical to primitive data types used by programming languages."
"identical to primitive data types" means the same thing, just with a different name? For example, Int32 is the same as int, right?
2.
Only struct or Enum we defined are derived from ValueType/Enum, primitive types and the related equal types (e.g. Int32 to int do not derive from ValueType/Enum?
3.
"Value types do not have the overhead associated with storing an instance of a class and they do not require constructors." -- what is the overhead?
regards,
George
|
|
|
|
|
George_George wrote: Int32 is the same as int, right?
int refer to int32. long refer to int64.
George_George wrote: Only struct or Enum we defined are derived from ValueType/Enum, primitive types and the related equal types (e.g. Int32 to int do not derive from ValueType/Enum?
Int32 is a built-in value type which don't inherit from System.ValueType. System.ValueType is for programmers to create their own value types other than the built in one. Enum is a special value type which derives from System.Enum not System.ValueType.
George_George wrote: Value types do not have the overhead associated with storing an instance of a class and they do not require constructors." -- what is the overhead?
Most of the value types are kept in stack along with the values. So it is easy and fast to refer and pass. There is no overhead to clean up the resources. Means garbage collector need not function to clean up value types. It will be cleaned when scope ends.
|
|
|
|
|
Thanks N a v a n e e t h,
1.
N a v a n e e t h wrote: int refer to int32. long refer to int64.
"Refer to" means the same thing just with a different name (like macro in C) or?
2.
"For each value type, the runtime supplies a corresponding boxed type, which is a class that has the same state and behavior as the value type. Some languages require you to use special syntax when the boxed type is required; others automatically use the boxed type when it is needed. When you define a value type, you are defining both the boxed and the unboxed type."
What is the boxed type in C# for a value type? Always System.Object?
3.
When we use new to create an instance of a value type, like a struct, is it on heap or on stack -- like the same in the page shows?
http://msdn.microsoft.com/en-us/library/34yytbws(VS.71).aspx[^]
regards,
George
|
|
|
|
|
George_George wrote: "Refer to" means the same thing just with a different name
Yes
George_George wrote: What is the boxed type in C# for a value type? Always System.Object?
I guess, but not sure
George_George wrote: When we use new to create an instance of a value type, like a struct, is it on heap or on stack
This is most confusing part. Read this[^] to get an idea. There are several things that control the allocation.
|
|
|
|
|
Thanks N a v a n e e t h,
Great article!!
1.
I have answered the question by myself after reading it. It does not matter using new, what matters is whether the value type struct is in a reference type or standalone. In the MSDN sample, it is
standalone, and should be on stack, right?
http://msdn.microsoft.com/en-us/library/34yytbws(VS.80).aspx[^]
2.
In the link you referred, it is mentioned,
--------------------
There are a couple of exceptions to the above rules - captured variables (used in anonymous methods and lambda expressions) are local in terms of the C# code, but end up being compiled into instance variables in a type associated with the delegate created by the anonymous method. The same goes for local variables in an iterator block.
--------------------
I am confused about what means "The same goes for local variables in an iterator block."? )I have the knowledge about iterator and yield statement.)
regards,
George
|
|
|
|
|
George_George wrote: and should be on stack, right?
Yes, it should be on stack.
George_George wrote: "The same goes for local variables in an iterator block."?
Variables used with anonymous methods are compiled as instance variables and kept with the delegate type which created that. The same approach will be used for the local variables in an iterator block too, means it would be kept with the associated type.
|
|
|
|
|
Thanks N a v a n e e t h,
Sorry my English is not good. For the local variables in iterator, it will be expanded and chnaged to member variables of classes.
Since we are discussing stack/heap storage issues, does changing the local variable to member variable of a class will change the nature of the stack/heap location (I am confused about whether it impacts the variable itself or the real object the variable refers to)?
regards,
George
|
|
|
|
|
N a v a n e e t h wrote: Int32 is a built-in value type which don't inherit from System.ValueType
Huh? How did you find that out? Int32 of course inherits from ValueType - there's nothing special going on there.
N a v a n e e t h wrote: So it is easy and fast to refer and pass.
Easy, I don't know, but fast? Passing a value type with say, 5 fields, to a function, is definitely more expensive than passing a reference to a class (assuming the JITter doesn't do inlining).
|
|
|
|
|
George_George wrote: Great link! Why you can always find good stuff, do you have any magic powers?
Well, no Super-powers, see Iain Clarke sign to have some insight.
George_George wrote: BTW, three further questions,
N a v a n e e t h already gave very good answers.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
|
George_George wrote: the boxed type for all value type in C# are all System.Object?
The C# compiler simply emits the box[^] IL instruction - and that boxes it to an object of type System.Object.
|
|
|
|
|
Thanks Senthil,
Does it mean all value types of C# will be boxed to Object?
regards,
George
|
|
|
|
|
George_George wrote:
Does it mean all value types of C# will be boxed to Object?
Yes.
|
|
|
|
|
1)
Yes, the restriction exists in C# , not in the runtime.
2)
No delegates are nice.
But in C# they look like they are something different , c# provides special support for delegates.
while at CIL level, they are just classes that inherits from Delegate
|
|
|
|
|
Thanks Roger,
1. All value types are inherits from ValueType, and ValueType is inherits from Object, correct? I can not believe int and long are also inherits from ValueType/Object?
2. What do you mean "But in C# they look like they are something different , c# provides special support for delegates."? Any more description please?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
