|
memblock destructor? |
Posted by jim enright on Apr-19-2017 03:13 |
|
just curious - here is the memblock class
class MemBlock
{
public :
int len;
const char *data;
MemBlock() : data(0), len(0) {}
MemBlock(const char *data, int len) : data(data), len(len) {}
char operator[](int i) const { return data[i]; }
};
why no destructor - presumably one would want the ability to free up memory allocated
by any instances.
thx - j |
Re: memblock destructor? |
Posted by Peter Kwan on Apr-19-2017 22:59 |
|
Hi Jim,
MemBlock never allocates any memory. It does not use "malloc" or the "new" operator at all.
What MemBlock does in the constructor is to save the data pointer and the length. The memory must have already been allocated by the object that creates and returns the MemBlock. In ChartDirector charting code, it is usually the BaseChart object. The BaseChart destructor does free up all memory that it allocates, so there is no memory leak.
Regards
Peter Kwan |
Re: memblock destructor? |
Posted by Kevin Flynn on May-19-2021 03:47 |
|
Peter Kwan wrote:
Hi Jim,
MemBlock never allocates any memory. It does not use "malloc" or the "new" operator at all.
What MemBlock does in the constructor is to save the data pointer and the length. The memory must have already been allocated by the object that creates and returns the MemBlock. In ChartDirector charting code, it is usually the BaseChart object. The BaseChart destructor does free up all memory that it allocates, so there is no memory leak.
Regards
Peter Kwan
I was just trying to find an answer to the question of ownership of the memory returned by the makeChart2() function for some mixed C and C++ code I'm working on.
You say that "MemBlock never allocates any memory." So, this is to say, its just returning a pointer and the size, and when the MemBlock instance returned by a call to chart.makeChart2() goes out of scope, the MemBlock instance is destroyed.
Now, as to the pointer to the image data. You say "The BaseChart destructor does free up all memory that it allocates, so there is no memory leak." Is this to say I should not take ownership of the MemBlock.data pointer and free it myself ?
If I want a long lived persistent copy of the generated chart image, I should allocate my own memory using malloc() and then do a memcpy() inside my C wrapper code ?
As an example, my C function wrapper code:
void cdfchart_ImgMake(cdfchart_t *fchart)
{
FinanceChart *fcobj; // C++ object ptr
MemBlock gimg; // generated image
cdfchart_ImgFree(fchart); // free image ( if exists )
fcobj = (FinanceChart *) fchart->cdFcObj; // get ptr to object instance
gimg = fcobj->makeChart(fchart->ImgFmt); // generate chart image
fchart->ImgSz = gimg.len; // store image size
fchart->ImgData = malloc(gimg.len); // allocate long lived chart image memory
memcpy(fchart->ImgData,gimg.data,gimg.len); // copy image -> my memory
}
So in the above example, I'm saving my own copy of the chart image, and leaving all the memory provided by ChartDirector code to manage itself ?
This is the correct method ? |
Re: memblock destructor? |
Posted by Peter Kwan on May-19-2021 21:30 |
|
Hi Kevin,
The MemBlock is just a pointer to some memory inside the BaseChart object that generates the MemBlock. In your code, the memory is inside the fcobj object. The memory is valid as long as fcobj is valid. The memory will become invalid if when you free the fcobjobject.
If you need to keep the memory after freeing the fcobj object, your code needs to make a copy of the memory.
In your code, it seems your code stores the memory pointer in fchart. Your code does not free the fchart or fcobj after creating the MemBlock in the cdfchart_ImgMake. That means the fchart and fcobj remains valid after returning from the function, so it is not necessary to make a copy of the memory. After returning from cdfchart_ImgMake, the memory pointer will remain valid as long as fcobj is valid.
Note that internally, the fcobj only keeps one copy of the memory. If you use the same fcobj to output multiple MemBlocks (which is not common), each time a new MemBlock is created, the previous one will become invalid.
Regards
Peter Kwan |
|