Embed Size (px)
Citation preview
プログラミングで言いたい & 聞きたい集
TECO
概要
普段感じているプログラミングに関する小さなことを集めました。
当たり前と思ってることもあるかもしれませんが、改めて考えてみよう。
STATIC_ASSERT(1)
コンパイル時にエラーを出してくれるアサート。積極的に利用しよう。
主な用途：配列サイズ → 固定サイズの配列を作る時、配列のサイズが正しい値に
なっているかどうか、確認してますか？ → 通常のアサートでは実行時チェックなので非効率 → STATIC_ASSERT を使ってコンパイルではじこう。
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]
配列の参照渡し (1)
問 . 静的サイズの配列を関数の引数として渡す時、どれが一番適切でしょうか？
1.void SetArray( int* array );2.void SetArray( int array[5] );3.void SetArray( int (&array)[5]);
配列の参照渡し (2)
1.void SetArray( int* array ); → 配列じゃなくても渡せてしまう。
2.void SetArray( int array[5] ); → サイズ 5 じゃない配列でも渡せてしまう。
3.void SetArray( int (&array)[5]); → サイズ 5 の配列しか渡せない。
正解 : ３
メンバ変数のポインタ化
ちゃんとメリットとデメリットを把握して、ポインタにするか実体にするかを使い分けよう。
メリット ポインタ化する型を先行宣言すればクラス間の依存度減 include 回数減＝コンパイル時間短縮
デメリット 要 NULL チェック？ キャッシュミスの原因になりかねない。
MASTER_CONST 修飾子マスタービルド時には定数だが、デバッグ時は調整のため変数にしたいものがある。MASTER_CONST を定義しょう。
#if defined(_DEBUG) #define MASTER_CONST#else #define MASTER_CONST const#endifstatic MASTER_CONST float s_GameParam = 0.0f;#if defined(_DEBUG) if( Pad::IsOn( BUTTON_UP ) ){ s_GameParam += 1.0f; }#endif
Addr 型
ポインタ型を数値変換する場合は、 Addr 型を定義して使いましょう。
Uint32 addr = reinterpret_cast<Uint32>(ptr); // No
Addr addr = reinterpret_cast<Addr>(ptr); // Yes
ポインタのサイズが 32bit である保証はありません。
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)
関数の入力、出力引数 ( 示し方 )
１ . コメントで示している。 → 関数定義を見ただけでは分からない。
２ . 引数名で示す。 bool GetParam( int* out_Param( or outParam ) ); → 命名規則にポリシーを持っている人には相性が悪い恐れあり。
３ . 修飾子を付ける bool GetParam( _OUT int* param );
個人的には 3 を推奨したいがどうでしょう？
関数の入力、出力引数 ( 範囲 )
１．入力、出力、入出力引数全てに示す。 Bool GetParam( _OUT int* dst , _IN_OUT int* param0 ,
_IN int param1 ); ２．出力、入出力引数のみ示す。 Bool GetParam( _OUT int* dst , _IN_OUT int* param0 ,
int param1 );
入力引数はデフォルトなので、示すのは冗長と感じるがどうだろうか？（２推奨）
Result型複数の理由で処理が失敗する可能性がある関数は返り値を Bool 型にするな。Result 型を定義して原因を示せ。
typedef Uint32 Result; #define S_OK 0 // 成功#define E_FAIL 1 // 失敗#define E_INVALID_ARG 2 // 引数が不正・・・
関数毎に author コメントを付けるべき
グループプログラミングをする場合、関数毎に文責者コメントを書いている人は少ない。引き継ぎや質問に支障がでるので書く癖を！！
/*! * ホゲホゲします。 * @authror Miyake Shunsuke */void MogeClass::DoHogeHoge(){ // ホゲホゲ}
入力（ 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 を回復 ( デバッグ用 ) }
