Boris Kolpackov wrote:
Hi Dale,
EXT-Pennington, Dale K <[EMAIL PROTECTED]> writes:
The second approach to dynamically allocate and reallocate an array of
XMLCh's as I go. That will handle arbitarily sized strings, but will
also mean a lot more heap action. (not to mention a certain amount of
copying depending on the realloc method used).
You can also pre-calculate the size of the resulting string by
iterating over the child nodes twice: the first time to calculate
the size and the second time to copy the text. Iterating over
child nodes is quite cheap (that is, if you don't use DOMNodeList)
and in your situation there probably won't be more than a handful
of child nodes.
But finding the lengths of the individual nodes will mean checking every
unit in each string, which could be very expensive.
I would take advantage of std::vector<XMLCh>, which has amortized constant
reallocation. Coupling that with reusing the same vector instance to
collect data each time would go a long way to cutting down on the cost of
the reallocations.
Of course, the best solution would involved re-writing the Xerces-C DOM to
use some sort of string class, rather than null-terminated arrays. That's
what I pushed for when the new DOM was being implemented, but I didn't get
my way...
Dave
