RE: [Re: [Re: [Re: [Re: [libxml++] UTF8 support]]]]

[Murray Cumming Comneon com]

> > Namespace xmlpp_ustring
> > {
> > 
> > Class Node : public xmlpp::Node<Glib::ustring>
> 
> wouldn't this still require the full inclusion of the 
> xmlpp:Node<> class template?

Yes, I guess people would still be using the inherited methods as templates
unless we reimplemented them too.

> I think for this to work the 
> underlying Node<Glib::ustring> would have to be hidden behind 
> a "compiler firewall" using the pimpl idiom.

I'm not sure that pimpl is necessay. Just calling the templated methods from
the untemplated derived methods would probably do it. But I haven't given it
that much thought. Your way would certainly work, and is no worse really. 

> Certainly more than the untemplatized version.
> Any API change would need to be re-implemented in the pre-compiled 
> Glib::ustring wrapper.

Yes. Unpleasant.

> To make even more work, a similar wrapper could be done for 
> other common params (e.g. QString) and included in the 
> libxml++.a library, allowing users of other tmeplate 
> instantiations to also drop in a new library without recompiling.

I think we would need separate libxml++_* libraries unless we want libxml++
to depend on both glibmm and Qt.

> > More importantly, I'm not sure whether our inheritance/polymorphism 
> > would still work. Is Element<Glib::ustring> still an instance of 
> > Node<Glib::ustring>?
> 
> yes:

Sorry, bad example. Yes, is probably would work for simple typedefs, but I
don't think it would work for derived classes, such as your pimpl technique.

Murray Cumming
murrayc usa net
www.murrayc.com