|
Boost : |
From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-06-12 06:51:27
Gennadiy Rozental wrote:
>1. No xmlChar type -> template parameter
>namespace xml {
>template<typename Ch, typename Tr>
>class parser {...};
>}
I agree with this, but think that the basic problem is with the underlying
implementation. The xml++ implementation makes use of libxml2, who's
underlying representation is xmlChar. I am not sure what this evaluates to,
but I'll assuming it evaluates to a char. If the library were to be ported
to another implementation, this may differ (the Microsoft parser uses
wchar_t).
This means having a conversion manager in the traits class, e.g.
Traits::representation_type * Traits::convert( Traits::value_type );
The question then is how do you manage possible allocation/deallocation of
memory, especially when the parameter may be passed through if the two types
are the same:
char * traits::convert( char * str ){ return( str ); }
A mechanism needs to be sorted out in order for this to be successful.
>2. No hardcoded virtual functions. In some refinements it still may come to
>use virtual functions here and there. One way to achieve this is to supply
>implementation as template parameter:
I was aiming at a similar idea with my document loader, allowing the XML
document to be loaded in to the internal representation using a loader
class. There could then be implementations using libxml2, MSXML3/4, Spirit,
or another parser.
Regards,
Reece
_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection
http://www.msn.co.uk/specials/btbroadband
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk