「limits.h」とか。。。
┌────┬┬───────────┬┬───────────┐
│   型   ││        signed        ││       unsigned       │
├────┼┼─────┬─────┼┼─────┬─────┤
│int     ││INT_MIN   │INT_MAX   ││          │UINT_MAX  │
├────┼┼─────┼─────┼┼─────┼─────┤
│int32_t ││_I32_MIN  │_I32_MAX  ││          │          │
│        ││INT32_MIN │INT32_MAX ││          │UINT32_MAX│
├────┼┼─────┼─────┼┼─────┼─────┤
│int64_t ││_I64_MIN  │_I64_MAX  ││          │          │
│        ││INT64_MIN │INT64_MAX ││          │UINT64_MAX│
├────┼┼─────┼─────┼┼─────┼─────┤
│char    ││SCHAR_MIN │SCHAR_MAX ││          │UCHAR_MAX │
│        ││          │          ││CHAR_MIN  │CHAR_MAX  │
├────┼┼─────┼─────┼┼─────┼─────┤
│short   ││SHRT_MIN  │SHRT_MAX  ││          │USHRT_MAX │
├────┼┼─────┼─────┼┼─────┼─────┤
│long    ││LONG_MIN  │LONG_MAX  ││          │ULONG_MAX │
└────┴┴─────┴─────┴┴─────┴─────┘
他にもいろいろあるよね。。。

先日、delete時にそのポインタがNULLか否かを一々確認する必要はなく
無条件に実行すりゃNULLの場合は無視してくれるということに触れた。

ただ、注意しなければならないのは、deleteしたらポインタを
自動ではNULLしてくれないということ。
手動で必ずNULLしよう。
┌──────────────────────────────────────┐
│delete p;                                                                   │
│p = NULL;                                                                   │
└──────────────────────────────────────┘

deleteしても元のアドレスを指したままになっている。
もちろんその先はありませんから大変です。
┌──────────────────────────────────────┐
│delete p;                                                                   │
│delete p;                                                                   │
└──────────────────────────────────────┘
こうすると、例外になる。

┌──────────────────────────────────────┐
│delete p;                                                                   │
│p = NULL;                                                                   │
│delete p;                                                                   │
└──────────────────────────────────────┘
これならOK。

ま、直線的にこんな書き方はしないけど、いろいろ処理がつながると
結果的にこんなことになりかねない。

┌──────────────────────────────────────┐
│if (p != NULL) {                                                            │
│    delete p;                                                               │
│    p = NULL;                                                               │
│}                                                                           │
└──────────────────────────────────────┘
みたいに、念のためポインタがNULLじゃないことを確認してから
領域を解放(delete)する処理を見かけるが、
本来は「delete NULL;」でもスルーされる(処理が起こらない)というC++の規約があり
このif文は冗長なようだ。

これだけでよい。
┌──────────────────────────────────────┐
│delete p;                                                                   │
│p = NULL;                                                                   │
└──────────────────────────────────────┘

なんか、ちょっと不安だけど。。。

年月日から曜日を計算式で求める。

そんな夢のような公式があるのを最近知った。

「ツェラーの公式」

素晴らしい。

後で解析しよう。

C++でオブジェクト指向に従って設計すると、
以下の不都合(というのはあくまでC++目線で)がある。

オブジェクト指向的な考え方
(1) そのインスタンス固有の情報は生成時に確定させる
    コンストラクタから値を引き渡すなど
    ・固有情報不明(未確定)のインスタンスはおかしい
(2) あらかじめ決まった前処理はコンストラクタの時点でやってしまう
    ・前処理のやり忘れを防げる

C++の事情
(1) メモリリーク対策としてできるだけヒープ領域より
    スタック領域でインスタンスを生成した方が有利
    ・メモリ解放漏れの疑念が減る(これはメモリリーク発生時効果絶大)
    ・但し、スタック領域にインスタンスを生成する場合、
      コンストラクタの実行タイミングに不自由が生じる
      (固有情報未確定時にインスタンス生成しなけらばならない)
      よって、別途コンストラクタ同等メソッド(初期処理メソッドなど)を用意し
      それを必ず実行するルールとする(しかしながら実行漏れのリスクあり)
(2) コンストラクタ中で例外が発生した場合メモリリークする恐れがある
    また、それを隈なく対処するとなると結構労力を費やす
    ・コンストラクタでは値初期化ぐらいの軽い処理にとどめてしまうルールとする
    ・前処理にあたるものは別途メソッド(初期処理メソッドなど)を用意し
      こちらで行う(しかしながら実行漏れのリスクあり)

本来のオブジェクト指向を追求すると(美しい形で)実行漏れがなくなるが、
C++としてはメモリリークのリスクが高まるので
多少いびつでも、メモリリーク防止に努めた方がよい
＃実行漏れといっても初期処理は最初の決まった位置に置けばよいだけ
  一方メモリリーク防止の解放処理は様々なルートを考慮しなければならないから
  コスト面(チェック箇所)では格段に違う

try-catchで例外を発生せればcatchへ飛ぶわけだが、簡単な例外発生の方法としては
未定義の変数を使ってしまうというのがある。
┌──────────────────────────────────────┐
│try {                                                                       │
│    alert(reigai);  // reigaiは未定義                                       │
│} catch (e) {                                                               │
│    alert(e);                                                               │
│}                                                                           │
└──────────────────────────────────────┘

catchの中身は以下のように定義すると以下のような結果となる。
┌─────────┬────────────────────────────┐
│alert(e);         │「ReferenceError:'reigai'は定義されていません。」       │
├─────────┼────────────────────────────┤
│alert(e.message); │「'reigai'は定義されていません。」                      │
└─────────┴────────────────────────────┘

JSONでは最後に余計なカンマをつけると怒られてしまうが、
C/C++の場合は以下の通りらしい。
┌──────┬─────────┬──────────┬──────────┐
│            │                  │         ○         │         ×         │
├──────┼─────────┼──────────┼──────────┤
│配列初期化子│int  a = {1,2,3,};│C90、C99            │                    │
│            │                  │C++98、C++03、C++11 │                    │
├──────┼─────────┼──────────┼──────────┤
│列挙子      │enum a = {1,2,3,};│C99                 │C90                 │
│            │                  │C++11(C++0x)        │C++98、C++03        │
└──────┴─────────┴──────────┴──────────┘
enumの場合の最後のカンマは、C++03では正式には不正だったが、
あまり気づかなかったらしい(コンパイルで許容されてた？)

┌──────────────────────────────────────┐
│count($array);                                                              │
└──────────────────────────────────────┘
PHPだと配列$arrayの配列数を求めるのに、count()が使える。

では、C/C++では？

そんな便利な関数はありません。

ってな訳で、以下のようなマクロで代用しましょう。
┌──────────────────────────────────────┐
│#define count(array)  (sizeof(array) / sizeof(array[0]))                    │
└──────────────────────────────────────┘

IE以外なら「arguments.callee.name」で取得できる。

統一的な取得方法ってないものか。。。

「arguments.callee.toString()」ってすると、
その関数のソースの中身が取得できるみたい。