Detecting stack or heap instances

Hi,

I have code like this in my legacy class library :-

class Base
{
public:
void* operator new (size_t size);
Base();

private:
unsigned int magic;
}

void* Base::operator new(size_t size)
{
void *newobj = ::operator new(size);//call global operator new

//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}

//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}

All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-

1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?

2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

Thanks in advance

Anu.

Anu wrote:

Quote:

Hi,
>
I have code like this in my legacy class library :-
>
class Base
{
public:
void* operator new (size_t size);
Base();
>
private:
unsigned int magic;
}
>
>
void* Base::operator new(size_t size)
{
void *newobj = ::operator new(size);//call global operator new
>
//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}
>
//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}
>
All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-
>
1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?
>
2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

The only concern I'd have would be with descendants of Base if they
have virtual functions. But thinking about it, the vtbl pointer is
usually written to the object as part of constructing, so when some
descendant's c-tor puts the proper vtbl into the object's memory,
the Base's c-tor has already done its stuff.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Apr 16, 3:01 pm, "Anu" <annu_iyer2...@yahoo.co.inwrote:

Quote:

I have code like this in my legacy class library :-

Quote:

class Base
{
public:
void* operator new (size_t size);
Base();
>
private:
unsigned int magic;
}

Quote:

void* Base::operator new(size_t size)
{
void *newobj = ::operator new(size);//call global operator new
>
//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}

Quote:

//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}

Quote:

All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-

Quote:

1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?

In other words, apart the fact that it doesn't work, is there
any other problem?

Quote:

2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

No. Formally, it's undefined behavior, period. In practice,
try it with virtual inheritance, or even ordinary multiple
inheritance, and it won't work.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Detecting stack or heap instances

re: Detecting stack or heap instances

re: Detecting stack or heap instances

/bytes/development

/bytes/it

/bytes/about