1. プログラミングで 言いたい & 聞きたい集 TECO

2. 概要 普段感じているプログラミングに関する小さなことを集めました。 当たり前と思ってることもあるかもしれませんが、改めて考えてみよう。

3. STATIC_ASSERT(1) コンパイル時にエラーを出してくれるアサート。 積極的に利用しよう。 主な用途：配列サイズ -> 固定サイズの配列を作る時、配列のサイズが正しい値になっているかどうか、確認してますか？ -> 通常のアサートでは実行時チェックなので非効率 -> STATIC_ASSERT を使ってコンパイルではじこう。

4. STATIC_ASSERT(2) // 定義例 template < bool > struct static_assert_{ enum { okay = 1 }; }; template <> struct static_assert_< false > {}; #define JOIN(a, b) JOIN_(a, b) #define JOIN_(a, b) a ## b #define STATIC_ASSERT(expr) ¥ typedef int JOIN(diagnostics_, __LINE__) ¥ [static_assert_<!!(expr)>::okay]

5. 配列の参照渡し (1) 問 . 静的サイズの配列を関数の引数として渡す時、どれが一番適切でしょうか？ 1. void SetArray( int * array ); 2. void SetArray( int array[5] ); 3. void SetArray( int (&array)[5]);

6. 配列の参照渡し (2) 1. void SetArray( int * array ); -> 配列じゃなくても渡せてしまう。 2. void SetArray( int array[5] ); -> サイズ 5 じゃない配列でも渡せてしまう。 3. void SetArray( int (&array)[5]); -> サイズ 5 の配列しか渡せない。 正解 : ３

7. メンバ変数のポインタ化 ちゃんとメリットとデメリットを把握して、ポインタにするか実体にするかを使い分けよう。 メリット ポインタ化する型を先行宣言すればクラス間の依存度減 include 回数減＝コンパイル時間短縮 デメリット 要 NULL チェック？ キャッシュミスの原因になりかねない。

8. MASTER_CONST 修飾子 マスタービルド時には定数だが、 デバッグ時は調整のため変数にしたいものがある。 MASTER_CONST を定義しょう。 #if defined (_DEBUG) #define MASTER_CONST #else #define MASTER_CONST const #endif static MASTER_CONST float s_GameParam = 0.0f; #if defined (_DEBUG) if( Pad::IsOn( BUTTON_UP ) ){ s_GameParam += 1.0f; } #endif

9. Addr 型 ポインタ型を数値変換する場合は、 Addr 型を定義して使いましょう。 Uint32 addr = reinterpret_cast < Uint32 >(ptr); // No Addr addr = reinterpret_cast < Addr >(ptr); // Yes ポインタのサイズが 32bit である保証はありません。

10. float 型について 比較する時は誤差を考慮したマクロを定義して使おう。 // f0 == f1 #define IS_EQUAL_F32( f0 , f1) ¥ ((f1) - EPSILON) <= (f0)) && ((f0) <= (f1)+EPSILON) // f0 > f1 #define IS_MORETHAN_F32( f0 , f1 ) ((f0) > (f1)+EPSILON) // f0 < f1 #define IS_LESSTHAN_F32( f0 , f1 ) ((f0) < (f1)-EPSILON)

11. 関数の入力、出力引数 ( 示し方 ) １ . コメントで示している。 -> 関数定義を見ただけでは分からない。 ２ . 引数名で示す。 bool GetParam( int * out_Param ( or outParam ) ); -> 命名規則にポリシーを持っている人には相性が悪い恐れあり。 ３ . 修飾子を付ける bool GetParam( _OUT int * param ); 個人的には 3 を推奨したいがどうでしょう？

12. 関数の入力、出力引数 ( 範囲 ) １．入力、出力、入出力引数全てに示す。 Bool GetParam( _OUT int * dst , _IN_OUT int * param0 , _IN int param1 ); ２．出力、入出力引数のみ示す。 Bool GetParam( _OUT int * dst , _IN_OUT int * param0 , int param1 ); 入力引数はデフォルトなので、 示すのは冗長と感じるがどうだろうか？（２推奨）

13. Result型 複数の理由で処理が失敗する可能性がある関数 は返り値を Bool 型にするな。 Result 型を定義して原因を示せ。 typedef Uint32 Result; #define S_OK 0 // 成功 #define E_FAIL 1 // 失敗 #define E_INVALID_ARG 2 // 引数が不正 ・・・

14. 関数毎に author コメントを付けるべき グループプログラミングをする場合、関数毎に文責者コメントを書いている人は少ない。引き継ぎや質問に支障がでるので書く癖を！！ /*! * ホゲホゲします。 * @authror Miyake Shunsuke */ void MogeClass::DoHogeHoge() { / / ホゲホゲ }

15. 入力（ Pad,Keyboard ）クラスには Rease と Debug 用 API を用意すべし。 アプリケーション側で #if 〜 #endif で分岐してるだけでは残ってしまう可能性がある。根元でも対応すべし。 // No #if !define (_MANTER) // もしも _MASTER のスペルを間違ってたら・・・ if ( Pad::IsPress( BUTTON_A ) ){ m_Hp = 100000; // Hp を回復 ( デバッグ用 ) } #endif // Yes if ( DebugPad::IsPress( BUTTON_A ) ){ m_Hp = 10000; // Hp を回復 ( デバッグ用 ) }

16. 以上！！ Q ＆ A 何かあれば [email_address] まで