Jesse's reasoning is exactly that used by me when I originally wrote Xerces. There will always be someone who wants X to be used in the parser, and there will always be someone for whom X is a huge PITA. If someone wants to use Xerces under their own proprietary object library, the STL is just extra complexity and extra overhead that isn't needed or wanted. If they want to use it in a small embedded system, and want to strip it down to the bare essentials, supporting the STL in a fundamental way makes that all the harder. I would have argued against the namespace thing myself, saying that either you support it or don't support it, period, and be done with it, because conditional code increases the complexity of testing and development quite non-linearly. Add in another big, orthogonal, conditional chunk and it would get insane for such a highly multi-platform product.
It's just the nature of the beast if you are going to write a heavily multi-platform system and want it to be as widely useful as possible. You have to stay somewhat least common denominator and allow people to wrap their object interface of choice around it to whatever degree they feel comfortable with. It wasn't until V7.0 that VC++ actually supported wide characters as a unique type, which shows how bad standardization has been. I consciously made this choice at the time based on my wide experience in writing portable code, and the current development crew have wisely maintained that stance, IMHO. This is not to say that the issue cannot be re-addressed, but it's not a no-brainer, nor does Xerce's current stance on this subject represent any kind of Luddite thinking. It's just practical. ------------------------------------- Dean Roddey The Charmed Quark Controller [EMAIL PROTECTED] www.charmedquark.com -----Original Message----- From: Jesse Pelton [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:06 AM To: '[EMAIL PROTECTED]' Subject: RE: posting code One clarification: Xerces is implemented using the standard C++ language. It exploits many features of the C++ language, but does not make much use of the C++ standard type library (STL), which is a library of code implemented using the language. (I think this is what you meant, but I want to be sure other readers understand the difference.) One of the challenges the Xerces project has is that the code has been ported to a wide variety of platforms (Win32, *nix, Mac, OS/2, OS/390, etc), many of which are not available to the core development team for testing. Add the fact that not all ports have a maintainer and it can be quite difficult to know what level of C++ support can be relied upon. Since the C standard has been around a lot longer (and is simpler to boot), it's implemented more consistently and is therefore safer to use in some cases. For instance, namespaces are useful but not universally supported, so Xerces allows you to use namespaces or not, in accordance with the capabilities of your compiler (and your preference). Making this possible took some effort, and requires the use of conditional code. This increased complexity, but this was deemed acceptable because of the usefulness of namespaces. If similar functionality is available in the C++ STL and the C run time library (RTL), and STL is not universally available, the code will be simplest (and therefore most maintainable) if the RTL is used. Conditional use of the STL makes sense only if there's a real benefit. I guess what it comes down to is that cross-platform projects like Xerces sometimes have to be technologically conservative in order to keep the code manageable. Given a choice between machine efficiency (executing the code) and human efficiency (maintaining it), it's generally wise to choose human efficiency. Machines get faster every day; people don't. One day, it may be more human-efficient to use the STL, but that day isn't here yet. > -----Original Message----- > From: sebastien demers [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 02, 2003 9:45 PM > To: [EMAIL PROTECTED] > Subject: Re: posting code --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
