axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Representing arrays: AXISCPP-149
Date Thu, 03 Feb 2005 18:47:10 GMT
Hi Mark,

Why do you think that deleting the memory in the struct is wrong? To me 
this is the obvious and simplest quick fix to this problem. It enforces 
the rule that they must give us a pointer to the memory and that we will 
handle the clean-up. If we supply this as the default behaviour then I 
would be more than happy ! If they wish to then hack the struct and remove 
our destruction code then they can do but giving the average user some 
function for free sounds great. Most people like rules that are clear - 
and that's a clear one to me !

If we wish to make it belt and braces then yes templates are the way to 
go. However, for this release I would like to see us cleaning up the 
structs as quick fix to an ugly problem.






Mark Whitlock/UK/IBM@IBMGB 
03/02/2005 18:07
Please respond to
"Apache AXIS C Developers List"


To
axis-c-dev@ws.apache.org
cc

Subject
Representing  arrays: AXISCPP-149










Hi,
I am investigating AXISCPP-149 "Memory cleaning of generated C++ array
code".

Currently Axis_Array is a class with public data and no methods. Arrays in
generated code are structs and new'ing and deleting the array storage is
done either by the client application (for input parameters) or for output
parameters new'ed by generated code and deleted by the client application.

Just adding in a destructor which always deletes the array storage is
deleting storage that the client application may have allocated. The 
client
application may have malloc'ed the storage for m_Array or even declared it
as a local variable. Such a destructor would force applications to use new
to allocate storage passed as input arrays, and then never delete that
storage. I think that is not the best model.

I think EITHER we should stay with the current model of arrays being
represented as structs and it is up to the application to manage the
storage OR arrays should be represented as a template which completely
encapsulates the array data. So...

template <class T> class Axis_Array {
public:
      Axis_Array();
      Axis_Array(int size);
      Axis_Array(const Axis_Array& copy);
      ~Axis_Array();
      Axis_Array& operator=(Axis_Array other);
      T& operator[](int index);
      int size();
private:
      void *m_Array;
      int m_Size;
};

typedef Axis_Array<xsd_int> xsd_int_Array;

Where the various constructors new the array storage and the destructors
delete it. Both generated and basic array types would be specific 
instances
of template Axis_Array. Since m_Array is private, applications (and the
rest of the Axis code) would not be able to access it directly. The
generated Axis_Create_ and Axis_Delete_ methods would disappear because
Axis_Array would be newing and deleting the storage (unless Axis_Array
calls template methods for Axis_Create_ and Axis_Delete_ and specific
instances of these methods are generated).

The C bindings would either have to use the existing generated structs and
copy data between these and Axis_Array, or else C functions would have to
encapsulate the array (allocate and free it) so that pointers to the
underlying Axis_Array were returned to the C application.

Comments?
Mark
Mark Whitlock
IBM



Mime
View raw message