Re: [Libxmlplusplus-general] parametrizing libxml++ for the character /string type

[Stefan Seefeld <seefeld sympatico ca>]

Murray Cumming wrote:

> We must fix these memory leaks before we can think of applying the
> patch.

well, I was under the impression that you'd put these changes into
an 'unstable' branch. While I agree that it is important to track
all changes, some things are hard to change under such constraints
(for example a stable API). As an example, there ar methods that
shouldn't be there. Some objects should never exist 'unbound'.
If for example an 'Attribute object always has a parent 'Node',
it's easy not to leak memory. However, if you want to be able to
construct attributes freely, things are different. That's one aspect
of the issue I was alluding to as 'specify ownership semantics'...

Please let me know how you would like to proceed. I have a long list
of things I'd like to submit / check in, and I'd like to get forward
as fast as possible (I'd like to use this in my own projects and at
work).

Again, I can work out a switch of the implementation in a single atomic
patch, but that would imply changes to the API, as well as changes to
configure (as I said, the libxml2 callbacks we'd want to use are only
available since 2.5.1, so we have to make sure the version is recent
enough). I tend to think that it would be easier to work on an unstable
branch, if you don't want to compromize stability for your users. (By
the way, what's the timeframe for the release of the stable libxml++
version ?)

> Please keep changes in separate patches. I don't see how the addition of
> a Document type has anything to do with the other changes.

right, keeping patches on focus for a specific purpose is important.
Yet I tend to think that a new 'Document' type fits in here, as it is
consistent with the other changes that directly map between libxml2 and
libxml++ types. The DomParser class now has a number of members, which,
with the new implementation would all be owned by a single Document
object (i.e. via _private members of the impl object...).

Regards,
		Stefan