[xsde-users] memory management of "variable length" elements
Ivan Le Lann
ivan.lelann at free.fr
Wed Sep 8 11:20:10 EDT 2010
Hi Boris,
----- "Boris Kolpackov" <boris at codesynthesis.com> a écrit :
> The alternative could be to serialize to XML using several parts
> instead of one object model thus avoiding copying altogether (here
> I assume that the goal of constructing an object from multiple
> parts it to eventually write it out to XML).
I might end with something like this, but I wanted to avoid it.
> > So far, the solutions I see would be to either :
> >
> > 1) use copy-on-write or shared pointer in containers of some
> > user-listed VL types.
>
> I think COW or reference counting would be too heavy-weight for
> XSD/e. Remember that its primary targets are mobile and embedded
> systems which can have only very basic C++ support, without
> exceptions, etc.
> Implementing error handling in COW without exceptions could be
> challenging. Also the overhead of storing a counter in each
> var-length object could be too high for some memory-constrained
> systems.
What I had in mind was to "type trait" the use of pointer in XSDe/Hybrid
generated code. It would then be user's responsability to specialize
the trait with "--hxx-prologue" file for the types of its choice.
He could also hack a libxsde header if he wants to change the default.
With a default targeting T*, I thought everybody would be happy.
The "You pay for what you use" axiom is respected.
I actually hacked one hour in that direction and it seems easier than
I first thought, at least in xsde/hybrid compiler code.
It might be more tricky to end with simple C++ in libxsde/hybrid sequences.
What do you think about this ?
> > 2) allow deep copy of some user-listed VL types.
>
> That's on the TODO for the next release. There will be an option to
> request generating of copy constructors/clone functions for
> var-length types.
>
Great. :-)
Regards,
Ivan.
> Boris
More information about the xsde-users
mailing list