[EMAIL PROTECTED] wrote:
> On the other hand, from the usage I see, XMLSize_t might as well stay
> a 32-bit value, and probably should have been on all platforms. Do we
> really need to "count" more than 2^32 nodes in a document, or be able
> to index into more than 2^32 of character data?
I would vote for not to limit XMLSize_t (or any other 'measuring' type)
to a fixed bit value. Instead, it should exactly shadow size_t.
In the past, similar questions have proven to poorly fail. Whenever an
upper bound of some measure has been placed in terms of absolute numbers
(stating that no one could imagine that this upper bound practically
would ever be excessed), this bound has become the Achilles' heel one
decade later. A consequence of Moore's law.
And we do not know today how many nodes some xml document will carry in
2015. But: xerces should be conform with the xml standards, and AFAIK
w3c has no 32-bit limit for the number of nodes in a document.
The problem of blowing the DOMNode representation on 64-bit systems is
not as grave as it seems on a first sight. Systems grow as they grow -
everybody knows that 64-bit software take more memory than their 32-bit
equivalents - and uncomplainingly slots in double RAM.
Axel
--
Humboldt-Universit�t zu Berlin
Institut f�r Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Wei�
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
