axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: Memory model for arrays and complex types (was: Carsten: please help)
Date Tue, 19 Jul 2005 03:30:47 GMT
> because it meant that services would now have to be linked with the Axis
> C++ server library.

Well I do not think this would be a problem. At the moment, the server
side, as per my understanding, suffers a lot form memory leaks. Hence
I think these proposed fixes would help rather than hinder the server
side.

I am strongly +1 for these fixes.

Thanks,
Samisa...

On 7/18/05, Mark Whitlock <mark_whitlock@uk.ibm.com> wrote:
> 
> 
> 
> 
> 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'
> destructors.
> 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
> arrays.
> 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
> Mark Whitlock
> IBM
> 
>

Mime
View raw message