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.
