By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,406 Members | 1,031 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,406 IT Pros & Developers. It's quick & easy.

overriding global new and delete + STL

P: n/a
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?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
shoosh <sh********@walla.co.il> writes:
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.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #2

P: n/a
shoosh wrote:
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.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jul 23 '05 #3

P: n/a
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.
"Thomas Maeder" <ma****@glue.ch> wrote in message
news:m2************@madbox2.local...
shoosh <sh********@walla.co.il> writes:
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.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #4

P: n/a

"shoosh" <sh********@walla.co.il> wrote in message
news:ct**********@news2.netvision.net.il...
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #5

P: n/a

Dietmar Kuehl wrote:
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #6

P: n/a
shoosh wrote:
#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()'.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.