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

Mark D. Anderson mda at
Mon Dec 6 22:19:11 GMT 1999

>> - use C++ exceptions
> I vote for C++ exceptions. That is why they are there.

Someone should dictate whether the exception objects are raised,
or pointers to them. Regardless, it is impossible for mere mortals
to use them without having leaks when they occur below constructors
and destructors. But I guess anyone using C/C++ already knows they
are taking such risks.

Don't get me wrong; i like exceptions in programming languages that
support them well.

I'm a little confused by the intent of the draft header, where
there is a SAXParseException class which is an argument to a handler.
Seems like if it is a native C++ exception, then the caller takes
care of catching it, not registering a handler.

I also wonder whether a handler (error handler or any other, like
document) is supposed to be able to call back into the Parser
and tell it clean up.

I also might note that the current exception class appears to have
no member data indicating which parser or inputsource object is in use,
which would be an issue with a multi-threaded implementation, or
even a single-threaded one with multiple top-level instances.

>> 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.
> If you always pass by reference, this isn't a problem. In C++, there is
> almost never a compelling reason to pass objects by value.

Agreed. I guess it comes down to how much you trust other programmers.
If you trust them, then using pointerhood to encode optionality might
be useful. I guess I'm just too often forced to deal with C++ afficionados
who love nothing more than hiding several automatic class methods and
casts in every argument value.


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

More information about the Xml-dev mailing list