RSS

 

RSS


プ:#ifdef #if 考察その2

  • いわいまさか
  • at 2007/8/18 09:59:29

プ:#ifdef #ifは使っちゃダメ という記事を書いた。今回はその続編で改善方法などをリストアップ。

■「使っちゃダメ」と言っても
 #ifを使わないと「それはムリ」という時は、もちろんあるのでそこは臨機応変でいい。がしかし、「臨機応変でOK」というと、また野放図に使う人が現れるのでやっぱり、基本的には「使っちゃダメ」を念頭においた方が正解。

■「変数名を変えた時」
 例えばクラスの中のメンバー変数のシンボルを変更したとする。

class NoMoreIfdef
{
 ・・・・・
  int  m_peke;
  int   m_pon;
 ・・・・・
};
 通常、この後、コンパイルをすれば、m_pekeを使用している場所がコンパイルエラー(m_pekeが未定義なので)によってアラワになり、m_ponへの変更がスムーズに行く。ついでにm_pekeにまつわる、コードに関して再チェックするのが更にGOOD。

 でも #if や#ifdefの影響でコンパイルされないところは、m_pekeが使ってあっても、コンパイルエラーが出ない。

  そして別の担当者が、#if#ifdefの条件を変えてコンパイルしたときにエラーになる。別の担当者だと変更の意味合いがわからない。

 「なんで、コンパイルエラーが出るんだよ」「シンボル変えないでね」「じゃ、シンボル変えないよ~」「この変数なんか変なんだけどな~」とだんだん、淀んでくる。

 これじゃダメなので、#ifdef #ifは使わない方がよい。

■「#ifの代わりにif」
   有効になってない側のソースもコンパイルの洗礼を受けさせるために#if の代わりにifを使う手がある。
#if  IS_DOUBLE
     m_peke=func_doble();
#else
     m_peke=func_single();
#endif

  if(IS_DOUBLE){
     m_peke=func_double();
 }else{
    m_peke=func_single();
 }
 これによって、#if表記で隠されてしまう部分をコンパイルに対して明らかにできる。IS_DOUBLEによって、分岐している不利な部分をいくらかカバーできる。

 ※この方法は#ifdef には適用できない。この点に限らず、#ifの方が#ifdefよりまだマシ。

■#ifの中を掃きだす。
 以下のようなソース、#ifの中身が複数行あるのは危険度が高い。
 関数として掃きだすと改善され、その後の更なる改善につながる。
#ifdef  DOUBLE
    ne++;
    ushi_double();   // #include <ushi_double.h>が必要
    u+=tora(1);
    tatsu();
#else
    ne++;
    ushi_single();
    uma();
    u+=tora(0);
#endif
(この記事用にデッチアゲたが、こんな感じのソースが実際にも多く・・・)

#ifdef  DOUBLE
 eto_double();
#else
   eto_single();
#endif
 上記太字部分、eto_double()の別関数、別ファイルに吐き出せば、ushi_double();にのみ必要だったヘッダー ushi_double.hのインクルードの必要がなくなる。これは収穫。

 「そんなヘッダー、この環境にはないよ~」「いじるとコンパイルエラーになっちゃう」「だから、いじらない」という淀みをクリアできる。

 今回はこんなところで。
  • コメント (0)
  • トラックバック (0)
トラックバックURL :
http://www.iwai-masaka.jp/tb.cgi/839