Cart
[Home] [By Thread] [By Date] [Recent Entries]
A danger with adopting the convention that 1 of the 0 or more output parameters is a return value is that it may interfere with a later convention on error handling. I haven't seen that discussed yet in your design principles. Unlike java or perl, exceptions in C++ are a bit of a land mine, and could also risk destroying any simple interop with a straight C library, either above or below. Not to mention the fact that there is no standard for cross-language exception raising. choices seem to be: - return an error code - return a boolean success/failure - use C++ exceptions - call an error handler and return 0 (which may not get run if the error handler aborts) - some combination of the above, configurable by the programmer btw, i'd like to register an objection to reference args. they make code reading a bit of pain because you cannot tell from the call whether a copy constructor is going to be used or not -- you always have to go hunt up the .h. with a pointer arg, it is always clear. and in regards the character type question, that is a bit awkward because a key goal for many programmers will be to use the "native" string type used by the parser, which may be just linked in binary -- not recompiled. of course, if we all just use expat, that is solved -- we have to have a SAX/C++ type which directly points to expat's strings. -mda --On Friday, December 03, 1999 8:58 AM -0500 David Megginson <david@m...> wrote: > James Clark <jjc@j...> writes: > >> That's problematic for EntityResolve::resolveEntity; that requires that >> ownership of an InputSource be transferred from to the caller from the >> callee. >> >> This could be avoided by doing: >> >> virtual const InputSource * >> resolveEntity(const char *publicId, >> const char *systemId); >> >> instead of: >> >> virtual void >> resolveEntity(const char *publicId, >> const char *systemId, >> InputSource &inputSource); > > (I'll assume that James accidentally reversed the two). The second > one is a very good idea -- the only modification I'd make is to add a > bool return value, so that the parser knows whether the resolver > actually wants to override: > > virtual bool > resolveEntity(const char *publicId, > const char *systemId, > InputSource &inputSource); > > > All the best, > > > David > > -- > David Megginson david@m... > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To unsubscribe, mailto:majordomo@i... the following message; > unsubscribe xml-dev > To subscribe to the digests, mailto:majordomo@i... the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@i...) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
