[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. :-)

> Boris

More information about the xsde-users mailing list