[TommyV]

Sorry, I know this isn't strictly SourceMM, but the plugin it concerns is.

I'm just wondering if any of you use classes with constructors and destructors and dynamically allocate them with new & delete in plugins. I'm doing this in a plugin and seem to be having lots fo problems with bugs, and I dont think I've ever seen new or delete in any of the open source plugins I've looked at. I notice for one that delete doesn't set poiters to null, is this kind of programming a big no no with plugins?

[devicenull]

I use it in a few cases. It's not that hard to pull off if you know what you are doing.

It works fine inside of plugins.

[TommyV]

Thanks devicenull, just wanted to check I wasn't the only one doing this.

[BAILOPAN]

Stripper:Source is open source and uses new/delete extensively. As long as you keep track of your pointers, it's perfectly fine. Stripper tries to aggressively cache pointers (because 'new' is expensive) and I have made bugs with that before.

If you're new to memory management, a few tips:
1) "new" matches with "delete," the array version "new []" matches with "delete []," and "malloc"/"realloc" match with "free." Never mix an allocator with a mismatching deallocator.
2) "new," by definition, cannot return NULL (you can force it to, but I'm saying it just so you don't try to check the return value every time).
3) All three major deallocators (delete,delete[],free) will accept a NULL pointer and do nothing with it. This means you don't have to litter your code with "if" checks.
4) Always, always set invalid pointers to NULL. Just in case.

[TommyV]

Thanks BAILOPAN,

Stripper:Source is one I hadn't looked at, I see you use it a lot in there now. I understand the concepts of memeory mangement, I'm just not that used to C++(or what seems more like C in hl2), and languages that dont keep track of the scope of objects and clean them up with a GC.

The reason I'm craeting classes on the fly is that it seems logical to use constructors, I have an array of pointers to a class that I construct/destruct as players join/leave. The constructor cretaes a recipient filter for the player, makes a manual call class and stores some pointers to their edict and entity. The logic being that once this is done they can be easily accessed at little cost. Does that make sense?

[BAILOPAN]

That makes perfect sense. You need not be worried about efficiency there, as players can't possible join/leave so rampantly that overhead of allocation would take over.