ROAST_SAFE_DELETE - Open MGL Wiki - Open MGL

＞FrontPage＞Roast+＞リファレンス＞std＞safe.hpp＞ROAST_SAFE_DELETE

ROAST_SAFE_DELETE

このテクニック（及びそれを実現するためのマクロ）は、これまでにも多くのプログラマが使い古してきた技術です。

変数の動的確保（C++であればnew、Cであればmalloc、calloc、realloc）の場合において、
──単純に、宣言と同時に確保を行うような変数であれば特に問題はないのですが───
処理の途中で確保や解放を行う場合、条件ルートによって解放すべきか否かが変わってくる場合、
少し面倒な話となります。

この場合、無条件に解放処理を行う・・・と言う事は出来なくなります。

変数の動的確保（C++であればnew、Cであればmalloc、calloc、realloc）を行う場合において、
───変数宣言時に同時に変数の動的確保を行ったり、また、宣言の後すぐに等、
必ずどの条件分岐経路を通ったとしても確保されている事が保障されているのであれば問題ないのですが───
もし、条件分岐経路によっては確保されていたり、されていなかったりする場合、ちょっと面倒な話になります。

それは、その動的確保を解放しようとした時です。
動的確保がされていないポインタを解放する事は出来ません（多くの処理系では、プログラムが異常終了します）。
このため、単にプログラムの最後で無条件に解放する訳には行きません。

多くのプログラマが、この問題に対する回避策としてまず一番最初に考えるのは、それぞれの条件分岐内で解放処理を、
行ったり、行わなかったりするようにする方法です。もし仮に、プログラムがよっぽど単純なものか、
もし貴方がよっぽど頭の良い人間であれば、この方法で良いかも知れません。しかし、多くの場合そうではありません。

また、もし仮にその時点で、ごく簡単な条件分岐であったとしても、
その後の改版により複雑な条件分岐となるかも知れません。そうでなくとも、
それまで確保処理を行っていた場所が、確保処理をやめてしまうかも知れません。
その逆もあり得ます。

仮にそうであったとしても、未来永劫そのプログラムの単純のままとは限りません。
そのプログラムに対し、今後貴方以外の人間が修正を加える可能性もあります。

多くのプログラムは、一度作ったらそれっきり・・・ではありません。
大抵の場合、そのプログラムが死ぬまでの間、改版、メンテナンスが繰り返されて行きます。

また、既に解放がされている

C++宣言

(C++) roast/std/safe.hpp ：

 #define ROAST_SAFE_DELETE(p)            { if ( p != NULL ) { delete p; p=NULL; }}
 #define ROAST_SAFE_DELETE_ARY(p)        { if ( p != NULL ) { delete []p; p=NULL; }}
 #define ROAST_SAFE_DELETE_ARRAY(p)      { if ( p != NULL ) { delete []p; p=NULL; }}

(C++) roast/std/safe.hpp ：
(C) roast_bufsafe.h ：

 #define ROAST_SAFE_FREE(p)              { if ( p != NULL ) { free(p); p=NULL; }}