Execute destructor when Dialog closes?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 10:27, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   12 
Platform:      
Language(s) :     C++  ;

---------
I've searched through the archives for info on this. But I couldn't find anything related to what I'm doing.

I'm creating a GeDynamicArray inside of my InitValues() function in a GeDialog plugin. So that the contents of this array are available when the plugin opens. But I don't know where to put the destructor for this array.

I can't put it inside Init because that just wipes out the data as soon as it's added.
And I also tried putting the destructor in the dialog's destructor like this:

myDialog::~myDialog(void)  
{  
  myArray.~GeDynamicArray();    //Destructor to free any memory used by the array  
  GeFree(dlg);  
}

But it doesn't work.

I'm wondering if I have to create the array as a GeDialog class member in order to be able to destruct it when the plugin closes?

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 11:26, xxxxxxxx wrote:

I don't think you can use a destructor like that. Why not just do:

  
myDialog::~myDialog(void)   
{   
    myArray.FreeArray();   
}   

Steve

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 12:38, xxxxxxxx wrote:

@spedler: Actually you can invoke the destructor this way. But you should make sure the destructor isn't called twice.
In the following code-snippets, the wrong methods invoke the destructor twice.

#include <iostream>  
#include <stdlib.h>  
  
class Foo {  
public:  
  ~Foo() {  
      std::cout << "Destructor.\n";  
  }  
};  
  
void wrong1() {  
  Foo foo;  
  foo.~Foo();  
}  
  
void wrong2() {  
  Foo* foo = new Foo();  
  foo->.~Foo();  
  delete foo;  
}  
  
void ok() {  
  Foo* foo = malloc(sizeof(Foo));  
  foo->~Foo();  
  free(foo);  
}

-Nik

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 12:52, xxxxxxxx wrote:

Yes, sorry - I didn't express it very well. I'm sure you can call the destructor like that, what I meant was, is it guaranteed to do what is (presumably) wanted in this case - to free up the memory allocated by the GeDynamicArray class?

I don't know if it would or not. AIUI C++ wouldn't free up allocated memory automatically, so you're relying on the code author having implemented it in the destructor. Logically I suppose that's where it would be done but can you be sure?

Steve

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 12:54, xxxxxxxx wrote:

No, the destructor doesn't free memory, it just does cleanups before deallocation. :)
What the operators new and delete basically do, is allocating/destroying and then constructing/deallocating.

-Nik

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 13:34, xxxxxxxx wrote:

There is no such method .FreeArray() for a GeDynamicArray.
But I did try this:

myDialog::~myDialog(void)  
{  
    myArray.Free();  
    GeFree(dlg);  
}

This doesn't work either. I still get memory leaks from the array.

The example Nux posted lines up with what I was thinking. That we have to declare arrays as class members in order to free the memory when the Dialog closes. But I'm not sure If I really need to do that. Or if it would even work?

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 14:08, xxxxxxxx wrote:

One thing that I have noted before about what you store in a GeDynamicArray is that you must allocate it (not just create it on the stack as a local variable) before pushing it into the array.  It could be that since you are pushing a local variable 'String textPerLine' then you are getting a copy of the string (or worse) which is foiling the array's storage system.  Unfortunately, there is no allocator for the C4D String class.  You may need to gNew each array element String and see if myArray.Free() works as expected.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/06/2012 at 15:17, xxxxxxxx wrote:

Doh! You're right Robert.
The memory leak problem was coming from the fact that I'm filling the array by reading a text file to populate the array.
When I create a GeDynamicArray and fill the elements manually(not from a text file) it doesn't leak.
If I can trust the debugger..I don't even need to use a destructor with it.

Edit - I think I've solved my memory leak problem. See the Text File to an Array thread.

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/06/2012 at 07:36, xxxxxxxx wrote:

Originally posted by xxxxxxxx

There is no such method .FreeArray() for a GeDynamicArray.

Yes there is, in R13. In R12 it's just called Free(), which I see you've tried.

Why Maxon feel the need to rename functions in this way between SDKs when there is no change in parameters or functionality is beyond me.

Steve

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/06/2012 at 10:09, xxxxxxxx wrote:

Sorry about that Steve.
I know it a bad habit. But I tend to work in R12 a lot more than R13. And that sometimes gets me into trouble with the SDK stuff.:wink:

R13 has many nice SDK improvements.
But for some reason the way it's laid out feels uncomfortable to me. And I tend to work faster and more comfortably in R12.

-ScottA

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/06/2012 at 10:58, xxxxxxxx wrote:

I wouldn't call it a bad habit. If you're developing plugins for a range of C4D releases you've got to do the main dev in one and then port to the others. The days when you could develop in Rx and expect that the plugin would run in Rx+1 or even Rx+2 are long gone.

For a long time I developed x-particles in R12 because like you I preferred it. It wasn't until all my beta testers were using R13 instead that I changed! From that experience though, IMO it's a lot easier to develop in an early version and port up than it is to do it in a later version and port down. The reason, of course, is that the later SDK often contains functions missing in the earlier one, which you then have to code separately. And I can tell you that developing in R13 and getting it to run in R11.5 is a serious PITA.

One point though is that with R14 going to appear at some point, developing in R12 leaves you two SDKs behind so you could consider trading up when it's released.