overriding global new and delete + STL

S

shoosh

hi
for my application under VC6 I need to implement my own memory manager
which overrides the global new and delete operators and which Do Not
use the normal free() and malloc().
it seemed to work fine on its own but when I tried to use say 'cout' or
'cerr' from STL
the tester crashed upon termination.
using some breakpoints I found out that when I make use of 'cerr' in the
program, there
is a call to my override of delete which do not correspond to any call to my
override to new. infact, with just a main() saying:
int main() {
cerr << "boo";
return 0;
}
all I got was a break in my operator delete and no breaks at all in my
operator new.
how is the memory allocated if now by using my operator new? where does this
pointer come from?

does anyone know anything about this issue? any help?
 
T

Thomas Maeder

shoosh said:
using some breakpoints I found out that when I make use of 'cerr' in the
program, there
is a call to my override of delete which do not correspond to any call to my
override to new. infact, with just a main() saying:
int main() {
cerr << "boo";
return 0;
}

Please post the entire program, including the overloaded
(de)allocation functions.
 
D

Dietmar Kuehl

shoosh said:
how is the memory allocated if now by using my operator new?

I'm a little bit rusty on replacing operators new and operator delete
but I could imagine that the memory is allocated with the 'nothrow'
version of 'operator new()' but deleted with the normal 'operator
delete()'. That is, you might want to add the following function:

/**/ void operator new(std::size_t sz, std::nothrow const&) throw()
/**/ {
/**/ ...
/**/ }

A brief glance at the standard just states that both version of
'operator new()' are replaceable but there is no statement that they
need to be replaced together. Of course, this makes for an interesting
problem: as an implementer of the standard C++ library I would probably
implement the throwing version in terms of the not throwing one. Of
course, if a user replace the throwing version, 'operator delete()' may
get called with memory not allocated from his replacement version
because the nothrow version is called somewhere. Since there is no way
to detect whether the not throwing one is replaced, there is no chance
to do it correctly: even if the operators are implemented the other way
around things could break. All the user needs to do is to replace the
'operator new()'. Probably the standard is defective if it does not
state that both versions of 'operator new()' need to be replaced if one
is replaced.
 
S

shoosh

the whole new Memory manager I wrote it not relevant to the discussion and
is too big to post.
yet the problem I describe can be recreated simply, like so:

#include <stdio.h>
#include <iostream.h>
#include <stdlib.h>


void *operator new( size_t stAllocateBlock )
{
printf("Memory block %d allocated for %d bytes\n" ,++cBlocksAllocated,
stAllocateBlock);
return NULL;
}
// User-defined operator delete.
void operator delete( void *pvMem )
{
printf("Memory block %d deallocated\n", --cBlocksAllocated);
}

int main( int argc, char *argv[] )
{
cout << "YEA!" << endl;
return 0;
}


running this code results in the following output:
YEA!
Memory block -1 deallocated
Memory block -2 deallocated

which means the my override of delete ran twice and the override of new did
not ran at all.
if I loose the 'cout' line and the #include <iostream.h> the output is
nothing.
 
P

Paul

shoosh said:
the whole new Memory manager I wrote it not relevant to the discussion and
is too big to post.
yet the problem I describe can be recreated simply, like so:

#include <stdio.h>
#include <iostream.h>

Use <iostream>, not <iostream.h>.

<iostream.h> is non-standard, so there is no telling what this thing does
for some cases.

<iostream> is the standard header, and will exhibit (or should exhibit)
standard-conforming behavior. Once you do this, you have to remember that
cout is now in the std namespace, and you must adjust your code accordingly.

Paul McKenzie
 
M

msalters

Dietmar said:
A brief glance at the standard just states that both version of
'operator new()' are replaceable but there is no statement that they
need to be replaced together. Of course, this makes for an interesting
problem: as an implementer of the standard C++ library I would probably
implement the throwing version in terms of the not throwing one. Of
course, if a user replace the throwing version, 'operator delete()' may
get called with memory not allocated from his replacement version
because the nothrow version is called somewhere. Since there is no way
to detect whether the not throwing one is replaced, there is no chance
to do it correctly: even if the operators are implemented the other way
around things could break. All the user needs to do is to replace the
'operator new()'. Probably the standard is defective if it does not
state that both versions of 'operator new()' need to be replaced if
one

A footnote would be nice, but if I replace one to forward to the other,
I would like it to work. This logically works (when the allocation
succeeds, the same value is returned and delete doesn't care how it
got that value) but your extra wording would prohibit it. Not sure
if there's a good reason to do so, but it would work as long as
any implementor is reasonably careful.

The tricky point for implementors is that if the built-in throwing
unconditionally forwards to the non-throwing, and the user replaces
only that one to forward to the throwing, you end up with a loop. So
an implementor probably has to call some shared __new() (or malloc())
from both versions of the default operator new.

With this implementation, replacing either version of new to forward
to the other will work ok, including deletion.

Regards,
Michiel Salters
 
D

Dietmar Kuehl

shoosh said:
#include <iostream.h>

I don't know whether it is related to your problem but you should get
rid
of this header as soon as possible: it is non-standard. You should use

/**/ #include <iostream>

(i.e. without the ".h") instead.

Other than that, I would guess that you should also replace the
"nothrow"
version of 'operator new()'.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,982
Messages
2,570,185
Members
46,738
Latest member
JinaMacvit

Latest Threads

Top