RE: [litwindow-users] Re: m_current as a pointer

[yrs90 <yr...@ya...>]

Earlier I wrote:
> Could you tell me where to find the data that the accessor is pointing to?


I found it right in front of me in const_accessor.this_ptr.  I looked at the
memory this pointed to several times but I was expecting to see some string
data rather than just pointers to wxString.  It's obvious now, but I was
confused... sorry.

> Currently, though, I'm trying to figure out why, when using m_current as
> originally designed, I can follow a particular click-sequence and watch
> what starts out as an iterator pointing to correct contents translate into
> corrupted data during the assignment to m_current.  Not only that but
> m_current's original contents coming into the assignment look suspect too.

I figured this out too.  I wonder if this was a danger I should have been
sensitive to. (It vaguely sounds familiar.)  Here's my explanation.

A class that manages some allocated memory.

class A
{
  char *data;
  int size;
public:
  A():data(0),size(0){}
  ~A(){delete[]data;}

  char *getdata() { return data; }
  void setdata(int sz, char* src) 
  { 
    if(data) delete [] data;
    data = new char[sz];
    if(data) 
    {
      memcpy(data,src,sz);
      size = sz;
    }
  }

  int getsize() {return size;}

  A &operator(const A& a)
  {
    setdata(a.getsize(), a.getdata());
  }
}

And now a function from class typed_const_accessor:
const Value get() const
 {
     Value v;
     get(v);
     return v;
 }

Function get(v) will copy an instance of A into v using the operator=.  No
problem.

On return from get(void) I seem to see another instance of A being created,
but /data/ will have the same pointer value as v.data!  Then v gets
destroyed freeing the memory that /data/ references.

Perhaps I needed a copy constructor?  Anyway, I resolved by managing my data
in a new object that I embed in A.  Now it works!  <sigh>

Regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]