Hi Mark, I think Jesse did an excellent job of describing why Xerces-C (and in fact Xerces-*; Xerces-J only very recently abandoned its commitment to run on JDK 1.1.8) has historically tended to be technologically conservative. Far from prereq'ing GCC 3.2.2, we still have folks who need to use GCC 2.95.3--e.g. on Linux on OS390--because higher versions of GCC aren't yet (commonly) available on those platforms.
For a bit of additional background, take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21079 and especially http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20684. It's the discussion surrounding this latter bug that's particularly been responsible for biasing many contributors against further reliance on STL/C++ IOStreams. Anyway, if STDC++ IOStream functionality is so much faster, and if someone puts together a conditionalized patch to allow for its use with compilers that support it, I for one would be happy to think seriously about committing it. Code complexity is a bad thing, and to be avoided for sure; but if the patch weren't too intrusive, and if there were a demonstrable performance gain, then it might well be a price worth paying. Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] Mark Deric <[EMAIL PROTECTED] To: [EMAIL PROTECTED] om> cc: Subject: Re: posting code 09/03/2003 12:22 AM Please respond to xerces-c-dev I can't believe I'm reading this. While I am not a contributor to Xerces-C, I am a faithful consumer; our company is in the process of converting our UI messaging system to XML, to mate with our daemon suite product's underlying XML runtime and persistent configuration. The UI is Java, and the under to hood code is "C". In my opinion, as the guy who wrote many "collections", and "engines" in "C", with handles given by the "createXXX" method, and cleaned up by the "destroyXXX" method -- to emulate the STL; I am super sympathetic to Sebastien (just 'cause a guy makes a living dealing w/win32, doesn't mean he's totally brain-dead. BTW, didn't M$ try to rewrite the STL; or abandon the open source connection?). And there's Neil Graham, the consistent, usually soft tempered contributor. Neil, I love you, man; but, consider the following: -- the Linux kernel now has a red-black tree (albeit, a special pupose rendition; Linus will come around). This is one of the general-purpose "collections" I implemented in "C". Wouldn't I have been better off to use the STL code? Ron Rivest is one of my heros. -- See the ACE/TAO suite for a view of cross-platform C++. Apache isn't the only open source worth reading. Also, see boost.org for extentions to the STL. -- The GNU support of C++ with 3.2.2 (RH9) is better than 2.96 (RH7.1). The 2.96 required some weird "#pragma impl" stuff, but it worked for me. Gcc 3.2.2 hasn't been tested alot, but from the notes and mini-forays, seems real good. -- when you talk about supporting many platforms, I hope you are focusing particularly hard on maintaining the SCO UNIX "proprietary" distribution I'm out. Regards, Mark On Tue, 2 Sep 2003 21:44:48 -0400 "sebastien demers" <[EMAIL PROTECTED]> wrote: > I didn't know that in year 2003 standard C++ library was not > supported in all common platforms and compilers. (Since the > Standard was published in 1998 and it's supported by all win32 > compilers for several years) > > I can imagine how the library could be optimized both in speed > and in size if it would be compiled with the standard library > and template. > > Will Xerces always be compiled only for Standard C or I could > hope a step ahead? > > - Sebastien > > > ----- Original Message ----- > From: "Neil Graham" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, August 30, 2003 4:55 PM > Subject: Re: posting code > > > > Hi Sebastien, > > If you want to post proposals to modify the sources, you'll > need to get to know the diff utility. Using it's -u option is > the best way of describing the delta between your modified file > and the original source. You'll also want to use sources from > CVS for this, rather than what was originally distributed, > since it's difficult to apply patches once the source against > which the patch was made changes. > > As to this modification specifically: I think the general > direction of the project is to rely less, rather than more, on > standard C++ routines. Remember that we need to run on many > many different platforms, and standard C++ tends to be rather > less portable than standard C. (And on many platforms it's not > as efficient either). So I'm not sure we'd want to make > modifications of this sort. > > Cheers, > Neil > Neil Graham > XML Parser Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > |---------+----------------------------> > | | Sébastien Demers | > | | <[EMAIL PROTECTED]| > | | utions.com> | > | | | > | | 08/28/2003 04:35 | > | | PM | > | | Please respond to| > | | xerces-c-dev | > | | | > |---------+----------------------------> > > >------------------------------------------------------------- > >-------------- > -------------------------------------------------------------- > ----| > | > | > | To: <[EMAIL PROTECTED]> > | > | cc: > | > | Subject: posting code > | > | > | > | > | > > >------------------------------------------------------------- > >-------------- > -------------------------------------------------------------- > ----| > > > > < > Hi Sebastien, > > This has been fixed for quite a while in CVS. It'll definitely > be in the next release (schedule for a little less than 2 > months from now). > > > > cool. > > I dont know if I'm in the good place for posting suggestion of > code (not really bugs) like the following code in the file > \util\XMLString.cpp > > unsigned int XMLString::stringLen(const XMLCh* const src) > { > if (src == 0 || *src == 0) > { > return 0; > } > else > { > return std::char_traits<XMLCh>::length(src); > } > } > > This small modification will accelerate considerably general > parsing of large input stream. > > I have modified several files in library for this kind of > problem and each time a new library revision is posted, I have > to update my files. > > - Sebastien > > ----- Original Message ----- > From: "Neil Graham" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, August 28, 2003 3:52 PM > Subject: Re: mess with <iostream.h> > > > Hi Sebastien, > > This has been fixed for quite a while in CVS. It'll definitely > be in the next release (schedule for a little less than 2 > months from now). > > Cheers, > Neil > Neil Graham > XML Parser Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > |---------+----------------------------> > | | Sébastien Demers | > | | <[EMAIL PROTECTED]| > | | utions.com> | > | | | > | | 08/28/2003 03:46 | > | | PM | > | | Please respond to| > | | xerces-c-dev | > | | | > |---------+----------------------------> > > > > -------------------------------------------------------------- > -------------------------------------------------------------- > -----------------| > | > | > | To: <[EMAIL PROTECTED]> > | > | cc: > | > | Subject: mess with <iostream.h> > | > | > | > | > | > > > > -------------------------------------------------------------- > -------------------------------------------------------------- > -----------------| > > > > In several files iostream.h, is still used in favor of iostream > > Since the file iostream.h is obsolate. Why new revisions still > using this file instead of using iostream with a small using > std::cout; ???? > > Please have a look in the file > xerces/c/src/xercesc/framework/StdOutFormatTarget.cpp for a > party of mess. > > - Sebastien > > > > -------------------------------------------------------------- > ------- 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] > > > > > > > -------------------------------------------------------------- > ------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
