axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <mark_whitl...@uk.ibm.com>
Subject Fw: Representing arrays: AXISCPP-149
Date Mon, 07 Feb 2005 10:44:37 GMT




Hi Samisa,
If I understand your append, you are agreeing with the template solution
(in my first append below) which has constructors, copy constructor and
overloaded operator= all of which take a deep copy of the data:-

Axis_Array(int size) {
      m_Size=size;
      m_Array=new T[size];
      for (int i=0; i<size; i++) m_Array[i]=NULL;
}

Axis_Array(const Axis_Array& copy) {
      m_Size=copy.m_Size;
      m_Array = new t[m_Size];
      for (int i=0; i<m_Size; i++) m_Array[i]=copy.m_Array[i];
}

virtual ~Axis_Array() {
      m_Size=0;
      if (m_Array) delete[] m_Array;
      m_Array=NULL;
}

and similiar Axis_Array() and virtual Axis_Array& operator=(Axis_Array
other) methods. I too prefer this solution. But for this release, I will
take John's advice and implement the simpler solution of not taking a deep
copy, or allocating storage; but simply deleting the user's storage in the
Axis_Array destructor.

This simpler solution forces the clients to always new storage for their
arrays in advance (never use local variables), and be careful how they use
these array classes. C++ sometimes creates temporary instances of objects,
at the compiler's discretion, which are not named variables in the source
code. If a temporary is assigned to an array class, and is then deleted
(arbitrarily by the compiler), that temporary's destructor will delete the
array's storage. I have seen these temporary instances being created and
destroyed, but I don't really understand why or when the compiler does it.

Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 07/02/2005 10:21 -----
                                                                           
             Samisa Abeysinghe                                             
             <samisa.abeysingh                                             
             e@gmail.com>                                               To 
                                       Apache AXIS C Developers List       
             07/02/2005 05:14          <axis-c-dev@ws.apache.org>          
                                                                        cc 
                                                                           
             Please respond to                                     Subject 
              "Apache AXIS C           Re: Representing arrays:            
             Developers List"          AXISCPP-149                         
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




> 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 <HAWKINSJ@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
>
>
>


Mime
View raw message