[xsde-users] memory management of "variable length" elements
Ivan Le Lann
ivan.lelann at free.fr
Wed Sep 15 13:23:35 EDT 2010
----- "Boris Kolpackov" <boris at codesynthesis.com> writes :
> Also, in this particular case the ideal is no changes to the way
> are currently done if the custom pointer option is not used. I think
> the problematic part will be var_sequence and var_iterator. Would you
> like to propose how we can handle them?
In var_sequence as in generated code, we need free functions to wrap
code like "p = 0" or "delete p". Without template specialization,
how to implement these functions ? Overloading can help in generated
code, but not in libxsde, as you spotted.
This looks like a dead end to me.
> Also, provided there is a way to clone var-length nodes, would you
> still need this feature?
I need both to get a COW-pointer.
Not that I really like COW but it seemed to fit here :
The code is basically a "solid request" builder from various parts.
Some parts are most of the time inserted as is, some are always,
and some are rebuilt from scratch each time.
My current state (with my smart ptr aware xsde) is that parts that
are known never to be modified use a shared ptr.
But I'm playing with fire here and especially with side-effects.
Before the move to vanilla XSD/e, this code was *much* slower.
This was pure DOM and XPath manipulation with TinyXML.
While performance with vanilla XSD/e is a great achievement, I had the
feeling I could easily be both safe and optimal with few pointer tweaks.
Please note that I realize now that I'm asking much of XSD/e here.
I might live with my "pointer patch" for a while, thinking of a
better way to do things in the future.
I might even try this idea on XSD (not /e). What do you think ?
More information about the xsde-users