Hi Matt and Dave,
I think there are two issues, which we shouldn't confuse. I believe
XMLSize_t should mirror size_t. Otherwise confusion just reigns.
If we need a type for the count of things, we should use something
else, or just use long or int (that's what they're there for!).
So I claim:
- It's a bug if XMLSize_t doesn't match what size_t should.
- If some of our API or data structures use XMLSize_t (or
size_t) where we really want a more conveniently sized count, we
should change the API (and internal references...) to use a better
type for this count
In Xerces 3.0, if size_t exists (which I believe it always does on
any of our platforms) our configure script typedefs XMLSize_t to
size_t. For the Windows platform, we hardcode XMLSize_t as SIZE_T (I
don't know what that is, or why it's not just size_t).
-jdb.
On Jun 10, 2005, at 2:09 PM, [EMAIL PROTECTED] wrote:
to expect in other 64-bit libraries. If this convention is not
followed,
what is the point of having 64-bit Xerces in the first place?
It's not as simple as that. We are talking about counts of nodes, not
sizes of nodes, or the amount of memory that's addressable. For
example,
it's roughly:
4,294,967,296 nodes per document
4,294,967,296 characters per string value (8,589,934,592 bytes)
4,294,967,296 nodes per node list
etc.
I think you get the idea. Even with 64-bit addressing, the amount of
memory consumed by a document that went over these limits would be
huge. I
think it's also worth mentioning that, if we go to 64-bit values
everywhere, every document will pay the price in potentially
overhead for
the few documents that manage to hit these limits. Of course, it's
always
possible to redefine the typedef to be a 64-bit value, if you
should need
to. That's why typedefs are a "good thing" and we should carefully
examine the use of XMLSize_t before we make any change.
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]
