On 10/02/2012 07:33 AM, Patrick J. LoPresti wrote:
> In C++ -- all versions
> ever, standard or otherwise -- calling "delete" on a NULL pointer is
> guaranteed to be a no-op. So there is never a need to check for NULL
> before calling "delete". Doing so makes your code run slower,
Not necessarily. In *your* favorite "modern" CPU, a transfer of control
to a non-local destination can cost 15 times as much as a local test-and-
skip-over, depending on branch prediction and Icache misses. Particularly
if 'delete' has not been called recently, then code which uses a local
guard might be faster.
> makes
> it harder to read, and makes the reader wonder whether the author
> simply does not know C++ or is trying to work around some obscure bug
> in some compiler.
It is true that the test is functionally superfluous.
It is also true that prevalent compilers don't make the obvious optimization
of removing the test. Therefore I hope that you complain just as loudly
to the maintainers of such compilers as you complain to users who write
such code.
It is also true that writing
-----
201: if (ptr)
202: delete ptr;
-----
provides a convenient debugging point which can be inserted easily
("break foo.c:202") using gcc and gdb/ddd/etc instead of using
a condition ("break foo.c:201 if ptr"). An unconditional breakpoint
is much faster (no dynamic cost unless triggered) than a conditional one.
Thus the explicit test can provide a practical benefit
even if it is functionally redundant.
--
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
