It is not the client stubs, rather the server library I guess.
On 7/20/05, John Hawkins <[EMAIL PROTECTED]> wrote: > > I'm still confused as to *why* the client stubs have to be linked to the > server. > > > > > > Samisa Abeysinghe <[EMAIL PROTECTED]> > > 19/07/2005 04:30 > > Please respond to > "Apache AXIS C Developers List" > > > To Apache AXIS C Developers List <[email protected]> > > cc > > Subject Re: Memory model for arrays and complex types (was: Carsten: please > help) > > > > > > > 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 > > > > > >
