[jira] Commented: (AXISCPP-149) Memory cleaning of generated C++ array code

["Mark Whitlock (JIRA)" <ax...@ws.apache.org>]

     [ http://issues.apache.org/jira/browse/AXISCPP-149?page=comments#action_58920 ]
     
Mark Whitlock commented on AXISCPP-149:
---------------------------------------

I have done some more investigation on this JIRA with the intention of fixing it for 1.5 but I have now decided to leave it for a future release. 

There are several possible solutions, but the solution that I would prefer would be to make Axis_Array a template that fully encapsulates the array and size and has constructors and destructors that deep copy the data. So...

template<class T> class AxisArrayT {
public:
  AxisArrayT();
  AxisArrayT(int size);
  virtual ~AxisArrayT();  
  AxisArrayT(AxisArrayT& copy);
  virtual AxisArrayT& operator=(AxisArray that);
  T& operator[](int index);
private:
  T *m_Array;
  int m_Size;
}

typedef AxisArrayT<xsd_int> xsd_int_Array;

Also the generated array classes would be specific instances of AxisArrayT<>. The advantages of this model are that the destructor cleans up the array storage (making client programming simpler), the data is fully encapsulated which is good OO practice, the class can be used as an array because it overloads operator[] and the class contains all the methods required to manipulate the data (not all listed here).

Unfortunately this would require large changes to SoapSerializer, SoapDeSerializer, ArrayBean, Param and other classes. Any method that was passed or returned one of these templates would need to be templatised itself since it would need to take the generalised form of the template not a specific instance. So...
template<class X> void Call::addBasicArrayParameter(AxisArrayT<class T> array, XSDTYPE type, const AxisChar *name)
There would also be considerable changes to wsdl2ws. Although I think this is a good long term solution, the amount of work involved puts me off implementing it in this release.

I also investigated simpler solutions that would clean up array storage in the client but be simpler to implement. One suggestion is to simply add a destructor to the existing Axis_Array. This is dangerous since then all copies of an Axis_Array would point to the same array storage. When the first got deleted (or went out of scope) it's destructor would delete the array storage, and now other copies would reference invalid storage and fail on deletion if not before.
The SoapDeSerializer (and others) passes around these array classes by value so copies are made and destroyed regularly. So this fix is not simple either. 

Another problem here is that the C++ compiler is free to create "temporary instances" of objects if it thinks it needs to. These "temporaries" are not referred to by local variables in the source code but are new'ed and deleted by the code that the compiler generates. So when compiler-generated code deleted one of these "temporaries", the array storage would also be deleted.

Consequently I think the simplest and safest solution in this release is to leave Axis_Array as is and force client applications to explicitly delete returned storage.


> Memory cleaning of generated C++ array code
> -------------------------------------------
>
>          Key: AXISCPP-149
>          URL: http://issues.apache.org/jira/browse/AXISCPP-149
>      Project: Axis-C++
>         Type: Improvement
>   Components: WSDL processing
>     Versions: 1.3 Final
>  Environment: All Platforms
>     Reporter: Samisa Abeysinghe
>     Assignee: Mark Whitlock
>      Fix For: 1.4 Alpha

>
> In case of Arrays, I noticed that the WSDL2WS tool is generating a 
> struct.
> e.g.
> typedef struct SOAPStruct_ArrayTag
> {
>         SOAPStruct* m_Array;
>         int m_Size;
> } SOAPStruct_Array;
> The trouble here is that in case of returned values/parameters the user 
> has to delete the m_Array mamber explicitly.
> I think a more cleaner way would be to use a class here and use a 
> destructor to clean memory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira