Hi all, FWIW, I think James has put it well. Why would one want to count something using a variable of a type with "size" in its name? Just doesn't seem to be a good fit.
Cheers, Neil Neil Graham Manager, XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] James Berry <[EMAIL PROTECTED]> 06/10/2005 05:19 PM Please respond to c-dev To [email protected] cc Subject Re: Need for XMLSize_t? 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
