技術と利便性は相関せず

今度のC++WGのアドホック会議で、全く関係ないが、ふと思ったことがある。技術と利便性とは相関しない。つまり、どんなに優れた技術が開発されても、我々人間の生活の質は、あまり向上しないのではないかということである。

実は私は、技術の恩恵を、あまり直接的に受けていない人間である。私はスマートフォンを持っていない。私は電子書籍を活用してない。私は最近の映画や音楽やゲームを知らない。

29日のアドホック会議のことである。ちょうど昼頃になったので、我々は食事をすべく、外に出た。7人の我々は、全員そろって座れる席のある飯屋を探していた。多くの者は、iPhone等のスマートフォンを持っていた。これらのスマートフォンは、GPSにより、現在位置を把握し、周辺の地図を表示し、さらに、進んでいる方向にあわせて、地図を回転してくれるような機能まで備えているのである。これさえあれば、我々が道に迷う可能性はゼロであり、また、飯屋もすぐに見つけられるはずである。

しかし、現実は、そううまくいかない。我々の飯屋探しは難航した。地図に、何人がけの席があるなどというメタ情報がないことも、あるのかもしれぬ。ただ、私が思うに、一番の問題は、選択肢が多すぎたことであろう。

我々の眼前には、飯屋が軒を連ねていた。通りの左右がほとんど、飯屋だったのである。これがたとえば、ぽつんと一件しか飯屋がないとなれば、そこに入るしかないとなるであろう。ところが、飯屋の数はとても多く、しかも、一軒一軒の飯屋は小さいので、全員入れる保証がない。

しかし、どう考えても、これはおかしい。我々はとても便利なスマートフォンを所有している。これさえあれば、地球の裏側の飯屋の情報だろうと、その場で探せるはずである。それが、なぜ眼前に飯屋が軒を連ねていながら、適切な店を決定できないのか。一体、我々の科学技術は、何のためにあるのか。

似たようなことは、夕食時にも起こった。会議が終わり、同志の者が集まって食事をしようと計画していた。すでに、どの店に行くかは決まっている。問題は、会議に参加していない人も、その食事には参加する予定であり、どこかわかりやすい場所で、待ち合わせる必要があった。

しかし、我々同志の者は、20人以上いる。20人で待ちぼうけるのは無駄である。誰かひとりだけ残って、残りの同志達は、店に向かうのが得策だろう。しかし、店の場所は、アキラさんしか知らない。さてどうするか。

アキラさんは、おもむろに近藤さんに近づき、手に持ったiPhoneを見せた。曰く、「近藤さん、店の場所はここです。近藤さんもiPhoneを持っているでしょ。ここに向かってください」
近藤さん、対えて曰く、「えーと、どうやって同じものを表示すれば・・・・・・」
アキラさん「ほら、ここに住所（の文字列）が表示されているので、これを手打ちで」
近藤さん、「ええ、手打ちですか？」

そう、店の場所は地図で表示されているが、それをコピーする容易な手段がないのである。コピペは使えない。なぜなら、物理的に別のデバイスだからである。今、私は東プレのRealForceというすばらしいキーボードで、この文章を入力しているが、iPhoneのようなスマートフォンに、東プレのキーボードを使ったように素早い文字入力は期待できない。それならば、メールで送るか。いや、手打ちより時間がかかる。

同志A「なんか赤外線通信とかできないんですかね」
同志B「ガチャンとぶつければやり取りできるとか、そんなのないんですかね」

残念ながら、この二十一世紀初頭においても、いまだにそんな技術が開発されていない。技術的には、可能である。ただし、共通の規格がない。

共通規格は重要である。映画「スターウォーズ」では、R2-D2というアストロメク・ドロイドは、劇中で出てきたどんなコンピューターにでも、たったひとつの接続端子を用いてアクセスしている。C-3POというプロトコル・ドロイドは、首を切断されて、頭部をバトル・ドロイドに溶接されたが、問題なく動いていた。バトル・ドロイドの体は遠隔操作されていたが、C-3POの頭部も問題なく動いているので、電力供給その他のバスの配置に互換性があったのであろう。恐るべき互換性である。我々の住む惑星地球では、iPhone同士ですら、汎用的な通信に困っているのである。片や、昔々、遥か彼方の銀河系では、惑星タトゥイーンで、スクラップの中から、まだ子供であるアナキンの手によって作られたコンピューターが、その惑星内どころか、全銀河のコンピューターと互換性のある接続端子を備え、また、そもそも接続用の端子ですらない、単なるライン上の溶接ですら、問題なく動いてしまうとは。

iPadである。今、世の中を騒がせているデバイスである。そのiPadを、早くも所有している人間が、当日は何人もいた。私には、その良さがまったくわからないし、第一、Appleの製品を使うことは、私の宗教の信条に反する。ただし、Apple信者としては、布教活動をしたいらしく、色々とすばらしいiPadの機能を見せつけてきた。おそらく、キリスト教その他の宗教にも見られるように、他人に布教活動をすることが、自分の徳分を上げる善行だと信じられているのであろう。

まず、電子書籍である。ある人のiPadには、森鴎外や芥川龍之介や太宰治の電子書籍が収められていた。そのUIは、既存の紙で作られた本をめくるような感じで、直感的に操作しやすいものであった。

しかし、せっかく紙を脱したのに、なんでまた、紙と同じ操作性にしなければならないのだろう。よく分からない。ましてや、電子書籍には、ページの概念など要らないはずである。さらに問題なのは、DRMだ。これが問題だ。今、私が電子書籍を買ったとする。私は、コンテンツを読む権利を買ったわけである。コンテンツを読むのに、再生装置が何であろうが、問題ないはずである。私はApple公式の本をめくるタッチをしなければならない使いづらいビューワーをやめて、もっとまともな使いやすいデバイスの上で、使いやすいビューワーを使って本を読みたい。ところが、DRMのせいで、それができない。

今、ソニー製のCDが、ソニー製のCDプレイヤーでなければ再生できないとなれば、消費者はソニーの製品をボイコットするだろう。CCCDの件では、ソニーその他のレコード企業は大いに批判された。CCCDは、規格上、CDですらないのだ。ところが、ことAppleの場合に限っては、諸手を上げて賞賛されているのである。不思議なことだ。

我々が紙の本を使っていた時代、DRMなどというものはなかった。それどころか、無料で本を閲覧、貸出させる、図書館なるものが、大いに流行った。有料で閲覧、貸出をする、貸本屋という職業も、大いに流行った。さて、本の売上は、図書館や貸本屋のために落ちたであろうか。疑問である。

まあ、DRMの問題は、iPadというデバイス自体には、関係ないのかもしれない。iPadというデバイスで、何が出来るのか。ゲームは、いつの時代も、大いに注目されるコンテンツである。ゲームはどうか。iPadのゲームは、私の感想では、皆手を画面上に、意味もなくこすりつけているようにしか見えなかった。いや、アクション以外にも、ゲームはある。例えば、RTSのような頭脳を使うゲームはどうか。アキラさんの作ったRTSゲームは、やたらとたくさんのタッチを要求するゲームであった。取引所直結の株取引じゃあるまいし、そんなに素早い操作が必要なのだろうか。やたらと多い操作を要求されるRTSゲームというのは、何が面白いのだろうか。

私には、iPadのゲームとは、いかに複雑なタッチをいかに素早くできるかどうかを得点とするように思えた。

これによってこれをみれば、ハイパーオリンピックは、先見のあるゲームであったと言わざるを得ない。結局、ゲームはハイパーオリンピックに帰結するのであろうか。

技術の進歩は、もちろん喜ばしいことであるが、どうも、我々の利便性は、あまり向上していないように思われる。

移動日記

29日に行われる、C++WGのアドホック会議のため、東京へ向かった。移動手段は、夜行バスだ。さしあたって、特筆すべきことは起こらなかった。ただし、界王拳のように、体に負担がかかったことだけは、記しておく。

さて、夜行バスは早朝に、休憩のため、海老名SAに止まった。みると、まだ五時頃なのにもかかわらず、露店がひとつ開いていた。「ポークもち」と称する、ウインナーにもちを巻いた、不思議な食物を売っていたので、ひとつ買って食べた。かなりボリュームがあった。

さて、六時半頃、東京駅の八重洲口に、到着した。今回のアドホック会議は、赤坂ツインタワーで行われる。Google MapのDirection機能によると、東京駅から、国会議事堂前駅に行って、そこから1km弱ほど、歩けばいいらしい。

さっそく、八重洲口から、東京駅の構内に入って、切符を買おうと、JR線の値段の図を見るが、どこにも、国会議事堂前駅は見当たらない。不思議に思って、Google Mapを見返すと、東京メトロ、丸ノ内線とある。メトロというからには、地下鉄であろう。幸い、丸ノ内線とかかれた矢印の標識を発見した。あの矢印の指し示す方向へ行けばいいのだろう。

そこで、私は駅構内を歩いた。しかし、いつまでたっても、地下鉄の改札口がみえてくる気配はない。丸ノ内線の案内標識だけは、絶えずある。本当にこのまま歩いていて見つかるのだろうかと、不安になった。

相当歩いた末、私はようやく、丸ノ内線の、切符販売機を発見した。不思議だ。私はずっと標識に従って歩いてきたので、私は最短ルートを通ってきたはずだ。それなのに、この距離はどういう事だ。一駅分は、優に歩いたはずである。

だいたいGoogle Mapによれば、東京駅から赤坂ツインタワーまで、直線距離で3kmである。無論、これは、皇居の堀を泳ぐという畏れ多いルートであるので、現実的ではない。By walk機能を使って調べたところ、3.5kmであった。やはり、十分に歩いていける距離である。たかだか3キロの距離の為に、同じ駅構内で、なぜこんなに歩かねばならぬのか。東京は不思議な都市である。

ともかく、丸ノ内線で、国会議事堂前駅に行った。駅を出ると、木の棒を携えた物々しい警官が多数、警備をしている。地図によると、赤坂ツインタワーへは、六本木通りに沿って歩いていけばいいはずである。果たしてその通りであった。

さて、赤坂ツインタワーは見つかったものの、まだ時間が早い。七時半である。どこかで腹ごしらえをしたいが、あまりに離れるのは、道に迷う可能性があり、危険だ。近くにあったなか卯で、最近出たという、和風牛丼を注文した。別に、どうということのない普通の牛丼であった。牛丼とセットで付いてきた、自称蕎麦は、まるで糸こんにゃくのような味がした。二八蕎麦ならぬ、八二蕎麦ではなかろうか。

さて、アドホック会議で、集まったNBコメントを議論した。参加者の数人は、最近出たiPadを見せびらかしていた。私には、どうもその良さが分からなかった。

途中、昼食のための休憩を挟んだが、「ポークもち」と牛丼を食べていた私は、全く腹が空いてなかった。

会議の途中、ある問題のために、C++WGのMLに、メールを投げてみてはどうかという事になった。幸い、ほとんどの者はラップトップを持ってきているし、ネット環境も整っている。これは、たやすく行われるように思われた。

ところが、問題があった。誰も、ラップトップにメール送受信の環境を構築していないのであった。考えて見れば、今の時代、ラップトップは、そういう位置づけなのかもしれない。第一、ラップトップと言ったところで、今日のラップトップは、片膝に乗るようなサイズばかりである。

ところで、私は自分のメールに、GMailを使っている。ということは、ネット接続とブラウザの環境があれば、どこでも自分のメール環境を構築できるのである。このため、MLには、私がメールを出すことになった。やれやれ、私のネット生活は、Googleに依存しすぎている。

なぜGMailか。以前は、契約しているISPのメールアカウントを使っていたが、もうやめてしまった。自分の家庭で契約するISPにメールサービスを依存すると、何が不便か。解約せざるを得なくなったときの、移行が困るのである。

たとえば、私はいまマンションに住んでいる。このマンションには、光ファイバーが来ており、各部屋までは、VDSLで接続されている。ISPは、eonet限定である。このように、引っ越した際に、同じISPとの契約を、物理的な理由で続行できない場合がある。それ故、私はISPのメールに依存することをやめた。ではなぜGMailか。やはり、無料であるし、Web上のUIが、他のWebメールサービスに比べて、優れていたからである。

会議の最後に、BoostConの体験談を聞いた。なかなか面白そうだ。

会議後、食事に行くことになった。とりとめのない話をしているうちに、夜行バスの時間が迫ってきたので、私は早めに離脱した。

さて、移動である。食事のために、かなりの移動をした。ここがどこか、分からない。現在、21:20。私は何とかして、あと40分以内に、東京駅にたどり着かねばならぬ。

まず、駅はすぐに見つかった。東京メトロ千代田線、赤坂駅である。しかし、千代田線は、東京駅には行かない。複雑怪奇な路線図を見たところ、国会議事堂前駅で、丸ノ内線の乗り換えるのではないかと推測した。幸い、当たっていた。

国会議事堂駅のホームの降りたところ、丸ノ内線はあちらという標識があった。これは親切だと、その方向へ向かったが、あまりの距離にうんざりした。ここは駅の構内であるはずだ。なぜ駅の中でこんなに歩かねばならぬのか。まったくもって東京は理解出来ない。

さて、なんとか東京駅にたどり着いた。やれやれ、あとはバスの中で寝ているだけで、勝手に移動してくれるはず・・・・・・ではなかった。夜行バスに乗るためには、東京駅の八重洲口をでてすぐの集合場所に向かわなければならない。今、私は丸ノ内線で東京駅に到着した。はて、私は今朝、とても長い迷路のような複雑な立体構造の中を歩いたはずであった。なぜ歩かねばならなかったのか。東京駅八重洲口から、丸ノ内線に乗るためである。とすると・・・・・・

私は、丸ノ内線の改札口から、八重洲口へと歩いた。これはどう考えてもおかしい。東京駅から赤坂駅までは、約3kmだ。もちろん、たったの3kmとはいえ、電車を使うのは、理にかなっている。3kmとはいえ、歩くと三十分以上かかるだろう。それが、五分や十分で済むのなら、電車を使う利点はある。

しかるに、電車の待ち時間などもあったが、私は移動に40分かかった。そのほとんどは、駅構内での、徒歩の移動に浪費されている。東京の電車は、一体どうなっているのであろうか。

ともかく、あとは、夜行バスに乗って、京都に帰った。

よくわからないintegral promotion

intよりrankの低い整数型の値は、すべての値が表現できるのであれば、intに型変換できる。

あれ、long intとlong long intはどうなるのだろう。これらは、通常の整数型の値の型変換には定義されていない。

とすると、intからlongへの型変換は、integral promotionではなく、integral conversionになるのか？　また、charからshortへの変換も、integral conversionなのか？

どうやら、そうなるようだ。これは、overload resolutionの順位にも影響するので、以下のようになる。

void f(short) ;
void f(int) ;
void f(long) ;
void f(long long) ;

int main()
{
    char x = 0 ;
    f(x) ; // call f(int)
}

なるほどなるほど、一瞬不思議に思ったが、当然だ。intを基本としているのだろう。

cstdint.hのMIN/MAXマクロ

どうも、皆たったのC99規格の２パラグラフが読めないようなので、翻訳する。

7.18.2 Limits of specified-width integer typesより、パラグラフ1

The following object-like macros specify the minimum and maximum limits of the types declared in <stdint.h>.

以下のオブジェクトに似せたマクロは、<stdint.h>で定義されている型の、最小と最大の制限を指定するものである。（略）

これだけ読むと、実際の最小値と最大値のように読める。次に、パラグラフ2だ。

Each instance of any defined macro shall be replaced by a constant expression suitable for use in #if preprocessing directives, and this expression shall have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions.

すべてのマクロは、#ifプリプロセッサディレクティブで使える定数式に置換されなければならず、その式は、integer promotionによって、対応する型と同じ型に型変換できなければならない。

これにより、キャストはできない。integer promotionによって型変換された結果、その型と同じになればいいので、正直なところ、渡された値を、そのまま使うしかない。これは、(2) - 危ないRiSKのブログへの反証にもなる。ただし、整数リテラルのサフィックスを付け加えて、符号を整えるぐらいはするべきだろう。そういう意味で、MSVCの実装は、すこし劣っている。とはいえ、Cのinteger promotionで同じ型に型変換できればいいのである。Cの型システムに頼っているのであるから、サフィックスを使わなくても、規格準拠であろう。ましてや、integer promotionだ。続き。

Its implementation-defined value shall be equal to or greater in magnitude (absolute value) than the corresponding value given below, with the same sign, except where stated to be exactly the given value.

その実装定義の値は、以下に定義された値に対して、等しいか、より大きくなければならない。符号は同じである。ただし、厳密に規定された値と記されている場合を除く。

厳密に指定されているのは、INTN_MIN、INTN_MAX、UINTN_MAXだけである。つまり、この三つのマクロは、規格の定義する値と、同じでなければならない。たとえ、uint8_tが、内部的に16bitであり、その最大値は、2¹⁶ − 1だったとしても、UINT8_MAXの値は、2⁸ − 1になる。

さて、それ以外の場合。

「等しいか、より大きくなければならない」なので、等しい場合も、規格準拠の実装である。たとえば、UINT_LEAST8_MAXが、実際は16ビットの整数であり、その実際の最大値は、2¹⁶ − 1だったとする。しかし、2⁸ − 1に等しいか、それより大きければ（ただし、単位は桁である。2の累乗のことだ）、規格上は問題ない。

これらのマクロは、最低限保証されている最小値と最大値を取得するものである。実装における本当の最小値と最大値を取得するものではない。それでは役に立たぬではないかという意見もあるだろう。しかし、規格準拠の実装は、役に立つかどうかで判断されるものではない。規格に照らし合わせて、準拠しているかどうかで判断しなければならない。もし、それが役に立たぬとすれば、それは規格の問題である。

個人的に言えば、これはプリプロセッサを使うから、こうなってしまうのである。プリプロセッサは根本的に邪悪で低機能であり、こうなるのも仕方がない。クラスとテンプレートさえあれば、C++の、std::numeric_limitsのようなテクニックで実装できる。これはもちろん、#ifでは使えない。しかし、C++ならば、最小値最大値に関わる実装分岐程度の問題は、プリプロセッサではなく、テンプレートメタプログラミングで解決できる。

基本的に、これらの技術文章は、日本語に翻訳すると、非常に分かりにくくなる。原文が英語である以上、当然英語で理解すべきである。

HDDに対して叫ぶなかれ

本当に声なんだろうか。むしろ、手を付いた時の振動ではあるまいか。ともかく、HDDには、どんなに微細であろうとも、振動を加えない方がいいというお話。

ペペロンチーノは聖なる食物

私は、空飛ぶスパゲティモンスター教を信じている。ところで、ここ一ヶ月以上、FSM教の聖なる食物である、スパゲティを食べていないことに気がついた。これはまずい。海賊のコスプレは、日常生活に支障があるので、仕方なく諦めているが、神聖なる食物は、欠かすことができない。

というわけで、100円ショップでスパゲティを買ってきた。何をかけて食べるかが問題だが、ペペロンチーノを選んだ。そういえば、いままでペペロンチーノでスパゲティを食べたことがない。そもそも、ペペロンチーノとは、どういう意味だろう。

アーリオ・オリオ・ペペロンチーノ - Wikipedia

どうやら、正式な名称は、アーリオ・オーリオ・エ・ペペロンチーノ (aglio olio e peperoncino)であり、ニンニクとオリーブオイルと唐辛子を意味するそうだ。しかし、これはスパゲティの本国イタリアでは、外食のメニューには存在しないそうだ。というのも、ペペロンチーノには具がなく、極貧の食べ物だからだそうだ。日本でたとえるならば、飯屋に行って、ご飯に醤油をかけたものが出されるのと、同じ感じなのだろうか。

しかし、貧乏人の食べ物だということは、まさしくFSM教の理想とする食物ではあるまいか。

ここで、FSM教になじみの人に、なぜスパゲティが神聖なる食物であるかの説明をしたいと思う。これは、預言者ボビー・ヘンダーソンの大著に述べられていることである。これは真実である。

一体、FSM教を信仰し、その真実である証拠を提出しているのは誰か。科学者である。では、科学者は、どこにいるのか。多くの科学者は、大学から輩出せられている。とすると、学生は、祝福された存在であるはずだ。

学生である。学生は我々の未来にとって、重要な存在である。これは、卒業スピーチで学長がよく言っているという証拠がある。学生は、親の金を浪費して、ただ本を読むということをしている。つまり、勉強は重要だということが分かる。

学生を注意深く観察すると、彼らは、ただに本を読むばかりではない。多くの学生は、本を読む以上に、ビールを飲むことに時間を費やしている。そこで、ビールは、勉学において重要であるということが分かる。

学生は何を食べているか。多くは、ラーメンやドライパスタを食べている。これらの食物は、とても安い。そこで、学生は、食費を節約できる。余った金はどうするのか。より多くのビールを飲むために費やされるのである。

もしかすると、空飛ぶスパゲティモンスター様は、我々が気づかぬうちに、学生を済度して、より正しい方向に導いでいるのではあるまいか。彼らが安いスパゲティを食べているのは、FSM様の導きによるものではあるまいか。そういうわけで、安いペペロンチーノは、祝福された食物といえる。

我々はかつて、この問題の検証を試みたことがあった。FSM教は、他の宗教、例えばキリスト教より、人々を済度している。この定説を確かめるために、我々は、次のような実験を行った。

我々は、被験者として、身長、体重、知能指数が平均的な、二人の被験者を選んだ。まず、外部の影響を避けるため、我々は被験者を72時間、監禁した。その後、キリスト教徒には、紙のように薄いウェハースを一枚与え、FSM教徒には、大量のスパゲティとミートボールを与えた。

テストの結果、キリスト教徒は、知能指数、心拍数、及び体温の低下が見られたが、FSM教徒には、明らかな上昇が観察された。また、FSM教徒の被験者自身の言葉によると、「Full」ということであった。これもまた、FSM様の影響を如実に表していると言える。ラーメン。

しかし思うに、日本ではビールの値段がやけに高い。これは、ビールに対する税率が高いからである。思うに、日本国政府は、FSM教を敵視しており、ビールの値段を上げることで、我々信者を迫害しようとしているのであろう。

ちなみに現在、日本における「たらこスパゲティ」が、祝福された食物であるかどうかの調査が行われているそうである。

「VC++10 のcstdintはバグっている」にたいするツッコミ

VC++10 の＜stdint.h＞, ＜cstdint＞はバグっている (2) - 危ないRiSKのブログ

C99規格より、

INT_FASTN_MIN    −(2N−1 − 1)
INT_FASTN_MAX    2N−1 − 1

とすれば、INT_FAST16_MINは、int_fast16_tの実際のビット数にかかわらず、-(2^16-1 -1)に置き換わるべきであるし、INT_FAST16_MAXは、2^16-1 -1に置き換わるべきである。

int_fast16_tの具体的な型がなんであるかは、規定されていない。int_fast16_tがintのtypedefであったとしても、全く問題はない。現時点で、MSVC10の実装では、intになっている。

VC++10 の＜stdint.h＞, ＜cstdint＞はバグっている (4) - 危ないRiSKのブログ

何も指定せず、普通に関数のオーバーロードをしているので、もちろんこれはC++のコードである。

ところで、先程も述べたのと同じ理由で、int_least8_tがintであったとしても、何の問題もない。重要なのは、intが8ビット以上あるかどうかだ。intが32bitの環境では、以下の実装は、well-formedである。

namespace std {
typedef int int_least8_t ;
typedef int int_least16_t ;
typedef int int_least32_t ;
}

つまり、std::is_same<int_least8_t, int_least16_t>::valueがfalseである保証はない。

以上の理由で、int_leastN_tで関数をオーバーロードするのは、規格上、おそらくは、undefined behaviorもしくは、unspecified behaviorになると思われる。上記のような実装の場合、オーバーロードすると、結局、どの型もintに過ぎないので、コンパイルエラーとなる。これは、規格が上記のような実装を認めている以上、コンパイラの責任ではない。

ただし、VCの実装では、int_least8_tはsigned charで、int_least32_tは、intなので、INTN_Cの挙動はおかしいと言える。しかし、そもそもcstdintで定義されているtypedefが、違う型である保証はない。とすれば、どうなったところで、文句はいえまい。

そもそもが鼻から悪魔を召喚するコードなのだから、どうなったところで、実装の責任ではないだろう。

なお、UINTN_Cが一部、signed型になるのは、これは仕方が無いのではあるまいか。もし、キャストすると、#ifで使えなくなる。そして、C99規格は、#ifで使えることを要求している。とすれば、何が出来るというのか。実装の問題ではなく、規格の問題である。

ちなみに、これは明らかに、規格の問題なのだが、どうせ劣ったC言語では、特に問題にならない。なぜなら、C99には、関数のオーバーロードはないし、autoもdecltypeもない。実際に違った型であったとして、Cからどうやって利用するというのか。Cの型システムはC++よりはるかに劣っているので、C++のような厳格な型システムを期待するのは無理である。

第一、プリプロセッサを用いている時点で、C規格が根本的に救いようのない劣った言語であることは間違いがない。C言語の規格がクソなのに、実装に文句を言っても仕方がない。

CのBlocksがクソすぎて吹いたｗ

CのBlocksがクソすぎる。詳細を書くのもバカバカしい。結局、リファレンスもクラスもテンプレートもないCには、lambdaは無理なのだ。

柳田國男の描いた上古

柳田國男は、妄想が激しく、その文章の多くは、論文の体をなしていない。妄想に基づき、文体の修飾を盛んにして、むしろ小説に属するものである。彼がなぜ小説家の道を諦めたかは、歴史上の偉大なるミステリーである。

定本柳田國男全集において、「木綿以前の事」と題された一連の文章の中で、彼は、上古の日本人は、今よりよほど寒暑に強かったと書いている。

確かに、木綿以外の植物由来の繊維は、あまり使い勝手がいいとは言えない。絹は高価で、またその肌触りも、木綿とは違う。また、中入れにする綿も、やはり木綿が優れている。

とはいえ、日本に木綿が一般的になったのは、十六世紀のことである。果たして、人間の種としての日本人が、たかだが数百年の間に、そう簡単に、寒暑に弱い方向に進化したりするだろうか。なまじ高機能な服があるばかりに、寒暑に強い遺伝子を持つ者は、自然淘汰されていなくなったのであろうか。あるいは、寒暑に弱い遺伝子を持つ者は、それまでは生存できなかったが、今は生存できるので、我々日本人は次第に弱くなったのであろうか。

さらに、柳田國男は、柔らかい食物と、歯科治療の技術が進んだ結果、我々の歯は弱くなったと書いている。曰く、「電車に乗ってみても、周りはみな、金歯だらけだ。装飾としてはともかく、能力的には、弱くなっている云々」と。果たしてそうであろうか。歯が痛むというのは、昔から書物にも絵にも色々と書かれている。病草紙など、有名だ。果たして、我々の歯は弱くなったのであろうか。

最近の若いものは・・・のソース

エジプトのパピルスに、「最近の若いものは・・・」と書かれているという話は、有名である。しかし、具体的に、どの文書に書かれていたか、そして、その実際の文面は、どのような意味だったかという事は、一向に明らかになっていない。

これは由々しき事態である。はっきりとした一次ソースがないのである。これでは、「最近の若いものは・・・」などと偉そうに講釈を垂れるジジババどもに反論できないではないか。

これに関して、調査を試みた人がいくらかいる。

最も古い「最近の若者は…」のソース: わたしが知らないスゴ本は、きっとあなたが読んでいる
2008-05-25 - 雑記

まあ少なくとも、日本にこの、何千年前のエジプトのパピルスにも、「最近の若いものは・・・」などと書いてあるという話を持ち込んだのは、柳田國男が始めであるらしい。幸い、私は定本柳田國男全集を、全巻所有している（ただし、別巻3の索引が欠けているのだが）。定本全集でいうと、14巻の、「昔風と当世風」という文章に、この話は載っている。読んでみると、なるほど確かに、そういう話がでてくる。

ところで、上記のサイトは、この該当部分の話しかひいていないが、この柳田國男の話には、続きがある。日本でも、平安末期に、似たような考えがあったと。考えて見れば、わざわざ四千年前のエジプトの例を引かなくてもいいのではあるまいか。日本にも、かつて、世の中の終焉を憂う思想は、広く行われていた。平安末期、鎌倉初期あたりには、「もう世の中は末である」という思想が、本当に広く行われていた。自分の読んだだけの本でも、平家物語や、愚管抄に、この思想は強く現れていた。

しかし、個人を無視して、世代をひとくくりにしてレッテルを貼る風潮は、どうにかならないものか。

世代 - Wikipedia

例えば、私の両親の学生時代には、大学の講義中には、決まって自称革命家とやらがやってきて、革命的会議にこの革命的な部屋を革命的に使用するので、講義を中止して部屋を明け渡せなどと主張することが、たびたび行われていたらしい。しかし、私の両親は、このような学生運動には与していなかったので、これをもって、私の両親も学生運動の世代であると言うのは、当たらないのではあるまいか。

ところで、この柳田國男の文章は、定本では大きく、「木綿以前の事」という題の下にある。これは、木綿が発明される以前、我々は何を着ていたのかという話だ。興味深い。

最近の若い者は・・・

Twitter / uupaa

PHP/HTML/CSS/JS/Flash → C#/Java/Ruby → C/C++ な話題を見ると、時代はかわったんだなぁとか思います。その順番で学ぼうとすると、応用→基礎な流れになり、どんどん派手さが無くなるので、自宅勉強だと長続きしないんじゃないか? と余計な心配も

読んでいて、ふと、こんな事を思いついた。

N88BASIC　→　C → アセンブリ　な話題を見ると、いやはや時代は変わったものですて。その順番にて計算機を学ぼうとすると、応用→基礎な流れになり、どんどん派手さがなくなるので、フローチャートが書けなくなるのではないか？　と余計な心配も致しますわい。

第一、ワシらの若い頃は、コンピューターを自作して、トグルスイッチでメモリ番地と値を指定して入力したか、あるいはパンチカードに穴を開けたものじゃて。パンチカードを物理的に切り貼りするから、パッチ（Patch）というんじゃ。最近の若い奴らは、キーボードと文字を表示するディスプレイで入力しよる。いやはや、恵まれすぎているのう。そんな軟弱な入力装置では、コンピューターの本質的な動きが分からないではないか。

バベッジ＆エイダ「コンピューター？　「計算をする人」とはどういう意味だ。それは我々の言うところの、階差機関のことか？」

パスカル「おまえらのたどっている道は、オレが300百年前に、すでに通過した場所だマヌケ。」

エジプトのパピルス「最近の若い者は・・・・・・・」

今も昔も、そんなに変わっていないだろう。例えば、遠い将来に、ASCIIや、Shift-JIS、UTF-8、UTF-16といった、マルチバイト文字エンコーディングが絶滅して、過去の資産としても価値がなくなったとしよう。皆、UTF-32、あるいは、未来の規格で文字をエンコードしているとする。そういう未来において、「昔はマルチバイト文字が主流であり、一文字が何バイトか、実際に解釈するまで分からなかった。今の若者は、そういった泥臭いアルゴリズムを知らない。それでは文字列処理の本質が理解出来ないだろう」、などと言ったところで、誰がまともに相手をするというのか。ただのジジイの昔語りではないか。

あるいは、こんな話もある。

「仰天もののディスケット」にはちっとも仰天しないという話 - やねうらお－よっちゃんイカを食べながら、しばし休息しよう。

例えば、SHARPのX1シリーズはクリーン設計のため、BIOS/ROMに相当するものがなかったのです。それゆえ、IPL(＝Initial Program Loader≒boot loader)がテープメディア or FDDからプログラムを読み込んだあとは、自力で(BIOSの力を借りずに)floopyにアクセスする必要がありました。

市販のソフトを出すならば、途中loadするタイプのゲームは、かならずFDDアクセスルーチンは自前で持っておく必要がありました。

つまり、当時の商用ソフトを出している誰もが、FDCにアクセスして、floopyを回転させ、seekして、index holeを検出して、1セクタ読み出す/書き出すというプログラムを書いたわけです。

この話をひいて、現代のJavascriptプログラマに、「昔はBIOSに頼らずに、フロッピーぐらい自前で読み書きしたものだ」などと講釈を垂れても、一体誰か能く聞くというのか。

Unicodeだってそうだ。たしか、PHPか何かの言語で、UTF-16化を、メモリの消費量が増えるというワケの分からない理由で断念したと聞く。これは大方、コケイジョンの無知と無理解とに基づくものであろう。第一、UTF-8では、ほとんどのCJK文字は、3バイトを消費する。我々日本人にとっては、UTF-16が、現時点で、最も現実的にメモリ消費量の少ない文字エンコードなのだ。

私などは、さらに一歩を進めて、UTF-32でエンコードすべきだと考えている。UTF-32ならば、サロゲートペアの心配すらない。たしか、UTF-32であっても、異字体セレクタというものが存在した気がするが、それは、まあ、知らなかったことにしておく。世の中は常に最良の選択が行われるわけではない。

マイ・コンピュータをつくる―組み立てのテクニック (1977年) (ブルーバックス)

適当に餌与えておけば年中ほっといても生きる魚

安心ちゃんねる！ 適当に餌与えておけば年中ほっといても生きる魚

興味深い。

笑い話

ケチな隣人

昔々、あるところに、とてもケチな主人が二人、家を隣り合わせて住んでいた。ある日のことである。ケチな主人は、釘を一本打つため、カナヅチを必要としてた。ケチな主人は、下男に言った。

「おい、ちょっと隣の家に行って、釘を打ちたいので、カナヅチを貸してくださいと頼んでこい」

そこで、下男は隣の家に行き、釘を打つのでカナヅチを貸して欲しい旨を伝えた。

「なに、カナヅチを貸して欲しい？　おう、いいともいいとも。貸してやろうさ。あ、ところで、打つというその釘は、木の釘かね。それとも、鉄の釘かね」
「はあ、普通の鉄の釘ですが」
「そうかそうか。ああ、残念だったな。ちょうど今、カナヅチは人に貸していたところだった。これは申し訳ない」

下男は不思議に思いながら、家に戻り、家の主人に、このやり取りを伝えた。

「何ィ、鉄の釘を打つと言ったら、カナヅチを貸してくれなかっただと。ふん、大方、鉄の釘を打つと、カナヅチが痛むので、わざと貸さなかったのだろう。なんてケチな奴だ」
「そういう事だったのですか」
「しかも、嘘までつくとはけしからん。こうなっては仕方がない。家にあるカナヅチを出して使おう」
「・・・・・・」

ホラ吹き

昔、婿入りをしてきた花婿に向かって、義父が言った。

義父「ワシはかつて、牛が千頭も、同時に入って足を洗えるほどの、巨大なタライを見たことがあるぞ。婿殿、お前さんは、どんなでかいものを見たことがあるかね」
婿「そうですね。僕はそんなでかいものを見たことはありませんね。ただし、僕もかつて、天にまで届くほど背の高い竹を見たことがありますね。」
義父「そんな長い竹など、何に使うのだ」
婿「義父さんの見たというタライの、タガに使うのでありましょう」

米倉千

昔々、あるところに、貧乏で正直な爺と、金持ちだが意地悪な爺が住んでいた。正直な爺は、ふとした善行のおかげで、打ち出の小槌という宝物を得た。欲しい物をつぶやきながら、この打ち出の小槌を振ると、欲しいものは何でも出るという。ただし、制限回数が定められていて、五回しか使えないとのことであった。

さて、この打ち出の小槌で、何を出すべきか。正直な爺は、婆と相談したところ、米を出すべきだという結論に達した。そこで、正直な爺が、「コメ」と言いながら、打ち出の小槌を振ると、家の前に、米俵が山のように積み上がった。

これだけの米を、そのまま野ざらしにするわけにはいかぬ。そこで正直な爺は、今度は、「クラ」と言いながら、打ち出の小槌を振った。すると、こんどは、大きな倉が現れた。

さて、正直な爺と婆は、これにて満足し、残り三回使える打ち出の小槌を、特に使うこともなく持っていた。そこへ、意地悪な爺がやってきて、急に大きな倉と、山のような米を手にした理由を聞いてきた。

人のよい正直な爺は、打ち出の小槌のことを打ち明けた。これを聞いた意地悪な爺は、打ち出の小槌を自分にも使わせるように要求した。正直な爺は、米と倉の他に、特にコレといって欲しいものもなかったので、打ち出の小槌を、意地悪な爺にあげてしまった。

さて、意地悪な爺は家に戻り、これまた意地悪な婆に、打ち出の小槌という宝物が手に入ったことを告げた。聞いて、意地悪な婆は、爺の手から打ち出の小槌をひったくると、欲深なニヤケ笑いをしながら、小槌を振った。

まず、意地悪な婆は、「雑炊千」と叫んで、打出の小槌を振った。すると、雑炊が千杯、出現した。次に、意地悪な婆は、「草鞋千」と叫んで、打出の小槌を振った。すると、草鞋が千足、出現した。

意地悪な爺は、打出の小槌を取り上げて、意地悪な婆を叱った。

「お前は一体なんという阿呆だ。千杯の雑炊など、どうやって食うのだ。すぐに腐ってしまうわ。それに、草鞋が千足あっても、どうしようもないわ。たったの三回しか使えないのに、もう二回も無駄に使ってしまったではないか」
「すまんよう。オレ、考えてなかったわ」
「ええい、もういい。ワシが最後に使う」
「だども、あと一回しか使えないだで、はぁ、どうするつもりだ。米を出したら倉が出ねーし、倉を出したら、米はねぇ」
「何、米と倉をいっぺんにたくさん出せばいいだけじゃて」

意地悪な爺は、打ち出の小槌を振り上げると、「コメクラ千」と叫びながら、勢い良く振り下ろした。すると見よ、千人の小盲小僧が、眼前に出現したではないか。

あっけにとられる意地悪な爺婆を前に、千人の小盲小僧は、それぞれ、千杯の雑炊を食べると、千足の草鞋を履き、どこかへ歩いて行ってしまった。

正直な打ち出の小槌を手に入れる経緯も書こうと思ったが、省略した。よくある話では、たいてい、竜宮かどこかから得たということになっている。善行というのは、刈り取ってきた柴を、水の中に投げ込んだところ、ちょうど竜宮では、柴が不足していたので、大いに感謝されたなどということが、ありきたりである。

柳田國男は、これを、前時代の水の神の信仰に基づくものと考えている。

また、正直な爺と意地悪な爺、上の爺と下の爺、などという対比は、いくつか意見を述べている。ひとつには、分かりやすい対比をさせることによって、話を面白くするということ。あるいは、その天運にあらざるものは、たとえ成功者のマネをしても、無駄だということなど。

駆け込みNBコメント続出

今日、23日がNBコメントの〆切なのだが、駆け込みNBコメントが続出している。いかにもプログラマらしい傾向と言おうか。

ソフトウェア特許のあり方

VP8 コーデックのライセンスについて - by edvakf in hatena

というか、これは最近はやりの手である。A社が、B社を、特許侵害で訴える。しかし、B社は、その特許で争う代わりに、別の特許を、A社が侵害しているとして反訴する。結局、うやむやになってしまう。この手法は、実にうまくいく。

しかしこれは、特許申請という、実に金と時間のかかる事務手続きができるほどの体力を持つ大手にしかできない手法である。そのため、大手は特許によりますます強く、ますます市場を独占してゆく。

ましてや、昨今のソフトウェア特許は、「当たり前だろハゲ」とか、「そんなのコンピューターが存在する以前からあったわボケが」などとツッコミたくなる内容だらけである。

これによってこれをみれば、現在の特許の仕組みは、何か根本的におかしいのではないかと思う次第である。

Clang、Boostをコンパイルす

LLVM Project Blog: Clang++ Builds Boost!

期待してもいいのかな。

そろそろNBコメント〆切わずか

そろそろ、C++0xのFCDに対するNBコメントの〆切が近づいてきた。あまりコメントが集まらない。現在のところ、全部で9件。単なるtypoなので、すぐ通ると思うのが4件。通っても通らなくても、些細な変更なのが、3件。あとふたつ、何で今までこんなの見逃してたんだ。N3000のときに排除されてるべきだろってのが1件。

馬鹿げたコメントが1件。

Crap my pants

風邪がようやく治ったと思ったら、今度はひどい下痢になった。水のような下痢だ。おかげで、日曜日は、朝から晩まで、精神と時の部屋、もとい、トイレで過ごすことになった。やれやれ、一応、15日に体調を取り戻したという自覚があったのだが、念のために一日様子を見ておいてよかった。もし土曜日にジョギングなんぞを再開していたならば、悲惨な目にあっていただろう。

さて、今回の下痢は、なかなか酷かった。自覚がないのだ。腹痛がないのはもとより、便意すら起こらない。にもかかわらず、出るものは出る。まさか、この歳になって、"Crap my pants"という言葉を、文字通り実行してしまうとは、オドロキだ。

しかし思うに、pantsという単語は、主にズボンを意味するのではないか。これは、解釈次第によっては、私の名誉を汚さないのではあるまいか。というのも、私は、ちょうどそのタイミングの時、ズボンを着用していなかった。あまりにも下痢が酷かったので、すぐにトイレに駆け込めるように、トランクス一丁だったのだ。つまり、ズボンは汚していない。これは幸運であったといえよう。

しかし、私の期待に反して、辞書を引いてみると、やはり、普通に下半身用の下着という意味も、当然ある。ダメか。残念だ。

閑話休題(それはさておき)

どうやら、私は、年に一度は体調を崩さなければならない性分らしい。毎年、季節の変わり目のどこかで、体調を崩して、数日は確実に寝込んでいる。二三年前も、一週間以上寝込んだことがあった。体調が戻ったあとで、健康の素晴らしさを再認識しつつ、ふとぽつり、「自分も年をとって、体が弱くなったのかな」とつぶやいたら、親父から、「何言っとるんや。君はちっさい頃から、何だかんだで、毎年、寝こんでたやないか。何も変わっとらへん」とツッコまれた。そういえば、そうだったかもしれない。

それはともかく、BoostConはものすごく面白そうだ。目玉は、もちろん、Instantiations must go!だ。decltypeとVariadic Templatesで、メタプログラミングが、初心者にも分かりやすくなる・・・・・・かなぁ？　少なくとも、高機能にはなるし、少し書きやすくもなる。が、メタプログラミングの難しさは、文法ではなくて、その概念なのだから、分かりやすくはならないのではないかと思う。これは、別に関数でもポインターでもテンプレートでも同じことだ。難しいのは、文法ではない。

まあともかく、その文法も、だいぶ分かりやすくなる。クラステンプレートのメタ関数は、お世辞にも分かりやすい文法とは言えない。これが、普通の演算子に置き換えられるだけでも、大した進歩と言えるだろう。

ようやく体調がよくなってきた

12日、昼頃まで寝過ごしてしまったと思ったら、どうも、起き上がる気がしない。これではいけないと、一時間ぐらいかけて起き上がったが、体が非常にだるい。これはいかん。体調を崩したか。

起きていると、体がだるくて仕方が無いので、今週は、ずっと寝ていた。執筆は、全く進まなかった。

今日になって、だいぶ体調が良くなってきた。ただし、まだ本調子ではないようだ。それに、寒気がある。しかし、どうやら寒いのは、体調のせいではないらしい。今朝は、明らかに寒い。もう五月も半ばだというのに、これは一体どうしたことか。

ところで、おとといのことだが、熱にうなされて、変な夢をみた。

広い体育館に、大勢の人間が整列していた。私も、その中の一人であった。我々は、ブラック会社の研修よろしく、非常に無意味な作業をしていた。何でも、日本には、公式の通貨単位が複数存在するそうだ。記憶では、九州円とか、中国円とか、大阪円とか、東京円などという通貨があった。我々に課せられた課題は、各種円の交換率を暗誦することであった。そこで、我々は、考えることをやめ、ただひたすら各円の交換率を復唱していた。

「九州円0.8、中国円0.5、大阪円1.2、東京円1.0・・・・・・」

はたして、交換率は固定なのだろうか。いや、そもそも、一体いつ日本の通貨が分裂したのか。だいたい、なぜ私はこんなことをしているのか。

次第に、体育館の中が、非常に熱くなってきた。当然だ。この大勢の人数がいて、しかも、まともに換気されていない。いや、むしろこれは、熱気ではなく、酸欠気味なのではなかろうか。ダメだ。このままでは窒息する。意識が・・・・・・。

と、ここで目が覚めた。気がつくと、私は毛布二枚の上に、さらに布団をかけて寝ていた。暑いのも道理というわけだ。

なんじゃこりゃ。

wtfjs

alert.call.call.call.call.call.apply(function (a) {return a}, [1,2]) // 2

@cramforceがこれを発見したとき、何かとてつもなくすばらしいのを吸ってたに違いない

これは単に、

Function.prototype.call.apply(function (a) {return a}, [1,2])

というのと同じであるらしい。しかし、これでもよく分からない。一体、どれほどのものを吸えば、このコードが理解できるようになるのだろうか。

PODじゃなくてもいいのでは。

C++0xではPODでもコンストラクタ相当のことができる・・・？ - Faith and Brave - C++で遊ぼう

それは、本当にPODであることが必要なのだろうか。C++0xでは、PODを細分化した。なぜ、プログラマーはPODを使いたがるのか。それは結局、二つの理由がある。

1. 構造体のオブジェクトを単なるバイト列にコピーして、差し戻したい
2. 構造体へのポインターは、構造体の最初のメンバーの指し示して欲しい

いわば、Cとの互換性や、その他の言語との相互利用のために、PODを利用するのだ。

struct POD
{
    int x ;
    int y ;
} ;

int main()
{
    POD pod = { 1, 1 };
    char a[sizeof(POD)] ;
    std::memcpy( a, &pod, sizeof(POD) ) ;// 単なるバイト列へコピー

    pod.x = 2 ;
    std::memcpy( &pod, a, sizeof(POD) ) ;// 差し戻す
    
    // ここで、pod.x == 1   

    // オブジェクトへのポインターをキャスト
    int * p1 = reinterpret_cast<int *>( &pod ) ;
    int * p2 = &pod.x ;

    // ここで、p1 == p2
}

しかし、このようなことは、PODではなくても、保証できるのではないか。そこで、C++0xでは、PODの機能を細分化した。どうすれば、trivially copyable classやstandard-layout classになるのかという条件は、省略する。規格を参照して欲しい。

trivially copyable class

このクラスは、triviallyにコピーができることを保証するものである。つまり、charやunsigned charの配列にmemcpyして、差し戻した場合、オブジェクトのストレージは、全く同じ状態になることが保証される。

standard-layout class

このクラスは、オブジェクトへのポインターは、クラスの最初のデータメンバーを指し示すことを保証するものである。つまり、reinterpret_castを使って、オブジェクトへのポインターを、最初のデータメンバーのポインターにキャストした場合、ポインターは、最初のデータメンバーを指すことが保証される。

では、PODとは何か。まず、trivial classというものが定義されている。これは、trivially copyable classで、さらに、ユーザー定義のデフォルトコンストラクターがないものである。PODとは、trivial classかつ、standard-layout classである。

つまり、これまでのPODの本質的な機能は、trivially copyable classと、standard-layout classで実現できる。PODである必要はない。C++0xは、PODが、実質、trivially copyable classと、standard-layout classを実現するために使われているという現状を鑑みて、PODでなくても、そのような保証ができるようにした。第一、デフォルトコンストラクターの有無は、クラスのレイアウトには、影響しないのだから。

まだPODであることを必要とするのだろうか。

Clangに自前のSTLが来る

LLVM Project Blog: New "libc++" C++ Standard Library

VCはクソすぎる。gccは汚すぎる。Clangは、C++プログラマにとって、福音になるかもしれない。

あの人へのインタビューができるかも

件のプログラミング雑誌では、Bjarne Stroustrupへのインタビュー記事を掲載している。この雑誌は、6月頃に発行できる予定である。

まだ、最初の雑誌も印刷されていないのに、次の話をするのもアレなのだが、Volume 2では、さる有名なあの人へのインタビューができるかもしれない。面白くなりそうだ。

ああ、始まってしまった

Vendors using Competing Prefixes - Snook.ca

こんなことが行われていたとは。MSらしいといえば、MSらしいが。ああしかし、地獄へようこそ。

進まない

C++0x本の執筆が、遅々として進まぬ。ブログを更新する暇がないくらい、取り組んでいるというのに、肝心の文章は、さっぱり進まぬ。とかくにBasic conceptsは難しい。

結局、完全に正しい詳細というのは、規格の文面の直訳に成り下がってしまう。それなら、規格を読むに如かずと言われたら、立場がなくなってしまう。私は、自然言語の正しい翻訳などということは不可能だと考えている。

件のプログラミング雑誌を創刊するにあたり、Bjarne Stroustrupへのインタビューを敢行した。詳しくは、6月頃に発行される雑誌をみてほしいが、このインタビューでは、C++の教育に関して、BSへ意見を求めている。BSは、あまりに深い詳細を解説するのは無駄であると答えた。何でも、詳細を理解することは可能だが、仮に理解したところで、現実のプログラミングの能力が上がるわけではない。言語の詳細は、必要なだけ理解しておけばいい。ということであった。

実際、BSの考えは正しかったと、いまさらになって痛感している。規格で定義されている、本当に正しい厳密な詳細は、C++コンパイラや、STLやBoostを書くのでもない限り、現実のプログラミングでは、まず役に立たない知識だ。

もう一つ懸念しているのは、私の執筆に対する意欲が、どうも上がらないということである。これは、結局、私自身は、C++の言語自体に対する参考書を必要としていないというのが、原因なのだろう。私は、C++について、何か疑問の生じることがあれば、まず規格を確認する。誰か他人の書いた参考書ではないし、ましてや、自分の書いた文章でもない。私は、STLのクラスだとか、クラスのメンバーなども、参考書などではなく、規格を参照して使う。

というわけで、私が読む参考書というのは、規格ではカバーしていない部分、つまり、プログラミングのテクニックやアルゴリズム、あるいは、規格の文面には載っていない歴史的経緯といった類の本になる。つまり、今私の執筆している言語機能を解説する本は、私自身は、特に必要としてないのである。これでは意欲の維持が難しい。

しかし、世は、言語機能を解説する本を必要としている。ここで誰か、規格をかじっていて、実務経験も豊富な真のプログラマが、私のかわりに本を書いてくれるのが、最良なのだが、なかなか、そういうことにはならないようだ。

やるしかないのか。

これはすごい

/sandbox/ftmpl

なかなか面白いが、型を変数として扱うのはどうなんだろう。型に対して操作したいときは、いちいちstd::valueメタ関数を使うのだろうか。もっとも、多くの場合（SFINAEに使いたい場合など）、すでにその型に対する変数（parameterの形などで）を作っているから、それを利用出来るだろうが。

#include "type.hpp"
#include "value.hpp"
#include "apply.hpp:
#include "is_same.hpp"

template < typename T1, typename T2 >
void f( T1 t1, T2 t2 )
{
    using namespace boost::ftmpl ;
    // true
    bool const result = unwrap_value< BOOST_FTMPL_UNWRAP(apply( is_same, t1, t2 ) ) >::type::value ;
    // type_t< true_t >
    using result_type = BOOST_FTMPL_UNWRAP( apply( is_same, t1, t2 ) ) ;
}

何にせよ、decltypeにより、夢が広がる。

easy peasy

英語は使わないと忘れる。いつものように英語を聞いていたところ、easy peasyなる言葉が耳に入ってきた。意味は自明だが、なかなか面白い言葉だ。

思うに、英語には、この手の言葉遊びが、非常に少ないと思う。似たような言葉に、Holly Mollyとか、Okey Dokeyがある。他にもあるだろうか。

ちなみに、このeasy peasyという言葉の歴史が気になったので、調べてみた。何でも、1970年代に、イギリスのテレビで、Lemon Squeezy detergent（レモン絞り洗剤）なる商品を広告するのに、この言葉を使っていたらしい。広告の最後に、"Easy Peasy Lemon Squeezy"と締めるのが常だったらしい。

まあ、最近は、この手の言葉を、あまり聞かない。このeasy peasyにしたって、私のきいたコンテキストでは、コミカルなキャラを目立たせようと、わざとこういうセリフを言わせていた。

最近の3Dとやらについて

しばらく前から、ディスプレイの3Dということが盛んに喧伝されるようになった。私の記憶では、nVidiaは、まだまともな対応ディスプレイがない頃から、すでに3D表示をサポートしていたはずだ。

ここでいう「3D」とは、いわゆる立体視によって、擬似的に、映像に奥行きを感じさせる表示方法である。360度全方位から見ることのできる、理想的な3Dではない。

この3Dは、はたして流行るのだろうか。

昨日、たまたまビッグカメラに立ち寄って、店頭に展示されている動作デモを見た。実写と、3DのFPSゲームの映像が流されていた。たしかに、奥行きはあった。しかし、これは、はたして値段相応の価値があるのだろうか。

私の感覚では、奥に巨大な一枚壁があって、その前で、物体が動いているように見えた。何といえばいいのだろうか。リニアな奥行きではない。切り絵を重ねあわせて動かしている感じだ。つまり、球を表現できない。

そういうわけで、よくある、平行法や交差法で立体視できる画像と、見た感じは同じであった。

それに奥行きは感じられるのに、なにか違和感がある。あるいは、焦点の問題なのだろうか。我々が近くを見るときは、遠くのものはぼやける。反対に、遠くを見るときは、近くはぼやける。今話題の3Dディスプレイには、これがない。

少なくとも、私は、3Dディスプレイで映画を観たいとは思わなかったし、また、FPSゲームをやりたいとも思わなかった。

当時、ゲームは、リアルタイム3DCGが発達したことによって、生き延びた。リアルタイム3DCGがなければ、ゲームは、とっくの昔に滅んでいただろうという意見を読んだことがある。では、この「3D」は、ゲーム業界の活力になるだろうか。聞説、任天堂もソニーも、次世代のポータブルなゲーミングコンソールは、この3Dをサポートする予定であるらしい。疑問だ。

私がディスプレイに望むのは、立体視などでない。高DPI化である。漢字は複雑な文字である。小さい漢字を読むためには、紙への印刷と同程度のDPIがほしい。私は、紙への印刷と同じ程度のDPIを確保できるまで、日本では、電子書籍は流行らないだろうと考えている。アンチエイリアスは、ごまかしに過ぎない。高DPIなディスプレイがほしい。

書けない

この一週間、ずっとC++のname lookupのことを考えていた。その前の一週間も、やはり、name lookupについて、思いを巡らせていた。一体、name lookupを、どうやって説明すればいいのだろう。

C++本の執筆が、全く進まない。困った。

name lookupについては、理解している。理解はしているものの、これを説明することは難しい。

今までも、このブログで、C++について、色々と書いてきた。ブログに書くのは、簡単だ。というのも、書いた内容に責任を負わなくていいからだ。それに、間違っていれば、あとからいくらでも書き直せる。しかし本に書くのは、難しい。

単に、ブログは無料で、本は金を取るからなどという理由ではない。私の書いた本は、一般の流通に乗り、全国の書店の店頭に並ぶ。私の知る限り、今現在、C++0xの参考書を書いている他の人は、いないはずだ。入門書なら、いくらでも出版されるだろうが、今私が書いているような、言語の詳細を説明する本を書いている人は、いないはずだ。

ひとたび印刷された本は、書き換えることができない。責任は重大である。下手なことを書く事はできない。

しかし、こんな完璧主義を続けていたのでは、いつまでたっても本は完成しない。結局、どこかで妥協しなければならないわけだ。

規格を読めないのは、英語がわからないからであり、むしろ、規格の日本語訳をするべきであるという意見もある。しかし、それは間違っている。規格がどの言語で書かれているかなどということは、些細な問題だ。日本語だろうが、英語だろうが、スワヒリ語だろうが、たとえ規格が日本語で書かれていても、問題は変わらない。

思うに、世の中には、完全なものは存在しない。完全を求めるのは不可能だ。かのBjarne Stroustrupでさえ、C++のすべてを理解してはいないのだ。Stroustrupが、C++についてわからないことがあればどうするか。彼は、規格や、自分の著作を参照する。彼の言によれば、「C++の詳細な定義を、完全に丸暗記するのは無駄である。それよりも、もっと現実的なことに、労力を割くべきである」ということだそうだ。

もはや、この問題に直面して、二週間になる。いや、去年から、このおそれはあった。これ以上、執筆を続けるためには、ここで妥協というものをしなければならない。

C++の標準規格でさえ、妥協をしている。C++の標準規格が制定されるときというのは、皆が、「この規格は、もはや、ある程度使えるようになった」と妥協した時である。この妥協は、1998年に起こり、最初の標準規格が制定された。その後、その妥協した産物である規格には、多くのツッコミが入った。

もし、完全なものがあるとすれば、それは、それ以上変更する必要がないはずだ。C++自体でさえ、完全ではないのに、どうして完全な参考書が書けようか。

中国の伝説では、昔、ある皇帝が、完全な本というものを書かしめて、誰でも読めるように、公共の場所に置き、「この本に、一字をも、付け加え、または取り除くことのできるものがあれば、誰でも自由に申し出よ」と宣言したという。詳しいことは忘れたが、確か、こういう話があったはずだ。いま、出典が思い出せない。誰かご存じの方は知らせてください。