> > from a xerces and xalan users point of view it is always a blocker > > for me that both libraries don't share a rich common code base.
> Yes, it's unfortunate, because it would make many things much easier for > our users. On the other hand, you would not believe the number of posts > over the years that have suggested Xalan-C is _too_ closely tied to > Xerces-C! perhaps that's true for the XercesParserLiaison subtree ;-) but from my point of view this is unimportant compared to the benefit for users if both share the same api. > There are several reasons why this won't work. One is that, with the > standard library collection classes, the allocator is a template > parameter, which means the allocator type is part of the type of a class, > and that makes it awkward to interact with instances of the standard > library collections where the allocator is not of the same type. > The other is the real show stopper, though. The C++ standard says, in > section 20.1.5.4: > "Implementations of containers described in this International Standard > are permitted to assume that their > Allocator template parameter meets the following two additional > requirements beyond those in Table 32. > — All instances of a given allocator type are required to be > interchangeable and always compare equal to > each other. > — The typedef members pointer, const_pointer, size_type, and > difference_type are > required to be T*,T const*, size_t, and ptrdiff_t, respectively. > The first of the two requirements is the killer, because it essentially > means that allocators cannot have instance data. I found an interesting discussion about that on comp.lang.c++: http://coding.derkeiler.com/Archive/C_CPP/comp.lang.cpp/2004-01/447index .html where opinions go apart. > Again, it's both good and bad. I did attempt about 4 years ago to push > the new Xerces-C DOM bindings in a direction that would make them useable > for Xalan-C, but it didn't work out. The sticking point was using a > string class, as Xalan-C does, vs. using bare null-terminated arrays of > XMLCh like Xerces-C does. For XPath and XSLT, the performance hit was too > great, for the following reasons: > 1. Null-terminated arrays do not carry their lengths with them, which > caused constant recalculation of lengths. > 2. We still needed a reasonably well-performing and functional string > class, because XPath and XSLT does lots of string manipulation. *nod* *nod* > In fact, looking forward to a new Xalan-C API for the source tree, I would > probably move even farther away from something that looks like the DOM, > although it still would be a tree-manipulation API. In fact, I think we > would move away from using strings in the interface, and move to assigning > unique integers to each unique "name" string in the source tree instance. > The source tree model in Xalan-J does this, and I believe we would see > considerable performance increases as a result. But more discussion of > possible changes should move to the Xalan developer list. my intention to discuss this on _this_ list was to get some general responses from the xercesc team *wink* about moving from null-terminated arrays to a string class in 3.0 without specifying how that string class could look like, because I know that performance in xalan would drop with null-terminated arrays as you have explained above. don't worry, dave, I don't really suggested to modify xalanc :), I only mentioned your name, because you can add some good extra arguments moving away from c strings in xerces, just because of xalan has is own string class. tobias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
