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

[Jonathan Wakely <cow compsoc man ac uk>]

On Fri, Feb 28, 2003 at 04:02:13PM +0100, Murray Cumming Comneon com wrote:

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

wouldn't this still require the full inclusion of the xmlpp:Node<>
class template?
I think for this to work the underlying Node<Glib::ustring> would have
to be hidden behind a "compiler firewall" using the pimpl idiom.

The class templates live in headers, which are installed for users to
include in their programs with whatever template params they want to
use. For certain params (e.g. Glib::ustring) we provide a wrapper class
which hides all the templates behind a compiler firewall:

In node_ustring.h header:

namespace xmlpp_ustring {
  class Node {
    ...
    Reimplemented constructors.
    Reimplemented methods.
    ...
  private:
    void* pimpl_;
  };
}

In node_ustring.cc;

template class Node<Glib::ustring>;  // explicit instantiation

typedef xmlpp::Node<Glib::ustring>  NodeImpl;  // for convenience

// definitions of Node members...

xmlpp_ustring::Node::Node()
: pimpl(new NodeImpl)
{}

Glib::ustring
xmlpp_ustring::Node::get_data()
{
  // cast void pointer to right type
  return static_cast<NodeImpl*>(pimpl_)->get_data();
}

We then compile node_ustring.cc and include it in libxml++.a
Because node_ustring.cc contains an explicit instantiation of the
template parameterised with Glib::ustring it should be a "normal" object
file, with no template dependencies.
This should allow a user to include node_ustring.h, link to libxml++.a
and be able to drop in a new libxml++.a with bugfixes.
This assumes you could force an explicit instantiation into the .a file
(does this work the way it should with today's compilers?)
It could also go horribly wrong if a user mixed the pre-instantiated
wrapper with their own instantiations of the templates using the same
parameters, as it would cause violations of the one definition rule if
the template definitions in the headers don't match those in library.

I have a demo of this idea that compiles with g++ 2.95 and 3.0 if anyone
wants to see it.

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

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

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

template <typename StringT> class Node { /* ... */ };
template <typename StringT> class Element : public Node<StringT> { /* ... */ };

Element<ns::str> inherits from Node<ns::str>, but is totally unrelated
to Node<other_ns::other_str>


jon


-- 
Atilla The Hun's Maxim:
"If you're going to rape, pillage and burn, be sure to do things in that order."
	- P. J. Plauger, Programming On Purpose