From: Paul Rohr (paul@abisource.com)
Date: Mon Jun 03 2002 - 11:00:56 EDT
At 04:33 PM 6/2/02 +0200, Joaquín Cuenca Abela wrote:
>On Thu, 2002-05-30 at 20:23, Tomas Frydrych wrote:
>> > In short, the whole reason we created those macros was to ensure that
>> > all delete, free, etc. calls did all of the nice null-sanity work
>> > you'd usually want. Thus instead of typing the risky:
>> >
>> > delete m_pHeaderSL;
>>
>> Correct me if I am mistaken, but the c++ operator is designed to
>> handle NULLs, so it is not really necessary to this kind of a check;
>> its a different story with free though, isn't it?
>
>afaik free should also handle NULLs, but it was not the case in older
>versions of ANSI C, so I guess that there are still out there some
>compilers that don't handle the free(NULL); case
Yep. I chose a bad example in my original post. FREEP needs to do the null
check first for exactly this reason.
I suppose that theoretically you might want the null check in DELETEP to
guard against a malicious/incompetent plugin who implemented a class that
overrode the delete operator in ways that didn't check for nulls. If that
sounds as ridiculous to everyone else as it does to me [1], then by all
means simplify the macro accordingly.
The whole point of the original message stands, though -- there's definitely
no need to null-guard any calls to DELETEP and friends. ;-)
>Btw, if we want to keep DELETEP, we can make it a bit more useful than
>now (the only useful bit right now if the ptr = NULL; part).
I can't comment on the suggested modification, but I would recommend we keep
*some* well-tuned version of DELETEP and friends. Not only do they save
typing, but they've also fixed a number of bugs in the past.
Paul
[1] Given how wide-open our current ABI_EXPORT strategy is for enabling
plugins, there are many less-obscure ways for a broken plugin to do Bad
Things to our application.
This archive was generated by hypermail 2.1.4 : Mon Jun 03 2002 - 11:05:01 EDT