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

[Murray Cumming Comneon com]

> From: Philipp Krause [mailto:pkk spth de] 
> >>Of course, one shouldn't have to recompile applications 
> when new minor
> >>stable versions are released.
> >So how can we give you this while also giving you a 
> templated library?
> >
> We could split it: a templated libraray, and a set of wrapper 
> functions 
> around the template functions.
> When someone uses the header file of the latter variant he 
> won't have to 
> recompile. Those who want
> templates are willing to pay the cost of recompilation and 
> can use the 
> template headers directly. The users
> of the wrapper functions would still benefit from improvements in the 
> templates.

To clarify, are you suggesting something like this?:

There are 2 or more libraries. E.g.
libxml++_templated
libxml++_ustring
libxml++_qstring

The _ustring and _qstring libraries will contain classes that derive from
the templated classes. E.g.

Namespace xmlpp_ustring
{

Class Node : public xmlpp::Node<Glib::ustring>
{
  ...
  Reimplemented constructors.
  methods inherited.
  ...
}

} //namespace

Yes, this might move the need to recompile into the _ustring library. It
seems like a lot of work though.

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

Similar loss-of-hierarchy problems are faced when using smartpointers such
as RefPtr or those used in the older versions of Xerces-C++ - I think we
would have to have templated copy constructors and operator= and use
templated cast_static() and dynamic_cast() methods instead of the standard
C++ static_cast<> and dynamic_cast<> operators. I don't like that much
myself.

I'm not sure whether this would apply to the simple typedefs too, or just
the derived classes idea.

Murray Cumming
murrayc usa net
www.murrayc.com