Printable View
I was wondering if it was possible to detect if a given pointer to a function was allocated dynamically or not.
From what I know, dynamic memory is located on the heap, and static memory is located on the stack.
I have a particular function that I want only to accept memory that was created with the 'new' keyword, or dynamic memory.
Other wise it should return, ignoring any value submitted to it.
I'm not sure if that is possible.
One solution might be to overload global new and delete yourself. Then you can allocate an extra byte, then in your function look for a specific value in that extra byte. Kinda like the Microsoft debug libraries work to detect "array out of bounds" errors.
Viggy
No, not portably. Scott Meyers has a lengthy discussion of why this is not possible in one of his "Effective" books.Quote:
Originally Posted by MrDoomMaster
Now the question is why do you care where the memory comes from? If you are given a pointer to foo, then it is a pointer to foo no matter where it comes from. If it is documented that the object must be created with some sort of allocator (whether it is new, or some other allocator), then let the user of your class suffer the consequences if they don't read the documentation.
If that is not enough, then make your objects have private constructors and destructors, and have public static functions that create and destroy the objects. In this case, the user would have to explicitly ask for an object to be created by calling one of the static functions, and your "object creator" creates it for them. Then you don't run the risk of the user creating objects in ways you don't want them created. This is called the factory pattern.
Regards,
Paul McKenzie
I am creating a class capable of managing dynamically allocated objects that may be used globally between various functions. This is why I must be able to detect if a pointer is dynamic or not, because my class forces 'delete' on every pointer submitted to it.
As suggested earlier, provide a method to the class that makes the allocation internal to your class and returns a pointer. The method would new the memory, add it to the internal list, and return the pointer. When a Release() method is called, that item gets deleted and removed from the list. Or when the container class is destroyed, all the list members get deleted.Quote:
Originally Posted by MrDoomMaster
Really, as Paul suggested, the simple way to handle this is to control how your objects get created (then you don't need to worry about the difficult task of determining how to cleanup memory - like delete, free, TaskMemFree, etc.).
Arjay
Well, here is a link. Note that none of these methods are foolproof:
http://www.tarma.com/articles/index....es/1997jan.htm
Regards,
Paul McKenzie
What if I allocated an array with new[], how will your class know to call delete[] as opposed to delete? The pointer returned by new[] will more than likely have similar properties as a pointer to plain new. In general, how would your class know which deallocator to use (delete, delete[], free, maybe GlobalFree if you're working with Windows, etc.)?Quote:
Originally Posted by MrDoomMaster
This is why I believe you should control how the objects are created.
Regards,
Paul McKenzie
Good point.
See, this all started with a difficulty of not being able to organize a certain situation in my code.
I have a class that has a constructor which requires a handle to a created dialog. The thing is, my dialog is created locally to WinMain(), but the class which needs this dialog handle is needed in more than one function, so I have to place it globally.
Basically I end up having to have a global pointer to the class, and add a dynamic construction of the class to this pointer in WinMain AFTER I create my dialog, this way I have a dialog handle!
The thing is this could get messy if you have 20 objects of this class. You will be creating 20 global pointers, 20 calls to 'new' and 'delete'.
Very messy.
I was thinking of a class that could be used on any data type. You call 'Class::CreateNew(std::string Name)' and it will create a new dynamic data type that is specified at class declaration via a template. Once this dynamic data is created, a pointer to it is stuffed in a list inside the class. Later on, to access this data you simply do: 'Class::Access(std::string Name)' and it will return a pointer to the data, so you could simply access it like:
ClassObj.Access("MyVarName")->ObjectMemberFunction();
Seems okay, right? Then in the class destructor you simply iterate through the list and call 'delete' on every element.
I can't think of a better way to manage global dynamic data! Especially when you face the situation I had previously explained.
I would still structure this differently and not use a [hWnd] handle to track the dialog. When you create your dialog, you return a hWnd to the dialog (according to your other post). Instead of doing this, consider creating a CDialog class and have it manage the hWnd internally. When this class goes out of scope, it takes care of deleting it's own resources (like the hWnd, any resources, child windows, etc.).
The more your class(es) become full featured, the more they will approach the MFC and ATL frameworks. Btw, looking throught the ATL source is a great way to get some ideas on building lightweight wrappers around Win32 windowing - it doesn't just to COM.
Arjay
I can't really use MFC for my purposes. I need to stick with Win32
I'm not suggesting you use MFC, I'm suggesting that you look at MFC and ATL for ideas toward creating a framework (ATL especially).