> My enterprise works with very large instance documents that are rich in > tags. Currently some of our large documents are 750 MB and are growing fast > as more data is added to the XML feeds and more users subscribe to our > services. > > If we went over 2/4/whatever GB limit that these 32-bit types impose, that > would be very bad. Therefore I advocate making sure a library compiled as > 64-bit shares the same traditional large file safety that people have come > 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]
