OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: SAX/C++: First interface draft

[ Lists Home | Date Index | Thread Index ]
  • From: "Richard Anderson" <rja@arpsolutions.demon.co.uk>
  • To: "XMLDev list" <xml-dev@ic.ac.uk>
  • Date: Fri, 3 Dec 1999 15:16:20 -0000

> 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) {}

I think the "= 0" is far more normal in the C/C++.  I personally prefer that
approach because if I derive a class from the parser class, and do a typo in
method implementation in the derived class I get a compile error, rather
than spending time figuring out the empty base class implementation is being
called.  Having a handler base is fine by me.

If we do go for the "= 0" approach I suggest the class be prefixed with an
"I" (for interface).  Those who work with COM will understand that rational
behind that ;)


> 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.

The other option is :

protected:
   virtual ~CSAXParser() {}

Of course, it is nice to be able to delete things so should the class should
probably include a delete or release method:

    virtual void delete() = 0;

That can then be implemented using referencing counting if so desired or a
straight delete.

> > - use iosfwd not istream as the header file

I've not used isofwd, but why not just define a SAX input stream class :

class CInputStream
{
public:

    virtual int ReadChar( unsigned char& ch ) = 0;
    ...
};

I for one have implemented by SAX support this way so people using the
toolkit can implement streams however they see fit, esp. if STL support on
their platform is a but shaky.

> > - 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).

We've had problems with namespaces not being supported with some compilers,
so it is best to avoid them.  That is the reason why I suggest all
interface/class names are prefixed with SAX, CSAX or better still ISAX

Regards,

Richard.




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS