Re: Overloading operator delete problem
Alberto Ganesh Barbati wrote:
kanze ha scritto:
(I'm not sure, but I think that the standard
implementation of new(nothrow) is required to use plain new, so
that just replacing plain new and plain delete should be
sufficient there.)
I could not find evidence of such guarantee. The wording just
says "This nothrow version of operator new returns a pointer
obtained as if acquired from the ordinary version." Few lines
below the standard describes the behavior by presenting a
precise algorithm, so it seems to me that default new and
new(nothrow) are not intended to depend on one another.
That's interesting. I'll admit that I hadn't checked, but this
means that if you replace the standard new, you'd better replace
the standard new (nothrow) (and delete (nothrow) too).
I guess the idea was to allow this kind of implementation:
void* operator new(size_t n)
{
for(;;)
{
void* ptr = malloc(n);
if(ptr)
return ptr;
if(!_new_handler)
throw bad_alloc();
_new_handler();
}
}
void* operator new(size_t n, nothrow_t) throw()
{
for(;;)
{
void* ptr = malloc(n);
if(ptr)
return ptr;
if(!_new_handler)
return 0;
try
{
_new_handler();
}
catch(bad_alloc)
{
return 0;
}
}
}
As you can see, the try-block of new(nothrow) is entered only
if allocation fails the first time and the user provided a
new-handler. On platforms where entering a try-block have a
performance hit, this could be better than an implementation
based on regular new, which would always require entering the
try-block:
void* operator new(size_t n, nothrow_t) throw()
{
try
{
return ::operator new(n);
}
catch(bad_alloc)
{
return 0;
}
}
Agreed, although I think the real difference is when you don't
have a user set new_handler. Presumably, if I'm using
new(nothrow), it's because I expect it to fail from time to
time, and can handle failure. Execution time when it fails will
be decidedly better when there is no exception.
This implies, as you pointed out, that each time an
application provides a replacement function for global
operator new, it should also provide a replacement for the
nothrow version.
Historically, of course, this created a portability problem,
when some compilers supported new(nothrow), and others didn't
(yet). I would hope that it isn't a problem today.
I does mean that I'll have to update my own debugging operator
new/operator delete:-).
I find this lack of clarity an inconvenient. Maybe the
standard should specify more explicitly the relationship
between new and new(nothrow) or the lack of it. Any ideas?
Just that it's a general problem. In the past, I've pointed out
similar problems concerning other related functions, e.g.
overflow and sync in filebuf.
Generally, they're not serious problems. In this case, just
replace all of the operator new functions, and you're safe. In
the case of overflow and sync in filebuf, you only have a
problem if you're trying to derive from filebuf to change its
behavior, so the answer is: don't do that.
--
James Kanze GABI Software
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]