On 12/04/2015 at 08:51, xxxxxxxx wrote:
Hi, sorry for my inactivity.
Originally posted by xxxxxxxx
I'd like to help you, but I don't have enough information yet to determine what situation you are in. Specifically, the HashMap holds what type of data? If it's simple data or even a struct that only contains simple data (integers, chars, floats, bools) then you shouldn't have any problems just using HashMap::Reset(). However, it can be insufficient if it contains:
- Objects that may contain dynamic memory
- Objects that use objects that contain dynamic memory
- Pointers to any kind of data, whether simple or objects of the kind mentioned above
It all depends on the specific implementation of each part. HashMap::Reset() is enough in some cases, but not all, especially if it contains pointers: pointers themselves do not get destroyed because they only contain address values, but what they point to has to be destroyed to avoid problems.
Let me know the details of each case (if it's more than one HashMap), and we'll figure it out.
SDK Support Engineer
I see three different situations similar to what you've mentioned already:
- The HashMap contains a simple data type that does not require explicit deallocation or do not
perform such in its destructor
- The HashMap contains a data type that deallocates memory using GeFree() in its destructor
- The HashMap contains a pointer that must manually be freed before calling HashMap::Reset()
For #3, it's crystal clear to do the deallocation in PluginEnd() at the very least and then call Reset()
(although it might not be necessary, it's definitely a good choice to do it after the deallocation of
For #2, if you do not call HashMap::Reset() in PluginEnd() but instead let the HashMap destructor
handle it, the time at which the destructors are called will be after PluginEnd().
For #1, this a concern that I also have for #2, the HashMap must deallocate its elements/nodes/entries
that contain the key/value pairs. Again if Reset() is not called in PluginEnd(), the HashMap will be
destroyed when the DLL/DYLIB is unloaded.
What it basically breaks down to is the following: Can GeFree() still be called after PluginEnd(),
or at the time the DLL/DYLIB is unloaded?
The reason I ask is because you can not before PluginStart() because the C4DOS is not initialized. If
you have a global String (not pointer, just a plain String object), your plugin will not load with (at
least on Windows) a "pure virtual function call" error window, because the String constructor, which
is called when the DLL/DYLIB is loaded, before PluginStart(), will use the C4DOS function table.
@Remo: Thanks for the test, but from your output you didn't show if C4DOS was still valid
when GlobalData was destroyed? I just want an official statement know if that is intended that it
will work without a crash or if that might change at any time. :)