Detecting pointer on the heap [C++]

Prev: performance of hash_map in combination with strings on vstudio 2003
Next: Dot operator Overloading

From: Mickey on 31 Mar 2010 23:02

On Apr 1, 12:39 am, pfultz2 <pful...(a)yahoo.com> wrote:
> I want detect if a pointer is pointing to memory on the heap or the
> stack, so I came up with this approach:
>
> bool isOnHeap(void * p)
> {
> int i = 0;
> int * s = &i;
> return (p > s);
>
> }
>
> I dont if this is the best or most portable way to do it. And im not
> sure how well it works for static and global variables, do they start
> on the end of memory? or at the begining? The reason why i want to do
> this is need to delete pointers sometimes, and some of them point to
> memory on the stack, so therefore i dont want to delete them, I could
> use type erasure and create a seperate class to handle the memory and
> use some form of custom deallocators, but then it would either cost me
> an extra pointer or double dereferencing, and i was trying to think of
> a neater way to do it. thanks.

{ edits: quoted banner removed. please keep readers in mind when quoting. -mod }

No, this function will not work in all scenarios. Let us not even get into
different platforms and compilers. In C++.... Why do you think you require
such a function? Isn't constructor/destructor mechanism sufficient for your
purpose. And Standard C++ library is already safe in this sense.

This link might be of help:
http://bytes.com/topic/c/answers/588820-how-stack-grows

Regards,
Jyoti

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Goran on 31 Mar 2010 23:04

On Mar 31, 9:39 pm, pfultz2 <pful...(a)yahoo.com> wrote:
> I want detect if a pointer is pointing to memory on the heap or the
> stack, so I came up with this approach:
>
> bool isOnHeap(void * p)
> {
> int i = 0;
> int * s = &i;
> return (p > s);
>
> }
>
> I dont if this is the best or most portable way to do it. And im not
> sure how well it works for static and global variables, do they start
> on the end of memory? or at the begining? The reason why i want to do
> this is need to delete pointers sometimes, and some of them point to
> memory on the stack, so therefore i dont want to delete them, I could
> use type erasure and create a seperate class to handle the memory and
> use some form of custom deallocators, but then it would either cost me
> an extra pointer or double dereferencing, and i was trying to think of
> a neater way to do it. thanks.

No flames yet? Strange. Ok, I'll volunteer.

You should forget all you have been thinking of so far. Whatever you
might have in your head is a BAD IDEA, and I am confident enough of
that even without knowing what you are trying to do.

There is NO "neater way" but to KNOW, at any point in your code, what
you need to do with any object/variable. Consequently, you must
organize your code so that, for a given pointer, YOU know when/if you
are supposed to "delete" pointed-to object.

In C++, just like in C and a host of other languages, you manage heap
manually. Put up or get out, simple as that. Now, there is a host of
approaches and solutions to simplifying heap management, and C++ is
rather strong in this domain. So if you have a particular situation to
handle, ask, I am positive that people here will be able to help you
if you ask the right question.

By the way, neither C nor C++ language specify in any way how is
memory organized. There is no "heap is after stack", nor any similar,
rule. Exploring this is a serious DELUSION.

Goran.

"In C++, OOP means "Object Ownership Protocols" - master_troll.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: bahadirdogan on 31 Mar 2010 23:07

From: gast128 on 1 Apr 2010 02:16

There was a non portable way (only on x86 nt based Windows systems) to
detect a stack based pointer, which can be used for exclusion of
pointers. It works by determining the TIB (thread information block)
which has stack base and stack top information fields.

bool IsPointerOnStack(const void* p)
{
//_CrtIsValidHeapPointer() returns always true for pointers on
stack
PTIB pTib = NULL;
WORD fsSel = 0;

__asm
{
mov eax, fs:[18h]
mov [pTib], eax
mov [fsSel], fs
}

//sanity check, if it fires tib structure is probably changed
_ASSERT(static_cast<void*>(pTib->ptibSelf) ==
static_cast<void*>(pTib));

//note: works only on on NT:
if (GetCurrentThreadId() != pTib->TIB_UNION2.WINNT.threadID)
{
//dangerous to use pointers on stack for diff. thread
_ASSERT(false);
return false;
}

if ((pTib->pvStackUserBase < p) && ( p < pTib->pvStackUserTop))
{
return true;
}

return false;
}

//from Matt Pietrek:
#pragma pack(1)

typedef struct _TIB
{
PEXCEPTION_REGISTRATION_RECORD pvExcept; // 00h Head of
exception record list
PVOID pvStackUserTop; // 04h Top of
user stack
PVOID pvStackUserBase; // 08h Base of
user stack

union // 0Ch (NT/Win95 differences)
{
struct // Win95 fields
{
WORD pvTDB; // 0Ch TDB
WORD pvThunkSS; // 0Eh SS selector used for thunking
to 16 bits
DWORD unknown1; // 10h
} WIN95;

struct // WinNT fields
{
PVOID SubSystemTib; // 0Ch
ULONG FiberData; // 10h
} WINNT;
} TIB_UNION1;

PVOID pvArbitrary; // 14h Available for application use
struct _tib* ptibSelf; // 18h Linear address of TIB structure

union // 1Ch (NT/Win95 differences)
{
struct // Win95 fields
{
WORD TIBFlags; // 1Ch
WORD Win16MutexCount; // 1Eh
DWORD DebugContext; // 20h
DWORD pCurrentPriority; // 24h
DWORD pvQueue; // 28h Message Queue selector
} WIN95;

struct // WinNT fields
{
DWORD unknown1; // 1Ch
DWORD processID; // 20h
DWORD threadID; // 24h
DWORD unknown2; // 28h
} WINNT;
} TIB_UNION2;

PVOID* pvTLSArray; // 2Ch Thread Local Storage array

union // 30h (NT/Win95 differences)
{
struct // Win95 fields
{
PVOID* pProcess; // 30h Pointer to owning process
database
} WIN95;
} TIB_UNION3;
} TIB, *PTIB;

#pragma pack()

However I also agree with other users, that u should really rethink
why u want to use this in the first place. Consider garbage collectors
or shared_ptr's if u have problems tracking down ownership of pointers.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: rado on 1 Apr 2010 06:56

On Mar 31, 12:39 pm, pfultz2 <pful...(a)yahoo.com> wrote:
> I want detect if a pointer is pointing to memory on the heap or the
> stack, so I came up with this approach:
>
> bool isOnHeap(void * p)
> {
> int i = 0;
> int * s = &i;
> return (p > s);
>
> }
>
> I dont if this is the best or most portable way to do it. And im not
> sure how well it works for static and global variables, do they start
> on the end of memory? or at the begining? The reason why i want to do
> this is need to delete pointers sometimes, and some of them point to
> memory on the stack, so therefore i dont want to delete them, I could
> use type erasure and create a seperate class to handle the memory and
> use some form of custom deallocators, but then it would either cost me
> an extra pointer or double dereferencing, and i was trying to think of
> a neater way to do it. thanks.

{ edits: quoted banner removed. please keep readers in mind when quoting. -mod }

You might consider some relatively recent additions to boost (in
<boost/fancy/memory.hpp>). These are quite useful functions. They are
implemented using some really-fancy template techniques.
Here's a little excerpt:
bool is_heap_ptr (const void* ptr);
bool is_stack_ptr (const void* ptr);
bool is_static_ptr (const void* ptr);
bool is_auto_ptr (const void* ptr);
Additionally, there a couple of functions aimed at supporting
debugging (note: applicable to heap pointers only; throw exceptions if
used with other pointers!):
bool is_deleted (const void* ptr);
bool is_allocated (const void* ptr).
bool is_referenced (const void* ptr).
I am surprised that nobody here didn't mention these. Check them out,
and good luck :-)
-- Radoslav Getov

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First | Prev | Next | Last
Pages: 1 2 3 4 5 6
Prev: performance of hash_map in combination with strings on vstudio 2003
Next: Dot operator Overloading