> 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 <[EMAIL PROTECTED]> 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 > >
