From b9eb0e8e6111e357ab0019dba41ea87a4a3ae9fe Mon Sep 17 00:00:00 2001
From: Tinny Ng <tng@apache.org>
Date: Tue, 12 Jun 2001 21:10:07 +0000
Subject: [PATCH] Add two more FAQs.
git-svn-id: https://svn.apache.org/repos/asf/xerces/c/trunk@172774 13f79535-47bb-0310-9956-ffa450edef68
---
doc/faq-parse.xml | 58 +++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/doc/faq-parse.xml b/doc/faq-parse.xml
index c98655f19..3aad70f0f 100644
--- a/doc/faq-parse.xml
+++ b/doc/faq-parse.xml
@@ -288,6 +288,13 @@ catch (const XMLException& toCatch) {
</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?">
@@ -602,12 +609,12 @@ catch (const XMLException& toCatch) {
<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>
@@ -680,4 +687,45 @@ catch (const XMLException& toCatch) {
</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>
+
</faqs>
--
GitLab