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 12:23:07 GMT




Hi Samisa,
I discussed the advantages/disadvantages of the 2 solutions again with John
Hawkins, and we agreed that your proposed solution (template with deep
copies) is preferable. So that is what I shall implement in this release.
Mark
Mark Whitlock
IBM

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




Hi Mark,
     Yes, it is exactly the same solution that I was proposing.
Thanks,
Samisa...


On Mon, 7 Feb 2005 10:44:37 +0000, Mark Whitlock
<mark_whitlock@uk.ibm.com> wrote:
>
>
> 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