On Jun 8, 2005, at 8:59 AM, [EMAIL PROTECTED] wrote:
Since we seem to have been surviving fine with a plain size_t, I'd
like to suggest that we eliminate XMLSize_t in favor of size_t
everywhere in Xerces 3.0. This would eliminate a bit of required
configuration.
We should be careful to understand the implications of this before
we do
it. For example, in the Windows 64-bit model, size_t is 64 bits, but
unsigned long is 32-bits. How will that affect users' code, and
will it
unnecessarily bloat the size of the DOM instances on some platforms?
My understanding of XMLSize_t is that it was added to accommodate (or
potentially accommodate?) platforms that had no standard size_t
definition. It has typically been typedef'd to size_t. But since we
seem to be using plain size_t with no problems, I see no need to
continue perpetuating XMLSize_t.
In any case, size_t is defined by the standards as a type that will
hold "an unsigned integral type of the result of the sizeof
operator." So it needs to be able to accommodate the size of anything
stored in memory. It's like ptrdiff_t, only unsigned. Where ptrs are
actually 64 bits, size_t needs to be too. I believe XMLSize_t is
already defined on our platforms to be 64 bits in those situations,
though somebody is free to argue me wrong ;)
James.
But I do agree that its use is pretty much limited to the DOM, and
I don't
quite understand the purpose of it, or all of the preprocessor macro
definitions (_SIZE_T, SIZE_MAX, etc.) that go along with it.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
