Determine if c++ Object are on stack or on heap ...
We need some phrase or image for when someone is given tons of good advice, and decides based on that advice to take the most idiotic possible route.
Quote:
Fo exemple, if i need to create a file object ( which is referenceable in my system ), in order to use it in a simple loading function, actually i must allocate it on the heap....
But it would be more convenient to be able to also use it as a stack allocated object ....
Zero need whatsoever for determining heap or stack allocation.
void load( const File &f );File f_stack;File *f_heap = new File();smart_ptr<File> f_smart;load( f_stack );load( *f_stack );load( *f_smart );You should be using references and stack allocated objects everywhere in the first place.
If you can't, and really can't, then use smart pointers.
The reason for this is two-fold. One - references cannot be null or invalid. Two - the life-cycle management is not available to function, which removes a lot of headaches about ownership.
If you can prove that you ever need a smart pointer to an object on the stack then I'll help you get around the problem. Otherwise, simply don't do it!
Quote:Original post by Promit
We need some phrase or image for when someone is given tons of good advice, and decides based on that advice to take the most idiotic possible route.
You mean something like this?
Author
Okay okay ....
So after a few reflexion, here is in fact what i need:
I way to detect if a smart pointer is pointing to an object that is allocated on the stack, in order to do an assertion. ( To inform the user that it's not allowed to have a pointer point to a stack allocated object )
I have try with the CrtIsValidHeapMemory function, but it seam that i must make all my memroy allocation using crt_malloc, which is actually not the case ....
:(
Any idea ???
thanks again :)
Clement
So after a few reflexion, here is in fact what i need:
I way to detect if a smart pointer is pointing to an object that is allocated on the stack, in order to do an assertion. ( To inform the user that it's not allowed to have a pointer point to a stack allocated object )
I have try with the CrtIsValidHeapMemory function, but it seam that i must make all my memroy allocation using crt_malloc, which is actually not the case ....
:(
Any idea ???
thanks again :)
Clement
Override the global new/delete operators, keep track of who allocates what.
When a smart pointer is created, check to see if this memory was allocated. If it wasn't, it's on stack. That is of course assuming several things about memory allocations, but it's probably your best bet.
The other solution is to simply make the smart pointer oblivious to actual location of memory, and do what boost does, advise that proper usage is to only use smart pointers for dynamically allocated memory.
Third solution might be to look into how your compiler manages memory, then calculate whether the address provided is within stack or heap region.
The language itself doesn't deal with this. Those are all implementation and OS specific issues.
When a smart pointer is created, check to see if this memory was allocated. If it wasn't, it's on stack. That is of course assuming several things about memory allocations, but it's probably your best bet.
The other solution is to simply make the smart pointer oblivious to actual location of memory, and do what boost does, advise that proper usage is to only use smart pointers for dynamically allocated memory.
Third solution might be to look into how your compiler manages memory, then calculate whether the address provided is within stack or heap region.
The language itself doesn't deal with this. Those are all implementation and OS specific issues.
Quote:
I way to detect if a smart pointer is pointing to an object that is allocated on the stack, in order to do an assertion. ( To inform the user that it's not allowed to have a pointer point to a stack allocated object )
This seems like a waste of time to me. You'll be going to a lot of effort to detect an edge case that arises from of a programmer intentionally attempting to subvert your API. The fact that you should not store pointers to stack-allocated objects for an indeterminate period of time should be something every minimally competent C++ programmer is aware of (similar to how you should never return pointer or references to stack-allocated local variables from functions).
It is folly to attempt to protect your code from intentional subversion by a programmer. You're only going to make more work for yourself and hamper the legit users of your API. I seriously would not bother.
Here is a crazzy crazzy idea!
Read ESP register: (may be like this)
you may dig into this...
Read ESP register: (may be like this)
DWORD get_ESP(){ DWORD rv; __asm{ move rv,ESP}; return rv;}upper = get_ESP()& 0x FFFFF000;if((unsigned long)&your_variable & 0xFFFFF000 == upper) // yeah is on stack..you may dig into this...
Ew.
That is not a scalable technique, and it won't even work for all cases on one specific OS/CPU/etc, either (after all, what you technically need to be aware of are objects that were not allocated with new, not objects that are on the stack).
This is still a bad idea.
That is not a scalable technique, and it won't even work for all cases on one specific OS/CPU/etc, either (after all, what you technically need to be aware of are objects that were not allocated with new, not objects that are on the stack).
This is still a bad idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
