|
George_George wrote: looks like we need to use DOM model, right?
Yes. XMLDocument use DOM. When file is loaded, it loads the entire file into memory. So if the file is very large, this method is inefficient. Calling Save() method on this class instance will save all the changes made to the instance.
George_George wrote: Any referred samples?
I think MSDN has enough documentation on using these classes. It's pretty easy.
|
|
|
|
|
Thanks N a v a n e e t h,
XMLTextWriter will not use DOM model and only loads necessary nodes other than all nodes (which is done in DOM model)?
regards,
George
|
|
|
|
|
George_George wrote: XMLTextWriter will not use DOM model and only loads necessary nodes other than all nodes
XMLTextWriter won't load any nodes. It is used to create XML documents. It has some methods which you can use to create nodes, attributes etc.
|
|
|
|
|
Sorry, N a v a n e e t h!
My bad, I mean XMLTextReader, it will not load the entire tree as DOM, like XMLDocument, and it will only loads necessary nodes, right?
regards,
George
|
|
|
|
|
Yes. It will not load the full file initially. XMLDocument class is also using a reader internally to fill the data.
|
|
|
|
|
Thanks N a v a n e e t h,
1.
So, can I understand that using XMLDocument has better performance compared with XMLTextReader, but bigger memory footprint.
2.
XMLDocument can both read/write, but XMLTextReader can only read, and XMLTextWriter can only write?
regards,
George
|
|
|
|
|
George_George wrote: So, can I understand that using XMLDocument has better performance compared with XMLTextReader, but bigger memory footprint.
This depends on the XML file size. When you call Load() method in an XMLDocument classes instance, it reads all the nodes and forms a DOM and keeps in the memory. So when the file is huge, it will consume more memory.
Performance is dependent of your scenario. If you need to read the XMLFile (not as DOM), XMLTextReader will give good performance. For creating a new xml file, XMLTextWriter will give good performance. Say, in a situation where you will add new nodes, change the attributes, and doing some XPath queries, then better choice would be XMLDocument class.
George_George wrote: XMLDocument can both read/write, but XMLTextReader can only read, and XMLTextWriter can only write?
XMLDocument class can do more than read/write. It supports XPath queries also.
|
|
|
|
|
Great N a v a n e e t h!
If I only need to read XML documents (in a file) into memory and get some values for some elements, then I think using XMLDocument will always have better performance, since all nodes are in memory (compared with XMLTextReader, only parts of nodes are in memory). Why do you think it is not always true?
regards,
George
|
|
|
|
|
George_George wrote: If I only need to read XML documents (in a file) into memory and get some values for some elements, then I think using XMLDocument will always have better performance
If the file size is less, you won't find any performance differences. XMLDocument provides an easy way to load and edit data. You can go with any methods which really suits your scenario.
|
|
|
|
|
Thanks N a v a n e e t h,
If the size of file is big, using XMLDocument is of better performance? 
regards,
George
|
|
|
|
|
You can use XMLTextWriter or XMLDocument. XMLTextWriter will be faster.
|
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
