You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Mark Whitlock <ma...@uk.ibm.com> on 2005/07/18 15:39:01 UTC
Memory model for arrays and complex types (was: Carsten: please help)
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
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by Samisa Abeysinghe <sa...@gmail.com>.
It is not the client stubs, rather the server library I guess.
On 7/20/05, John Hawkins <HA...@uk.ibm.com> wrote:
>
> I'm still confused as to *why* the client stubs have to be linked to the
> server.
>
>
>
>
>
> Samisa Abeysinghe <sa...@gmail.com>
>
> 19/07/2005 04:30
>
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To Apache AXIS C Developers List <ax...@ws.apache.org>
>
> 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 <ma...@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
> >
> >
>
>
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by John Hawkins <HA...@uk.ibm.com>.
I'm still confused as to *why* the client stubs have to be linked to the
server.
Samisa Abeysinghe <sa...@gmail.com>
19/07/2005 04:30
Please respond to
"Apache AXIS C Developers List"
To
Apache AXIS C Developers List <ax...@ws.apache.org>
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 <ma...@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
>
>
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by Samisa Abeysinghe <sa...@gmail.com>.
> 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 <ma...@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
>
>
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by Nadir Amra <am...@us.ibm.com>.
Mark,
I do not have a problem with that.....sorry for my confusion.
Mark Whitlock <ma...@uk.ibm.com> wrote on 07/18/2005 10:12:23 AM:
>
>
>
>
> Hi Nadir,
> I didn't mean to suggest that the client would be linked with the
server.
> The problem previously was wholy on the server-side. Apparently services
> currently deployed to the Axis C++ server are not linked with the Axis
C++
> server library. But with this fix they may have to be.
> Mark
> Mark Whitlock
> IBM
>
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by Mark Whitlock <ma...@uk.ibm.com>.
Hi Nadir,
I didn't mean to suggest that the client would be linked with the server.
The problem previously was wholy on the server-side. Apparently services
currently deployed to the Axis C++ server are not linked with the Axis C++
server library. But with this fix they may have to be.
Mark
Mark Whitlock
IBM
Nadir Amra
<am...@us.ibm.com>
To
18/07/2005 15:27 "Apache AXIS C Developers List"
<ax...@ws.apache.org>
cc
Please respond to axis-c-dev@ws.apache.or
"Apache AXIS C Subject
Developers List" Re: Memory model for arrays and
complex types (was: Carsten: please
help)
If you mean that the in order to use the client piece one has to build the
server piece, yes, I have a problem with that. Mainly due to the fact
that from OS/400 perspective we have not done anything with the server
side of things. But it also added complexity that seems unnecessary.
Mark Whitlock <ma...@uk.ibm.com> wrote on 07/18/2005 08:39:01 AM:
>
>
>
>
> 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
>
Re: Memory model for arrays and complex types (was: Carsten: please help)
Posted by Nadir Amra <am...@us.ibm.com>.
If you mean that the in order to use the client piece one has to build the
server piece, yes, I have a problem with that. Mainly due to the fact
that from OS/400 perspective we have not done anything with the server
side of things. But it also added complexity that seems unnecessary.
Mark Whitlock <ma...@uk.ibm.com> wrote on 07/18/2005 08:39:01 AM:
>
>
>
>
> 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
>