To remove or not to remove (call func)?
The problem with removing an application built in lib is that lib might be using a different heap / memory manager.
Solutions include:
- Make sure your application is built with the same heap manager as the library.
- Implement a (not inline) deleteMe method in a class whose implementation can be
delete this;
- Define a custom
operator delete
within a class implemented in the library ... if a custom statement deletes then it is called if and when your application deletes the object's value.
source to share
I remember someone said that if you create a class via lib, you must destroy it via lib.
This means that if you call a function in lib to create an object for you, you should read the documentation for that function, which should tell you how you will free that object again. Often the function for free something is called a similar distribution function. For example, a library pcre
has two functions: pcre_malloc
and pcre_free
.
The reason is that the library gives you opacity (this is the reason you use this function in the first place). It can get memory from the program's data section, while you (erroneously) assumed that it got memory, possibly from the heap in use delete
.
If you are the author of this library, the same rules apply. Make sure that when one of your functions returns a dynamically allocated object you are telling how the caller should handle it
- Is the object encapsulated in a smart pointer? Then the smart pointer will take care of calling the appropriate deleter you specified.
- Are you returning a raw pointer? You should avoid doing this because the caller must keep track of the pointer and the caller must pass the pointer to the function that you are documenting in your interface. This is another layer of dependency that you place on the burden of the user of your library that smart pointers can elegantly rationalize.
- Are you returning an object by value that wraps the allocated resource by itself? If so, overload the copy constructor, the copy assignment operator, and the destructor of that object class, which then manages the resource, either by copying it correctly or by splitting it among all other instances of its object (see this answer ).
You should almost never overload the delete operator for your class unless you overload the new operator. Overloading the delete operator should not be taken literally: it means that you are simply overloading the deallocation of the object's associated memory. This makes sense if you have your own memory pool or want to log every memory allocation / deallocation for your objects.
source to share
This rule applies to classes that you . A rule of thumb (though not always used) is that if a class creates an object, it should delete it.
But if you are asking about some library that someone else has developed, you cannot know if he followed this rule and you need to check it through himselef / documentation / code.
source to share
You should read the library documentation on how to delete the generated objects. Apart from what others have mentioned, sometimes there is a wait in the library for objects to be disposed of. For example, in wxWidgets, you don't have to delete widgets yourself, because wxWidgets will try to delete them for you when their parent widget is destroyed - if you've already deleted them, you'll have double free behavior (undefined). You can't figure it out simply by looking at the types - libraries can work that way even if they don't return a smart pointer. Also, a library can depend on deallocations happening in a specific order (for example, it might always deallocate all objects of one type before another), and deleting things on its own destroys the order.
source to share
If your library provides a specific method to create objects in terms of memory management and so on, then you can be there , so you can get rid of this facility except by means of a meaningful process that would destroy objects in the same way as it was created / allocated.
In other words, if your objects tend to stand out in a certain way, make sure that all the ways to get rid of them follow your "certain path".
source to share