0xDEADBEAF

ひらたく言うと花粉の季節。

どうも最近眼がかゆくて、あぁこれは昨年発症した花粉症だなと。 今住んでるあたりは実にひどくて、これまで花粉症と縁もゆかりもなかった僕をこの憂鬱な世界に引き摺り込んだのでした。

しかしほんとに辛い。今年は発症する前に病院行かなくちゃ!と去年固く誓ったのに忘れていたなんて。

あと何科に行くのがよいのか分からない。耳鼻科かな?でも、眼がかゆいのだから眼科かしら。いやいやアレルギー関係かな? 分からない。

アレルギーについて　花粉症科はないか、アレルギー科ですべて解決できないか

花粉症はどこの科にかかればいいか・・・アレルギー性鼻炎や、花粉症は全身的な対応が必要 です

…

そんなに医学って一人が全部の科を見れるなんて甘いものじゃないんです。

ううむ。まずは総合病院かな?

• 花粉症*ナビ

近所の映画館で上映していたので観に行った。 手に汗握る美しさ。

たくさんの大事なことが詰まっていた。

• The Sound of Music
• My Favorite Thing

を何度も口ずさんでしまう。

最後の追われるシーンがすごくどきどきして、手に汗を握ってしまった。

Wikipediaで調べてみたら、なんと実話をベースにしてるのだと。

• Wikipedia:Maria von Trapp
• ja.Wikipedia : マリア・フォン・トラップ

山々の美しさと、メロディーの美しさがずっと余韻をひいている。長いんだけど、また何度も観たい。

---

開通しますよと言われ続けてはや半年が過ぎ、とうとう我が家にも光が届きました。

さっそくためしにストリーミング動画とか流してみる。驚くべきすいすい感に酔いしれる。

あとは、この高速回線をどう活かすかです。

や、は、出版社の抵抗が強いらしくなかなか全開バリバリというわけにはいかないらしい。

そこで考えてみた。

たくさんのひとが、blogである本について書くとしよう。一般的なblogでは、気になったところを引用しつつ、そこについての自分の考えを書くというのスタイルになる。

ならば、その引用部分だけを抽出してつないでいくことができれば、一冊の本が自動的に再構築できるのではないか?

方法

1. 本のタイトル(A)、著者名(B)、書き出し(C)をキーワードにして検索
2. それらしいものが見つからなければ(C)をひとつ先の文章にして1. に戻る

3. ...

   の部分を抜き出す
4. 抜き出した文章の最後の文節でキーワード(C)を置換
5. 1.に戻る

例

ためしに、読み終わったばかりのでできるかやってみた。

書き出し(C)は

情報技術(IT)が社会に及ぼす…

なので、

2. 見つからないので1. に戻る
3. しばらくやってるうちにweb kikakuがみつかる。ここには、ほぼ本文そのままがある。
4. 3.で見つかったページの一番最後の文章である いずれ振り返ることになるだろう を(C)にして1. に戻る

なんてことをやってみたけれど、やはりそう簡単にはいかない。序章すら再構築できなかった。

まとめ

とはいえ、この本はいくらベストセラーといってもごく最近出たものなので、まだあまりwebに引用が載っていないということを差し引かないといけないだろう。 多くの人が引用するような興味深い古典だと、実現可能かもしれない。

---

最近よくふつうのページや管理画面がApplication Error(rails)になってしまって、プロセスを再起動しないといけなくなる。 原因がよく分からないのが痛いところ。

Mac miniサーバだとやはり貧弱なのか。ちゃんとプロファイルとってみるかな。

やっと心あるおともだちから、お友達だよねっのメッセージをもらえた。

昔やっていたHMバンドの名前でコミュニティを検索すると、15件もヒットしてしまって憂鬱になった。

妻に招待してもらって、遅まきながらやっとmixiに参加できた。

いったいどんなとこなのかとうろちょろしてみた。Orkutを思い出す。あれの日本ローカル版なのかな。

友達をさがしてみる。一人もヒットしない。友達が少ないのか、みんな本名で登録していないのか。

そして、まだmixiのおもしろさが分からないでいる自分がいる。

自転車が進まないほどの強風の中、桜乃という珈琲屋さんに行ってきた。 店長さんが気さくな人で、一人で行ってもくつろげそうなお店。

たくさんのカップの中から好きなのを選んで、コーヒーを注いでもらえる。食器がきれいで良い。

暗黙的な型変換に注意しようという話。

暗黙的な型変換には、3とおりの方法がある。

1. 引数を一つだけ取るコンストラクタ、あるいは 引数に対してデフォルトの値を設定しているコンストラクタ
2. operator sometype() const みたいな型変換演算子

しかし、暗黙的な型変換は予期せぬ振る舞いに発展する可能性があるので、できれば避けたほうがよい。あなたの意図したものと、コンパイラが解釈した結果は異なる場合があるからだ。

型変換演算子

たとえば、ペットショップの犬を表すクラスを考える。 それぞれの犬にはIDが振られている。

class Dog {
   public:
      void bark();
      operator int() const { return id_; }
   private:
      int id_;
      char *name_;
};

いま、犬の名前を表示しようとして、うっかりDogクラスには operator char*()がないことを忘れているとすると、

Dog pochi;
std::cout << pochi << std::endl;

なんてやってしまう。結果は、pochiのIDが表示されるというもの。

経験を積んだC++プログラマは、たいてい型変換演算子を避ける。 たとえば、std::stringにはoperator char*()の代わりに c_str()が存在する。

引数を一つだけ取るコンストラクタ

こいつはよりたちがわるい。

ふつうにクラスを設計していても、こうしたコンストラクタを記述することはままある。そして、こうしたコンストラクタも、暗黙的な型変換に一役買ってしまうことがあり得る。

class Array {
   public:
      Array(int n); // n個の要素で初期化するコンストラクタ
};




Array a(10);
Array b(10);




for (int i=0; i<10; i++) {
   if (a == b[i]) {        // ここでミスしている !
      ...
   }
}

なんて風に、a[i] == b[i]と書くべきだったところを書き間違えても、コンパイラは文脈から if (a == static_cast(b[i])) といったように解釈してしまう。意図が正確に反映されていないばかりか、見つけにくいバグになってしまっている。

対策

explicitキーワードをコンストラクタにつける。このキーワードがついたコンストラクタは、暗黙的な型変換には使えなくなる。

もう一つ方法はあるけど、それはトリッキーになるので略 (ヒント: proxy class (see Item 30))。

---

所感

暗黙的な型変換は、こちらがコーディングをミスったときに、コンパイラがプログラムをコンパイルできるように、都合良く解釈してしまうため、どこで間違いを犯したか分かりづらいことが問題。

既存の大規模プログラムに手を入れたり、バグを発見するような場合を考えると、こうした言語仕様は厄介だ。

自分の意図と異なる振る舞いをプログラムが見せることほど腹立たしいものはない。コードの字面の下で何が行われているかを、正確に把握していないと正しいコードが書けないような言語は人に優しくない。これで大規模なプロジェクトをまともに作ろうという方が無理だと思う。

自分の意図を自然に表現でき、そして書いたとおりのことがストレートにコンピュータに伝わり、実行されることが重要だろうと思う。

デフォルトコンストラクタは大きなお世話な場合があるので、コンパイラに生成させないようにしようという話。

オブジェクトを生成する際に、なんらかの情報が必至であるようなクラスもある。この場合、デフォルトコンストラクタの存在が邪魔だったりする。しかし、デフォルトコンストラクタがないと面倒なことになる場合がある。

たとえば、

class Hoge {
   public:
      Hoge(int x) : x_(x) {}
   private:
      int x_;
};

なんてクラスを考える。

問題1. オブジェクトの配列をつくる場合

オブジェクトの配列を定義する際に、引数を与えることはできない。

Hoge hoges[3]; // NG
Hoge *hoges = new Hoge[3]; // NG

ではどうするか。

定義時に初期化

Hoge hoges[3] = { // OK
   Hoge(0),
   Hoge(10),
   Hoge(20)
};

しかし、この方法も完全ではない。

Hoge *hoges = new Hoge[3];

の場合を扱えないから。

ポインタの配列

(Hoge hoges)[10];  // OK
(Hoge *)hoges = new (Hoge *)[10]

この方法にも問題がある。

1. 配列の要素すべてにdeleteをかけないといけない
2. ポインタのぶんだけ余計にメモリを消費する

placement new

2つ目の問題は、placement newを導入すれば解決できる (see Item 8)。しかし、placement newを用いるにも問題がある。

1. 多くのプログラマは、このイディオムに不慣れである
2. デストラクタの呼び出し方法がトリッキーになる

問題2. template-based container class

テンプレートを用いたコンテナクラスは、デフォルトコンストラクタを要求する場合が多い。std::vectorみたいに、慎重に設計されたクラスだと問題ないけど、すべてのクラスがそうだとはいえない。

問題3. 仮想基底クラス

class Hoge {
   public:
      Hoge(int x) : x_(x);

  virtual void some_method();

};


class Fuga : public Hoge {
   public:
      Fuga();                  // NG
      Fuga(int x) : Hoge(x) {} // OK
      void some_method();
};

ある仮想基底クラスから派生したクラスのコンストラクタは、親クラスがデフォルトコンストラクタを持たないことを知っておかないといけないという問題。

策

class Hoge {
   public:
      Hoge(int x = DEFAULT_VALUE) : x_(x);
   private:
      static const int DEFAULT_VALUE;
};

のように、引数にデフォルト値をセットするという方法もある。しかし、これだとちゃんと初期化できているか分からない。なので、このようにコンストラクタを定義しておき、引数が与えられなかった場合は、例外を投げたり強制終了させたりする向きもある。

結論

以上のような問題にうんざりして、コンストラクタにデフォルトコンストラクタをつくってもらいたいと思うかもしれない。しかし、その場合は、メンバがちゃんと初期化されているかをチェックしないといけなくなる。チェックのためのコードが走る時間、コードサイズの増加といったコストを払わないといけない。

なので、初期化しなければいけないメンバをもつクラスで、コンストラクタに引数を与えないと行けないようなものの場合は、デフォルトコンストラクタを使うのは避けよう。そうすることによる弊害を受け入れるのは苦痛かもしれないけれども、ちゃんと初期化されており、無駄なチェックコードが走らないといった利点を享受できるわけだ。

---

所感

だんだん言語仕様の複雑なところに入り込んできている。

デフォルトコンストラクタを生成させないようにすると、自然なコードが書けないようになる。やっぱりそんな言語はイヤだなぁと思う。