GeDialog ~Deconstructor
-
On 20/06/2013 at 02:38, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R14
Platform: Windows ;
Language(s) : C++ ;---------
Hi Folks,I have a dialog buried inside an object plugin. But Cinema crashes upon trying to free the global bitmaps I've used. Example of what I have below:
~MYDIALOG(void) { BaseBitmap::Free(MyBitmap); // crashes Cinema }The same code layout works fine in my object plugin. What might be causing this to happen?
WP.
-
On 20/06/2013 at 04:10, xxxxxxxx wrote:
"global bitmaps" does not sound good in combination "freeing in dialog destructor". Are they still
referenced somewhere else at the time the dialog destructor is called?The time the destructor is called also depends on the context, btw. For a modal dialog, you usually
construct the dialog, open it, and then it gets destroyed. For an async dialog which is usually kept
as a local attribute to a CommandData plugin, the dialog is destroyed at the time the command data
plugin is destroyed.-Niklas
-
On 20/06/2013 at 06:31, xxxxxxxx wrote:
To further what NiklasR says, it is better OOP to make class instance allocations owned by a particular class and not global for the sake of keeping control. When you use class members as allocation parameters, set them to NULL in the constructor and free the memory in the destructor (at the least). When you deallocate memory, always set the 'primary' pointer to NULL to avoid attempts at false deallocation later. In C++, ownership of memory is tantamount and you must account for ownership and verification of allocation and deallocation.
-
On 20/06/2013 at 11:36, xxxxxxxx wrote:
Thanks Robert and Niklas,
just to clarify, the bitmaps are "global" to the GeDialog class. So they're class level variables - I should have been a bit clearer there. They do have the same names as bitmaps in other classes but I didn't think that would matter? They're just drawn once in the constructor, used in the Draw() function where/when needed, and freed/destroyed in the deconstructor. Just got into the habit of making bitmaps in the constructor if they only need drawing once.
Re the memory, I don't mind looking after that, though I admit I'm not entirely clear on how all the alloc/dealloc works yet. That's still a lesson in progress!
The thing I found is that using prints to the console, it's clear that Cinema gets to the first BaseBitmap::Free(bmp) line in the deconstructor, then crashes. So no prints occur after that line.
WP.
UPDATE: OK I've added an "= NULL" first before freeing them. Not sure why it works without that in one part of the plugin, but another needs the nulling. Anyway, for the purposes of this posting, answer found.
-
On 20/06/2013 at 12:50, xxxxxxxx wrote:
Why not try something like this ?
class MaDialog : public GeDialog //please do not call is MySomething in production code ! { AutoAlloc<BaseBitmap> mBitmap; public: MaDialog() {} ~MaDialog() { mBitmap.Free(); //actually you do not need this. } //... void SomeFunction() { mBitmap->Init(...); } }or
class MaDialog : public GeDialog //please do not call is MySomething in production code ! { AutoFree<BaseBitmap> mBitmap; public: MaDialog() { mBitmap.Assign( BaseBitmap::Alloc ); //would be bettter to use Reset here :) } ~MaDialog() { mBitmap.Free(); //actually you do not need this. } //... void SomeFunction() { mBitmap->Init(...); } } [/codd] -
On 20/06/2013 at 13:03, xxxxxxxx wrote:
Hi there Remo,
I didn't think we were able to use AutoAlloc or AutoFree at a class level. I think I thought that because of not being able to give variables a value at that level. Though it was partly also because I was using it to learn to look after memory myself.
But thanks for that, I'll note and try remember that one! Would probably save a bit of needless coding!
WP.