SAX/C++: First interface draft

[David Megginson]

James Clark <jjc at jclark.com> writes:

> In Java, everything in SAX is an interface. The way to do an interface
> in C++ is to use a class where all members (except possibly a virtual
> destructor) are abstract (ie defined as = 0).  This provides the maximum
> flexibility and insulation. The only good reason not to do an interface
> is if it were necessary and possible to inline some method calls for
> performance.  I think this this applies here: certainly there's no
> performance need to inline method calls to something like InputSource.

Actually, I don't see any strong argument not to provide empty inline
implementations for the handler callbacks:

    virtual void startDocument (void) {}
    virtual void endDocument (void) {}
    virtual void startElement (const char * name, const AttributeList &atts) {}
    virtual void endElement (const char * name) {}

(etc.)

That way, subclasses can implement only the callbacks they need, and
there's no need for a HandlerBase class.

> One interesting issue is whether to provide a virtual destructor.  I
> think the safest solution is not to provide a virtual destructor but
> instead to declare but not define a private operator delete.  This makes
> it a compile time error to do:
> 
>   DTDHandler *p;
>   // ...
>   delete p;
> 
> Given the policy on object ownership there's never any need to do that:
> only the creator of an object can delete it and the creator always has a
> pointer to the concrete subclass which will provide a way to release the
> object.

I appreciate James sharing some of his C++ experience here.  This
sounds like a good idea to me, but I'm at best a C++ journeyman, so
I'd be happy to hear from other masters on the list.

> It also has the nice property that there is no .cpp file associated with
> the SAX interface and no SAX library that has to be compiled or linked
> with.  It would be a completely pure interface.

Yes, I'd like this as well.

> Here's another draft, with this change and a few other minor changes;
> 
> - use int not size_t (Lakos has a whole section on why unsigned in
> interfaces is usually a bad idea)

OK -- I thought that I was being well-behaved using size_t.  Oh, well.

> - use a SAXString typedef for zero-terminated arrays

Sounds good, if slightly obfuscatory.

> - don't use (void) for empty argument lists

What are the arguments for and against?

> - use iosfwd not istream as the header file

I have no idea why, but I'll take James's word on this.

> - use characters not SAXCharacters as the method name on DocumentHandler
> - use a const char * arg for Parser::setLocale; I think that's the best
> you can do portably; Standard C++ allows locales to be identifier by
> name

Thanks.

> - add Locator

Yes, I forgot it.

> - change resolveEntity to avoid transfer of ownership as suggested in my
> previous message

Perfect, except that it might be nice to use bool as the return value, 
as I suggested, so that the parser isn't forced to examine the
InputSource if the app hasn't made any changes.

> - solve the UTF-8/UTF-16 problem by having two namespaces: a SAX_UTF8
> and a SAX_UTF16 namespace (since you're using std::istream, you are
> assuming compiler support for namespaces); this will work nicely with
> namespace aliases (eg namespace SAX = SAX_UTF8).

Ouch!  We might be getting a little hairy here.  How is Namespace
support out there, by the way?  I know that EGCS is pretty good on
Linux, though the std:: Namespace still isn't properly supported.

> Discussion points:
> 
> - Would it be better to typedef SAXString to the Standard C++ string
> class (ie std::basic_string<SAXChar>)?

Do we want to force that overhead on an app?  I need to understand
better if there will be a high cost to calling c_ptr over and over
again, if the app needs a regular zero-terminated character array.


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)