Re: [libxml++] patch to allow building without glibmm

[Stefan S. <se...@sy...>]

Brandon Forehand wrote:
> Stefan Seefeld <se...@sy...> 2005-10-28 10:32:28 -0400:
> 
>>libxml++ could define its own string type, which would simply be some
>>kind of smart pointer. Then you could add conversion functions to and from
>>your favorit unicode implementation for convenience.
>>That way users still have the choice which unicode library to use (if any 
>>at all).
> 
> 
> This seems like a fairly reasonable tradeoff.  Basically, it would be a
> thin wrapper class around xmlChar *, that only manages memory allocation
> and deallocation.  It could in fact be completely opaque and provide no
> interface for access.  One possible implementation would simply be an
> opaque wrapper of std::vector<xmlChar>.

not quite. That would incure a full copy of the string each time you
access content. The only reason to actually wrap xmlChar * in a class/struct
is type safety, and a tiny bit of convenience.

class String
{
public:
   String(xmlChar *d, bool owner = false);
   ~String();
   xmlChar const *data() const;
   size_t size() const;
private:
   xmlChar   *data_;
   bool const owner_;
};

When accessing libxml2-internal content, libxmlpp would
simple construct a String with owner=false. The compiler
should be able to optimize the String use away entirely.
On the other hand, if passing new content into libxmlpp,
the String object would own its data, so it can destroy it
at the end.

Anyways, you get the idea...

Stefan