SAX/C++: C++-specific design principles

[Mark D. Anderson]

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 at megginson.com> wrote:

> James Clark <jjc at jclark.com> 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 at megginson.com
>            http://www.megginson.com/
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
> unsubscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)