> 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! > in the case of stl both libraries try to reinvent some stl classes on > their own. every c++ programmer know stl, but he has to worry about > xerces and xalan clones too. As far as I know, Xalan-C's "clones" of the standard library collections are, for the most part, drop-in replacements for the ones in the standard library, although we obviously use our own class names and namespace. > that's why i would prefer heavy stl usage in xerces and xalan after > verifying which compilers will break _today_. i'm using xerces and > xalan on different platforms/compilers (embedded systems too) and > never came across stl related problems. btw, i never understand why > stl shouldn't work with your pluggable memory management, i always > thought that a custom memorymanager to std::allocator wrapper of > the allocator template parameter of each stl collection could do the > job here, but correct me if i'm wrong, i have never verified this. 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. > and this is also for the xalan team, i saw dave is following this > conversation: > before xerces is pulling in some xpath library like pathan, life > could be a lot easier if xalan was sharing the same dom api, > so that it could be directly integrated in xerces if users wish > xpath/xsl functionality in xerces dom. 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. 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. Dave
