「単一列」副問い合わせは、対象とする表が複数列の表であっても
射影(SELECTの列数)によって、単一列になることが保証されれば成立する。
  ○SELECT 列 FROM 表
  ○SELECT * FROM 単一列表
  ×SELECT * FROM 複数列表
実際にデータがあろうがなかろうが理論上で単一列であることが決定できる。

副問い合わせはその結果により、以下の五種類に分類できる。
┌──────┬──────┬──────┐
│            │単一行単一列│単一行複数列│
│  該当なし  ├──────┼──────┤
│            │複数行単一列│複数行複数列│
└──────┴──────┴──────┘

副問い合わせが成立するのは以下の場合(○＝成立、×＝エラー)
【結果列に副問い合わせを出力する場合】
    ○SELECT (該当なし);  ※
    ○SELECT (単一行単一列);
    ×SELECT (複数行);
    ×SELECT (複数列);
  ※該当なしの場合は、NULL扱いとなる
    ちなみに型は該当ありだった場合の列の型となる
【条件式に副問い合わせを出力する場合】
    ○SELECT 列 FROM 表 WHERE 列 = (該当なし);  ※
    ○SELECT 列 FROM 表 WHERE 列 = (単一行単一列);
    ×SELECT 列 FROM 表 WHERE 列 = (複数行);
    ×SELECT 列 FROM 表 WHERE 列 = (複数列);
    ○SELECT 列 FROM 表 WHERE 列 IN (該当なし);  ※
    ○SELECT 列 FROM 表 WHERE 列 IN (単一列);
    ×SELECT 列 FROM 表 WHERE 列 IN (複数列);
  ※該当なしの場合はNULL扱いなので、条件式にNULLが混在することになり
    その結果、判定結果は「偽」になる

NULLは「''」や「0」と混同してしまいがちだが、
以下の性質があるので押さえておくと何かと役立つ。
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
┌──────────────────────────────────────┐
│NULLが加減乗除の一要素となった場合、計算結果がNULLになる                    │
└──────────────────────────────────────┘
  なお、「1/NULL」のように除算しても除数ゼロエラーではなく計算結果がNULLとなる。
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
┌──────────────────────────────────────┐
│NULLに文字列結合した場合、結合結果がNULLになる                              │
└──────────────────────────────────────┘
  「NULL || 'a'」の結果は「'a'」ではなく「NULL」。
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
┌──────────────────────────────────────┐
│NULLの型は不明型(unknown)だが、キャストもできる                             │
└──────────────────────────────────────┘
  「NULL::integer」のようにキャストするとその型(integer型)のNULLとなる。
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
┌──────────────────────────────────────┐
│NULLを判定するとたいてい偽になる                                            │
└──────────────────────────────────────┘
  ・CASE WHEN NULL = 0 THEN '真' ELSE '偽' END  →  偽
  ・CASE WHEN NULL > 0 THEN '真' ELSE '偽' END  →  偽
  ・CASE WHEN NULL < 0 THEN '真' ELSE '偽' END  →  偽
  加減乗除の結果もNULLとなるという法則を組み合わせると以下も導き出せる。
  ・CASE WHEN (NULL + 1) > 0 THEN '真' ELSE '偽' END  →  偽
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
┌──────────────────────────────────────┐
│NULLを判定するためには「IS NULL」を使わなければならない                     │
└──────────────────────────────────────┘
  「NULL IS NULL」は真だが、「NULL = NULL」は偽。
  ちなみに「NULL IS NOT NULL」は偽だが、「NULL <> NULL」も偽。
  さらには、「IN (NULL)」も「NOT IN (NULL)」も偽。
  NULLに対しては「IS NULL」や「IS NOT NULL」を使わないと一律に偽になる。

数値2桁(00)の場合は、以下のような感じ。
┌──────────────────────────────────────┐
│{$値|string_format:'%02d'}                                                  │
└──────────────────────────────────────┘
ま、printf()と要領は一緒やね。

サニタイズしたい時など、他の修飾子がある場合は、並べて書くだけ。
┌──────────────────────────────────────┐
│{$値|string_format:'%02d'|escape}                                           │
└──────────────────────────────────────┘

「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'は定義されていません。」                      │
└─────────┴────────────────────────────┘