Re: Representing arrays: AXISCPP-149

[Samisa Abeysinghe <sa...@gmail.com>]

> 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 do agree on the complexities of this situation.
However, can't we make sure that we always do a deep copy of the
m_Array member in the class and seperate the memory management
concers.

What I ment here is that if client application allocates, that must
always clean up.  The class must have its own copy for the members,
and must take care of cleaning itself. If client application allocated
memory is passed to the class constructor, or set methods, instead of
using the pointer as it is, the class allocated its own memory, copy
the content to allocated memory and clean up once done with or in
destructor. Yes, this is going to increase the memory usage as we may
have allocated memory on several instances for the same value - but it
simplifies the memory management. And if amount of memory allocated is
a concern, we can eliminate that using some best practices at client
application level.

Is this a viable solution?

Thanks,
Samisa...


On Thu, 3 Feb 2005 18:47:10 +0000, John Hawkins <HA...@uk.ibm.com> wrote:
> 
> 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"
> Toaxis-c-dev@ws.apache.org 
> cc
> SubjectRepresenting  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
> 
> 
>