You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xerces.apache.org by tn...@apache.org on 2001/06/12 23:10:08 UTC
cvs commit: xml-xerces/c/doc faq-parse.xml
tng 01/06/12 14:10:08
Modified: c/doc faq-parse.xml
Log:
Add two more FAQs.
Revision Changes Path
1.25 +53 -5 xml-xerces/c/doc/faq-parse.xml
Index: faq-parse.xml
===================================================================
RCS file: /home/cvs/xml-xerces/c/doc/faq-parse.xml,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- faq-parse.xml 2001/06/08 16:27:34 1.24
+++ faq-parse.xml 2001/06/12 21:10:07 1.25
@@ -288,7 +288,14 @@
</a>
</faq>
+ <faq title="Why do I get Internal Compiler Error when compiling xerces-c for a 64bit target with gcc?">
+ <q>Why do I get Internal Compiler Error when compiling xerces-c for a 64bit target with gcc?</q>
+ <a>
+ <p>This is a compiler problem. Try turning off optimization to bypass the problem.</p>
+ </a>
+ </faq>
+
<faq title="How are entity reference nodes handled in DOM?">
<q>How are entity reference nodes handled in DOM?</q>
@@ -602,12 +609,12 @@
<faq title="Why does deleting a transcoded string result in assertion on windows?">
<q>Why does deleting a transcoded string result in assertion on windows?</q>
<a>
- <p>Both your application program and the Xerces DLL must use the same *DLL* version of the
- runtime library. If either statically links to the runtime library, the
- problem will still occur.
+ <p>Both your application program and the Xerces DLL must use the same *DLL* version of the
+ runtime library. If either statically links to the runtime library, the
+ problem will still occur.
- For example, for a Win32/VC6 build, the runtime library build setting MUST
- be "Multithreaded DLL" for release builds and "Debug Multithreaded DLL" for
+ For example, for a Win32/VC6 build, the runtime library build setting MUST
+ be "Multithreaded DLL" for release builds and "Debug Multithreaded DLL" for
debug builds.</p>
</a>
</faq>
@@ -677,6 +684,47 @@
throw an exception.
</li>
</ul>
+ </a>
+ </faq>
+
+ <faq title="Why DOM_Node::cloneNode() does not clone the pointer assigned to a DOM_Node via DOM_Node::setUserData()?">
+ <q>Why DOM_Node::cloneNode() does not clone the pointer assigned to a DOM_Node via DOM_Node::setUserData()?</q>
+ <a>
+ <p>There are several possible options for how cloneNode should handle userData:
+ </p>
+ <ul>
+ <li>
+ 1) Copy the pointer. May be a Very Bad Idea if you really wanted the data
+ associated with a particular node object.
+ </li>
+ <li>
+ 2) Clone the object being pointed at. Maybe a Very Bad Idea if that object,
+ in turn, wasn't designed to be cloned at this time.
+ </li>
+ <li>
+ 3) A complex call-back API has been proposed which would allow the userData
+ object to tell the DOM which of these three options should be taken, but
+ that would require that only objects implementing that API be registered as
+ userData. That doesn't seem to be a good option.
+ </li>
+ <li>
+ 4) Do nothing. This is by far the lowest-overhead and safest choice. And
+ since cloneNode is a DOM operation, and userData is _not_ defined by the
+ standard DOM API, one can make a very strong case for this being the "most
+ correct" option.
+ </li>
+ </ul>
+ <p>
+ We chose (4), very deliberately. If you want one of the others, you can
+ implement it by creating your own wrapper operation for cloneNode() and
+ calling that.
+ </p>
+ <p>
+ NOTE that userData should be considered a nonportable, experimental feature
+ of the Xerces DOM. It may evaporate entirely in favor of a scheme based on
+ the DOM Level 3 "node key" mechanism, when that becomes officially
+ available.
+ </p>
</a>
</faq>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-cvs-help@xml.apache.org