axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <>
Subject Memory model for arrays and complex types (was: Carsten: please help)
Date Mon, 18 Jul 2005 13:39:01 GMT

Hi Samisa/Carsten/All,
There are a bunch of problems with the current memory model for arrays and
complex types....
1) Storage for pointers in input complex types must be new'ed by
applications so the complex type's destructor can delete it later. This
prevents local variables from being used in this situation, and multiple
pointers pointing at the same storage. It is a poor programming model,
since the application must new the storage, but must not delete it.
2) Complex type's destructors delete storage for any arrays embedded in the
complex type. Arrays do not have a destructor. So storage for array
elements that are output parameters still needs to be explicitly deleted by
the application.
3) Storage for nillable fields is not deleted by complex types'
4) Complex types and arrays do not have constructors that take a deep copy
of the data they contain. So applications that use complex types and arrays
must be careful to ensure that multiple instances do not reference the same
storage, otherwise the destructor for each instance will attempt to delete
the same storage.
5) xsd_base64Binary, xsd_hexBinary and AnyType have similar problems to
those of arrays.
6) Pointers that are deleted are not zeroed afterwards.

These problems are partly covered by AXISCPP-149. I propose to fix these
problems by...
1) Adding a destructor to arrays that deletes the array storage
2) Improving complex type's destructors by supporting nillable fields but
not deleting array storage
3) Adding copy constructors and operator= methods to complex types and
4) Ensuring complex type's and array's set methods deep copy storage passed
to them.
5) Fixing xsd__base64Binary, xsd__hexBinary and AnyType to behave the same
as arrays.

Last time I unsuccessfully tried to fix AXISCPP-149, I added the
implementation of xsd__base64Binary methods (and others) to
AxisUserAPI.cpp. People on this mailing list were unhappy with this fix,
because it meant that services would now have to be linked with the Axis
C++ server library. Is this still a problem and if so, why?

Does anyone have any comments on this proposal?
Mark Whitlock

View raw message