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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
