本の虫

アプリケーションがクラッシュして、デバッガXが、自動的にアタッチされたとしよう。なぜなら、システムの設定がそうなっているからだ。しかし、急にデバッガYを使いたくなった。デバッガYをインストールはしてみたが、どうやって、現にアタッチされているプロセスのデバッガ、XからYに変更すればいいのだろうか。デバッガYでアタッチを試みても、STATUS_PORT_ALREADY_SETエラーコードが返るだけである。なぜならば、あるプロセスにアタッチできるデバッガは、ひとつだけだからだ。しかし、前のデバッガをデタッチしてしまうと、アプリケーションは消えてしまう。このCatch-22問題はどうやって解決すればいいのだろうか。

こうすればいい。

ntsdデバッガを、non-invasive モードでアタッチする。これには、-pの代わりに、-pvオプションを使って、プロセスIDを指定する。

ntsdデバッガは、プロセス内のスレッドをすべてサスペンドさせる。

ここで、デバッガXに、プロセスをレジュームさせ、デタッチする。もし、デバッガX自体がntsdならば、コマンドはpdである。

次に、デバッガYをプロセスにアタッチさせる。

最後に、non-invasiveモードでアタッチした、ntsdデバッガを、qdコマンドでデタッチさせる。

non-invasiveモードとは、デバッガをプロセスに、実際にはアタッチしないのだ。単に、プロセス内のすべてのスレッドをサスペンドし、メモリを覗き見るだけなのだ。そのため、元のデバッガをデタッチして、アプリケーションの実行を再開しても、アプリケーションは、実行を再開しない。なぜならば、non-invasiveモードのntsdデバッガが、まだアタッチされていて、プロセスをサスペンドさせているからだ。そこで、新しいデバッガをプロセスにアタッチすれば、デバッグが再開できる。

いうなれば、non-invasiveモードのntsdデバッガは、橋渡しの役割を果たす。つまり、デバッガを交換する間、プロセスを止めておけるのだ。

この情報は、誰かの役に立つはず。

ちなみに、Catch-22とは、同名の小説に由来するパラドックスである。小説内に出てくる、ジョン　ヨサリアンという人物は、パイロットの軍務から免除されることを願っていた。「免除」されるには、軍医の診察を受けて、「飛行に不適」と診断されなければならない。

「不適」と診断されるには、パイロットが自ら志願して飛びたいと願えばよい。なぜならば、自ら身を危険に晒したいと考えるのは、「狂人」だからである。

しかし、「問題」は、「不適」と診断されるためには、まず自分から、「軍医の診察を受けたい」と申請しなければならない。自分から診察を願うぐらいなら、まだ「まとも」な精神状態である。この条件を考えると、「不適」と診断されるのは、不可能である。

2010-01-07

メイリオはアップデートできる

実はメイリオまだ進化中！誕生秘話を河野氏に聞いた－＠IT

Windows Vistaのメイリオが、実はまだ中途半端なできて、Windows 7では、改良されているというのは聞いていた、また、メイリオUIという、従来のMS UI ゴシックにサイズを合わせたようなフォントが、新しく出来ているというのも聞いていた。

気になっていたが、残念ながら、私はVistaを使っている。たとえ、Vista同梱のメイリオが中途半端だったとしても、そうかそうかと、どこからから、ごにょごにょげふんげふんして、フォントをダウンロードしてくることはできない。

でも、アップデートがあったらしい。

ダウンロードの詳細 : メイリオフォントアップデート

知らなかった。さっそく入れてみた。

これはMeiryo UIフォントによる文字。薔薇檸檬憂鬱御璽

これはメイリオフォントによる文字。薔薇檸檬憂鬱御璽

なるほど、この記事では、Meiryo UIを使ってみよう。

しかし、この人、電話帳を節約するために、かなり斬新なことをしている。製本のことはよく知らないが、余白というのはあれだけ広く必要なのだろうか。

しかし思うのだが、やはり、メイリオは、普通のメイリオの方がいい。

「UIゴシックというのがありますよね。ひらがなやカタカナを70％にコンデンス（細く）したものです。これはこれで非常に見にくいんですが、メイリオでもそれをやれと言うんですね。ひどいことになっています。一応コンデンスされたメイリオもWindows 7に入っていますが、本当に読みやすいものにするなら90％とか85％ぐらいまでなら我慢できるかもしれませんが……。あるいは、ひらがなの『り』のような文字は両脇に白いスペースがたくさんできますので、英語のように、それぞれの文字の幅を変えてプロポーショナルにできるはずです。これはまた時間がかかる話ですけど、いずれやっていかなきゃいけない問題だと思っています」

そういえば、偶然だが、私はC++0x本の余白について考えていた。他のパーフェクトシリーズは、かなり広い余白がある。これは無駄ではないか。詰められないのだろうか。

結局、記者クラブは何も変わらんな

「Web専業メディアはオープン化対象外」　総務省記者クラブに定例会見への参加条件を聞いた - ITmedia News

これは面白い

なぜ私たちはいつも締め切りに追われるのか

面白い。

松尾ぐみの論文の書き方 | 松尾豊

これも参考になる。

「～において」「～については」などは極力使わないようにしましょう。また、「前述の」「後述するように」「～節で述べた」などの指示詞も極力使わない方がよいです。これらの語は、読者の注意を特定の部分に向ける語ですが、よい文章は、こういう語を使わなくても、注意の対象を読者が自然に意識できるものです。文章というのは、複雑な思考の直線化（linearization)ですから、ポインタをたくさん使わないといけないというのは、直線化がうまくないということです。

2010-01-06

C++0x本：文体について

文体について考えてみる。人間である限り、文体という、文章の個性は、当然でてくる。問題は、その個性をどこまで主張するかということだ。

たとえば、ですます調だ。ざっと見た限りでは、日本語の技術書は、ですます調を使っている方が多いと思う。しかし、私はですます調が嫌いなので、使おうとは思わない。

語尾をです、ますから、だ、であるに変える程度なら、別にそれほど問題でもない。それ以外の文章の個性はどうだろう。

例えば、このブログの文章には、かなり「遊び」を入れている。といっても、あまり意図的に入れているわけではない。長い文章を書こうとすると、自然に入ってしまうのだ。この遊びがないと、長い文章がかけない。つまり、文章が単調だと、読むだけでなく、書くのもつまらないのだろう。

とはいえ、これから書くのは本である。個人のブログではない。私は、本には、「よろしく～すべし」とか、「まさに～せんとす」、とか、「～をして～せしむ」などといった表現、あるいは、聞説、所謂、就中、不斜、などといった漢文表現をいれるつもりはない。これは、私が漢文を好きだから、たまに使っているのであって、さすがに、プログラマに漢文の素養を求めるのは、間違っている。したがって、使わない。

それ以外の、差し障りのない遊びをいれるかどうか。あまり入れるべきではない。しかし思うのだが、単調な文章というのは、読んでいてつまらない。ましてや、今回は言語を解説する本である。私は、規格の、Generalとか、Lexical conventionsとか、Basic concepts、あるいは、Standard conversionsなども、すべて解説するつもりでいる。これは、知っていても、直接役に立つというわけではない。しかし、C++を理解するためには、知っておかなければならない。よく、C++が理解できないといわれるのは、文法が理解出来ないのではなくて、この辺を解説している参考書がないからなのだ。

世間には、やる夫で学ぶシリーズや、マンガで分かるシリーズ、萌えるシリーズなどの、参考書が存在する。これも、一種の文体とみなしていいのではなかろうか。これらは、遊びの部分が大きすぎるので、問題もあるのだが、つまらないから学ばないのと、遊びの部分が多くて詳細を解説していないが学べるのとでは、どちらがマシだろうか。

私の母親は、教員免許を持っていて、昔は塾の講師をしていたらしいが、授業する秘訣に、笑いを入れるというのがあったらしい。塾の授業は、何時間もある。単調に学んでいただけでは、集中力が続かない。定期的に、笑いを入れた方が、効果的だったという話である。

これを考えると、文章に、差し支えない範囲で、遊びを入れて、読みやすくするのは可である。

問題は、私の笑いのツボは、少しく世間と乖離しているという懸念がある。例えば、私は、Windows 7のBeep ドライバってどうなったのさ？という記事は、かなり気合を入れて書いた。しかし、たったの2はてブしか得ていない。一方、Windows 7にGod Mode、発見さるという記事は、かなり投げやりに書いた。ところが、こちらは20はてブも得ているではないか。

これはどう考えても解せない。絶対にBeepの方が面白いはずである。こんな面白い記事には、今頃100はてブはされていてしかるべきだ。解せん。

と、このように、私は遊びを入れたがるのである。まあ当然、一般大衆にも分かりやすいのは、フォルダにある特定の名前をつけただけで使える、Windowsの隠し機能の方だろうが。

すげー

HTML Slidy (1)

いい加減、WordとかPowerPointの類のソフトウェアは、死滅するべきだ。XHTMLとCSSとJavascriptがあれば、なんでもできる。

Debug Interface Access SDK

Visual C++ Team Blog : DIA based Stack Walking
Debug Interface Access SDK

Windowsプログラムのデバッグ用のSDK

私の専門ではないけれど、興味深かったので紹介。このブログを読んでいる人で、興味深いと感じる人はいるはず。

C++0x本：正規表現を解説すべきか

C++0xには、正規表現ライブラリが入る。正規表現がいかに便利であるかは、いまさらここで言うまでもないだろう。問題は、正規表現の文法を解説すべきかということだ。

実際、紙面の都合上、ライブラリをすべて解説できるかどうかはわからない。コア言語と、言語サポート・ライブラリだけで、かなりページを消費すると思う。出版社側は、どうも一冊にこだわっているらしく、その場合、ライブラリは広く浅くといった紹介にならざるを得ない。

もし仮に、ページ数を考えずに、深く解説できたとしても、果たして正規表現の文法自体を解説すべきだろうか。

私は、正規表現を語れるほどには、詳しくない。もちろん便利なので、たまに自分でも正規表現を書くが、文法を覚えていないので、文法書を見ながら書く。

私は、一応、規格書を読むだけの読解力には恵まれているので、正規表現の文法一覧のようなものを書くことはできるだろうと思う。しかし、そんな本は、すでに山ほど出ているのである。しかも、どの本も、私より正規表現を理解している者の手によって書かれているのである。

さらに、C++の規格では、正規表現を定義していない。どのように定義しているのかというと、別の規格を参照している。

さらに、C++で使える正規表現は、一種類ではない。たくさん種類がある。std::regex_constants::syntax_option_type定数で、正規表現の文法を切り替えることができる。case sensitivityとか、最適化などの細かいオプションを除けば、以下のような方言が使える。

ECMAScript: ECMA-262で規定されている正規表現、ただし一部変更あり
basic: POSIXで規定されている、basic 正規表現。
extended: POSIXで規定されている、extended 正規表現。
awk: POSIXのユーティリティである、awkの正規表現。
grep: POSIXのユーティリティである、grepの正規表現。
egrep: POSIXのユーティリティである、grepに-Eオプションを渡した場合の正規表現。

現時点では、私はどれがどれぐらい違うのかということを論ずるだけの知識を持っていない。これだけ種類があって、選べるということが、正規表現オタクを喜ばせるのか、あるいは、これでもまだ少ないと不満がらせるのか、それすら分からない。

ECMA-262に対する変更は、本当に細かい。どうも読んだ限りでは、POSIXのClassAtomExClass, ClassAtomCollatingElement and ClassAtomEquivalenceに相当する機能を付け加えるような文面になっている。

それより気になるのは、文面では、ECMA-262とだけ言っている事だ。何番目の規格とは、明示していない。正規表現が正式に入ったのは3rdだというので、少なくとも、それ以降である。規格書を読むと、3rdと5thでは、微妙に文法定義の方法が違っているのだが、表面的には変わらないのだろうか。単にECMA-262と言っているということは、将来、規格改訂で、文法が変わった場合、それに追随するということだろうか。

とにかく、C++独自の正規表現を定義しているのではなくて、いずれも、すでに十分実績のある、他の規格を参照するようになっている。これらの正規表現自体を学ぶのであれば、すでに本が、洋書和書を問わず、山ほど出ているので、わざわざ解説するまでもないだろう。

2010-01-05

最高にカッコいいレゴマシーン

自動ドミノ並べ機

Windows 7のBeep ドライバってどうなったのさ？

Larry Osterman's WebLog : What’s up with the Beep driver in Windows 7?

今朝早く、ある人が僕に、「なんで64bit版のWindowsは、PCの内部beepスピーカーをサポートしてないんだい」と訊ねてきた。その答えは、すこしばかり複雑なんだ。また、PCを取り巻く環境とも関係していて、なかなか面白い問題だ。

まず、当時[1]のbeepハードウェアが、どのように機能しているかということについて説明するね。元々、IBM PCは、Intel 8254 プログラマブル・インターバル・タイマー・チップを搭載して、システムクロックを作り出していたんだ。IBMのエンジニアは当時、PCは音を鳴らす必要がある（高音質とまではいかないけれど）と考えたから、8254を、矩形波生成器として使うことにした。このために、エンジニア達は、チップの第三タイマーを使って、矩形波モードを操作できるようにし、好きな出力周波数をカウントできるようにしたんだ。このため、Out2ラインは、クロックが0になるたびに、highからlowへとトグルする。ハードウェアの設計者は、チップのOut2ラインをBeepスピーカーにつなげた。するとほーら、クロック・チップを使って、Beepスピーカーにノイズを鳴らすよう、プログラムできるようになったじゃないか（それほど良い音じゃないけど、まあノイズには違いない）

Beep() Win32 APIは、基本的に、この8254 PIC機能の、薄いラッパーに過ぎない。Beep() APIを呼ぶということは、8254をプログラムしてBeepスピーカーから音を鳴らすということなんだ。

25年もの月日は、飛ぶように早く流れた。PC業界は大きく変わり、PCのアーキテクチャも変わっていった。この時点で、もはや8254を、プログラマブルな割り込みコントローラとしては使わなくなってしまったのだけれど、まだまだ新型PCにも搭載されている。というのも、8254は、いまだに現役でBeepスピーカーを操作するのに使われているからなんだ。

他に、25年のうちに起こった出来事といえば、パソコンはもっともっといろんなことができるようになった。今や、パソコンは奇妙で斬新な新型ハード・ディスク・ドライブを搭載しているっていうじゃないか。僕はよく分からないんだけど、中には30メガバイト以上もの容量をもつヤツがあるっていう話じゃないか。（でも、そんな大容量のハードディスクなんて、誰が欲しがるんだろうね。僕には分からないや）。それに、サーバーじゃないパソコンはみんな、サウンドカードを搭載してる。そんなわけで、今売られているパソコンは、音を鳴らす方法が二つある。サウンドカードと、昔ながらの、内部Beepスピーカーにつながってる8254とだ。（あるいは、サウンドカードの専用入力とか、これは後で説明するけど）

この25年のうちに起こったことは、まだまだある。パソコンは家電になった。パソコンメーカーは、厳しいコストカットを余儀なくされることになったんだ。メーカー各社は、8254に目をつけて、言った。「なんでコレを取り除けないんだ？」と。

でも、それは無理な相談だった。なんでかっていうのが、ものすごく期待はずれの変な理由なんだ。障害を持つアメリカ人法（ADA）のせいなのさ。

ADAだって？ADAとパソコンのBeepと、何の関係があるっていうんだい？　それがねぇ、この25年間のどこかで、Win32 Beep()は、障害者補助の技術として使われてたらしいんだよ。StickyKeysみたいな、障害者補助技術は、Beep() APIを使って、一連の音を鳴らしていたんだよ。Windowsには、六つの障害者補助技術(AT)音が、組み込まれて、その実装は、win32k.sysの奥深くに入り込んでいるんだ。

でも、なんでそれが問題になるのさ？　それがねぇ、多くの業界団体（政府と民間企業の両方）では、障害者補助技術のない製品は買わないっていう決まりがあるらしくて、つまり、メーカー各社は、beepハードウェアがないパソコンを、そういう業界団体に売ることができないってわけなんだ。

この問題に、最初に気がついたのは、マイクロソフトが64bit版のWindowsを開発していたときなんだ。というのも、最初の64bit版Windowsは、サーバー用途だったから、64bit機が想定する環境として、8254のサポートなんてなかったんだ（障害者補助技術の決まりごとは、サーバーに対しては、すこし緩められたらしい）。でも、一般ユーザー向けの64bit OSを開発しだしたら、問題に直面してしまった。一般ユーザー向けのOSは、障害者補助技術をサポートしなければならなかったんだ。そんなわけで、何とかしてbeepをサポートしなくちゃいけなかったんだ。そもそも、beepハードウェアがないパソコンばかりなのにね。

Windows XPでは、winlogonに、ソレ用のコードを書いて、この問題に対処した。一応動いたんだけど、ちょっと複雑だった（この話には直接関係ないけどね）。Windows Vistaでは、僕は設計をやりなおして、障害者補助のbeepの仕組みを、新しい「ユーザー・モード・システム・サウンド・エージェント」に移した。

この問題のあるパソコンというのは、64bit機だけだから、この機能は64bit版Windows限定の話だよ。

これはつまり、パソコンメーカーは、まだまだ8254というハードウェアをサポートし続けなくちゃならないってことなんだ。そもそも、ユーザーが32bit版のOSを買った場合、もしかしたら、障害者補助機能を使いたがるかもしれないからね。

Windows 7では、この問題を完全に解決した。Beep.sysにあった機能もぜんぶ、ユーザー・モード・システム・サウンド・エージェントに移したんだ。これで、Beep() APIを呼んでも、8254チップを操作するかわりに、実際の音を再生するユーザー・モード・エージェントに丸投げできるって寸法さ。

この計画では、思わぬ利点もあったんだ。8254出力ラインは、サウンドカードの専用入力につながってるって、さっき言ったよね？　このサウンドカードへの入力のせいで、サウンドハードウェアは、つねにフルパワーで電源供給されてなきゃならないんだ。だって、アプリケーションがいつ、Beepを呼んで、8254を叩くか、分からないからね。（電源管理機構では、8254は操作できないんだ。だから誰かが8254の第三タイマーをプログラムした時だけ、サウンドハードウェアを起こすなんてことはできないんだ）。Beep呼び出しを、システム・オーディオ・ハードウェアにリダイレクトすることで、サウンド・ハードウェアは、必要になるまで、スリープさせておけるようになったんだ。

このリダイレクトで、また思わぬ利点があったんだ。それも複数。たとえば、間違って、0x07文字を含むファイルをtype、あるいはgrepしたとき（たとえば.objファイルとかね）、あのイヤーなノイズを消すことができるようになったんだ。beepはもう、パソコンのスピーカーから再生されているわけだから、パソコンのミュートボタンで、ささっと消すことができるってわけさ。また、beepのボリュームを操作することもできるようになったよ。

また、思いがけない発見もあったよ。一番傑作なのは、アプリケーションがBeep()を使っていたということに、みんな気がついたってことだね。みんな、パソコンをかなり離して置いていたり、あるいは、周りの音が大きすぎたりして、パソコンがbeepを鳴らしていることに、気がつかなかったんだね。それが、いきなり手元のスピーカーから鳴り出したんだからね。

[1]　というわけで、僕がいまだに1980年ものの、昔のIntelの部品データ・カタログを捨ててないのは、正しい選択だったってわけさ。

Larry Ostermanは、このブログでも、何度か取り上げているが、Raymond Chenに次ぐ、有名なマイクロソフトの古参プログラマのブロガーである。Raymond Chenほど頻繁ではないが、たまに、Windowsの昔話を疲労してくれる。彼はWindowsのオーディオ周りを担当している。

ちなみに、Larry Osterman本人は、かなりのヒゲモジャなので、この翻訳の文体は、少し見かけに合わないかもしれない。

むかし、16bit DOSからアセンブリで直接8254を叩いて、音を鳴らして遊んでいたのを思い出した。

それにしても、最近は翻訳文が、流れるようにスラスラ出てくるから気持ちがいい。翻訳の仕事でもしたいものだ。

C++0x本：言語とライブラリの分離

どうしても、言語とライブラリを一緒に解説しなければならない部分がある。

たとえば、Move Semanticsだ。あるいは、Initializer listsだ。メモリ周りも、言語と完全に切り離すことができない。

実際、Move Semanticsというのは、言語でもライブラリでもなくて、プログラミングのテクニックに属する。しかし、これを解説しないわけにもいかない。というのは、規格書には、Move Semanticsという言葉自体は出てきているからだ。具体的な解説はないものの。

一体どうすればいいのだろう。どうしても、言語とライブラリを明確に切り離せないものも存在する。個々に詳しく解説した上で、言語にもライブラリにも属さない章を作り、そこで、組み合わせて使う場合を解説すればいいのだろうか。

C++0x本：内容は重複してもいいのではないか

本の解説は、重複してもいいのではないかと考えている。

たとえば、lvalueとrvalueの違いと、C++0xの二種類のreferenceだ。lvalueとrvalueの違いは詳しく解説するとして、referenceの章でも、多少解説を加えてもいいのではないか。差し当たって、最低限必要なことだけ触れて、「より詳しく知りたければ、X章を参照されたし」などと書くのはどうか。

referenceと、templateのargument deductionもそうだ。argument deductionは、それ単体で、詳しく解説する必要がある、しかし、referenceの解説や、std::forwardの解説の部分でも、触りだけ取り上げてもいいのではないか。このブログでC++を解説するときも、この機能については、別に解説しているので、ここでは一再解説しない、などという書き方はしなかった。

C++という言語には、それ単体で使える機能というものは、あまり存在しない。ある機能Xは、機能Yを知っていなければ使いこなせない。ところが、機能Yも、機能Xの存在を前提に定義されている。といった類の言語機能が、数多くある。

そして、人間の頭というのは、コンパイラのように働かない。ある機能について学びたくて、参考書の章を読んだとする。「この機能を使いこなすためには、他の機能X, Y, Zを知っていることが前提である。まず、それぞれの章を参照されたし」となっていた場合、果たして、その本は人間にとって便利と言えるだろうか。デジタルデータですら、そんな記述をしていては読みにくいのに、いわんや紙に書かれたアナログデータをや。

内容の重複は、ある程度はしかたないのではないか。

Windows 7にGod Mode、発見さる

Understanding Windows 7's 'GodMode' | Beyond Binary - CNET News

Windows 7にGod Modeが発見されたようだ。

どこにでもいいからフォルダを作成
名前を、"GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}" に変更
フォルダを開く

Windowsの設定変更の一覧が表示される。コントロールパネルより詳しい。

Vistaでも動くそうだが、64bit版は、クラッシュするとの声もある。実際に、手元のVista 32bitでは、動いた。

別にフォルダ名は、GodModeでなくてもいいのだが。

静的型付け言語は時代遅れなのか？

2010-01-04 - きしだのはてな

たしかに、Webサイトを構築する上では、強い静的型付けは、じゃまになるのかもしれない。

ところで、

さて、これからは、JavaScriptが高速化したりHTML5が出たりで、ブラウザ側で処理を行うアプリケーションが多くなっていく。ユーザーインタフェースに対する要求の高まりへのJavaScriptでの対応の難しさから、Flexなどの出番も増えると思う。

これ以上、Flashだけで構築されたサイトが増えてたまるものか。動画だけ再生できてりゃいいのだ。

2010-01-04

C++0x本：執筆に必要なもの

C++0x本を執筆するにあたって必要なものがある。人と金と時間だ。

人が必要である。規格を読んで文章を書くのは、一人でできるとしても、自分の文章を自分でデバッグすることはできない。こう書くと無責任なように聞こえるかもしれないが、プログラマなら誰しも、「自分の書いたコードのバグを、自分で見つけるのは難しい」という考えは、理解してもらえると思う。これは能力の問題ではない。単に、自分の中で、正しいと信じているから、バグを見つけられないのである。かえって他人の方が、バグを見つけやすい。自分のバグを見つけることまで含めて能力だといえば、たしかにそれはそうかも知れない。しかし、OSやブラウザといった、一流のプログラマによって書かれた一流のソフトウェアにすら、バグは山ほどある。とすれば、誰もそんな能力を有していないのである。

よって、査読者が必要である。それも、大勢必要である。確率などというものを言いたくはないが、より多くの人に確認してもらった方が、誤りを発見出来る確立は上がる。査読者は必要だが、残念ながら、対価をはらうということはできない。私は、払いたくても、金がないのだ。

こう書くと、すぐに出てくる発想は、「C++0xを学ぶためなら、査読してくれるボランティアもいるだろう。執筆途中の原稿を、どこかにアップロードして、広く公開すればいいのではないか。誰か読んでくれるだろう」というものである。確かに、より多くの人に見てもらうという点では、最も優れている。しかし、それでどの程度、結果が得られるだろうか。

私が必要としているのは、批評や提案である。「これは良かった、悪かった」という一般的な感想ではない。「この部分の記述は間違っている、なぜならば……」とか、「この部分は文章に問題があり、理解できない。改善するためには……」という類の意見が欲しい。

とすると、希望者のみの登録制にしてもよさそうである。そのためには、MLのような仕組みが必要である。できれば、数MB程度のファイルをアップロードできるとなおよい。わざわざそんなインフラを自前で構築するリソースはない。すると、どこかのWebサービスを使うというのが、最も手軽だと思う。

さて、では、どこのサービスを使うかという問題だが、 Google Groups がなかなかよさそうだ。チャットが必要なら、Google Talkが使えるではないか。メールはGmailが便利だ。関係ないが、私はGoogle Readerなしのインターネットというのは考えられないし、ブラウザはChromeだし、検索はGoogleを使う。そもそも、ブログは、もちろんGoogle傘下のBloggerである。

思えば、私はかなりGoogleに依存している気がする。Googleひいきというわけではないのだが、便利なものは便利だ。

話がそれた。MLなどのWebサービスは、問題ではない。本当の問題は、どうやってボランタリーな査読者を集めるかということだ。広い分野から集めたい。とくに、意欲ある学生を集められないものか。結局のところ、プログラミングというのは、学生のうちに学んだ影響が大きい。とすれば、その学生の意見を聞きたいものだ。

金と時間は両立できない。本を書くためには金がいる。時間がなくては本がかけない。どうするか。

2010-01-03

Not the Messiah

BBC iPlayer Console - Not the Messiah

You know... Eric Idle is always a nice chap. Bloody nice.

How to tweet in Hatoyama way

鳩山首相：ブログとツイッター開始 - 毎日ｊｐ(毎日新聞)

鳩山由紀夫首相は１日、インターネット上に自身のブログ「鳩ｃａｆｅ」を開設し、ネット上に短文を発信・表示するサービス「Ｔｗｉｔｔｅｒ（ツイッター）」の利用も昨年１２月３１日から始めた。ブログは週１回程度、ツイッターは１日１回の更新を目指す。現役首相のブログやツイッターの利用は初めて。

ブログには「みなさんと政治の距離を少しでも近づけ、一緒にこの国を変えたい」と抱負を記した。２日のツイッターでは「本当に本人か」との質問に「基本的に私が書き、メールで秘書官付（職員）に送り、ツイッターへの送信はその人がやってくれる」と答えた。

好きに書かせると失言だらけになりそうだからだろうか。

2010-01-02

C++規格におけるoperatorの優先順位の定義方法

ふと、C/C++の規格上は、どのようにoperatorの優先順位が定義されているのかということが気になった。そこで、調べてみた。

operatorはすべて、Expressionの下に配置されているが、どうやら、優先順位を示す表や、文章は見当たらない。しかし、何らかの方法で優先順位を定義しているはずである。

いくら探しても見当たらなかったので、何気なくふと、Grammar summaryを見たところ、なんと、Sytax Notationの形で、優先順位が定義してあった。

たとえば、

expression:
    assignment-expression
    expression , assignment-expression

となっている。では、assignment-expressionの定義はどうか。

assignment-expression:
    conditional-expression
    logical-or-expression assignment-operator initializer-clause
    throw-expression

なるほど、ではlogical-or-expressionはいかに。

logical-or-expression:
    logical-and-expression
    logical-or-expression || logical-and-expression

このように定義されているのである。ちなみに、primary-expressionは、( expression )となっている。これで、括弧も定義されている。

なるほど、面白い定義のしかただ。

この方法は厳密だが、人間にとっては分かりにくい。C++0x本では、分かりやすく表にしようと思う。

ちなみに、この定義を見て始めて、Nicolai Josuttisの、Object-Orientend Programming in C++での、operatorの優先順位の表の意味が分かった。表が、濃い線と薄い線を使い分けているのは、そういう意味だったのか。ちなみに、この本は、C++の入門書として最適である。日本語に訳されていないのだが。

C++0x本では、規格に書いてあるSyntax Notationを用いようと思っている。他のパーフェクトシリーズは、【】なども駆使した、独自のSyntax Notationを編み出しているようだが、私は、規格に従おうと思う。ただし、規格にあるすべてのSyntax Notationは出さない。あくまで、個々の文法を説明するだけに留める。

吹いたｗｗｗ

パソコンの環境設定

大阪府の電子入札や電子申請に使う端末には、「Internet Explorer 6 SP3」「Internet Explorer 7(以下 IE7)」「Internet Explorer 8(以下 IE8)」並びに「Windows XP SP3」「Windows Vista(以下 Vista)」「Windows 7」を使用しないでください。

何を使えというんだ、何を。

しかも、ある特定のバージョンのJAVAに依存しているらしい。セキュリティーホールがあるバージョンだ。

しかし、JAVAってバージョン間の互換性の問題を度々引き起こしている気がする。JAVAの規格が悪いのか、Sum Microsystemsの実装が悪いのか、プログラマが悪いのか。

そもそも、JAVAの理念というのは、ハードウェアを意識しないで実行出来ることではなかったのだろうか。Javaアプレットは、あんまりいい話を聞かない。

各ブラウザのvideo対応が出揃った

Opera Core Concerns - (re-)Introducing <video>

Operaもvideo要素の実装に本腰を入れ始めたようだ。Operaの実装は、GStreamerを使う。

ただし、Windows版のOperaは、GStreamerを独自に改変したものを使っている。これは、Ogg/TheoraとWAVE PCMしかサポートしていない。彼らは、オープンなOgg/TheoraこそがWebの標準であるべきだという意見らしい。

さて、これで、各ブラウザの<video>対応が、出揃った。

FirefoxとOperaは、Ogg/Theoraをサポートする。Firefoxも、GStreamerを使うという話がある。

Safariは、QuickTimeを使って、動画を再生する。ただし、QuickTimeは、皆知っているように、最悪だ。

Chromeは、ffmpegのコードを使っている。これは、かなり広範な動画をサポートできる可能性がある。

video要素なら、Chromeを使うべきである。

しかし、Ogg/Theoraという、画質の最悪な動画が、Webの標準になろうとしているのは、あまりいいことではない。これではFlashやSilverlightに勝てない。

C++0x本：図と表について

本の品質を良くするために、どうか意見をコメントしてもらいたい。

すでに発行されているパーフェクトC#やパーフェクトJavaを見ると、図や表がふんだんに使われている。実に贅沢な本である。まさかこの本の原稿は、MicrosoftのExcelで書いたのではあるまいか。

一体、図や表は、それほど分かりやすいだろうか。私は、表に細かい文字でびっしりなにやら書いてあるのを見るのが嫌いである。見ているうちに、行や列を見間違えてしまうこともよくある。確かに、図や表は一見してかっこいいし、分かった気になれるが、実は全然理解していないのである。

たしかに、pointerを解説するとなれば、objectを参照するpointerの図のようなものがあった方が、分かりやすいとは思う。また、C++0xとは直接関係ないが、双方向リストというデータ構造がある。双方向リストを解説するには、やはりそのような図が欲しい。とはいえ、演算子をすべて表でならべるというのは分からない。かりに優先順位などを表現したいとしても、たとえば優先順位の高い順番に解説していくという方法もあるではないか。

図や表を使えば、紙面の削減になるのかもしれない。しかし、仮にそうだとしても、理解しづらい方法でページ数を多少削減するなどということは、断じて許容できない。

一体、ニッポン人の図表好きはなぜなのだろう。私は、ソフトウェアの仕様書を、すべてExcelで書いている製品という話を聞いたことがある。一体、何が彼らを図表へと駆り立てるのであろうか。

有名な洋書の参考書をみても、図表をこれほどふんだんに用いているのはまれである。だいいち、そんなに高度な印刷技術を使っていない。もし、日本のパーフェクトシリーズを、海外で出そうとしたら、本の値段は、一桁高くなるはずである。それぐらい、日本の製本技術は優れている。

私は、図表の乱用はやめようと思っている。どうしても必要な場合に限り使うことにしようと思う。結果として、私の本には、図表はあまり出てこないと思う。どう思うだろうか？

本の品質を良くするために、どうか意見をコメントしてもらいたい。

C++0x本：実装依存について

本の品質を良くするために、どうか意見をコメントしてもらいたい。

私の書く予定のC++0x本は、言語仕様を解説する本である。特定の実装（例えばVC++やgccなどのコンパイラ）や環境（WindowsやLinux、組み込み系など）について解説するものではない。

ところが、世の中には、どうしても書かなければならない、デファクトスタンダードとなっている事項が存在する。

たとえば、registerやinlineは、ほとんどのコンパイラで、無視される。しかし、この機能が実装されていないわけではない。この手の仕事は、コンパイラの方が、人間より優秀なので、無視するだけなのだ。C++が設計された当時は、まだコンパイラの技術が貧弱だったので、こういう機能が役に立ったこともある。無論、これは規格の範囲外である。

ところが、もしこれを解説しない場合、「そうか！　registerやinlineを使えば早くなるのか！　さっそくどんどん使おう」などと、早合点するものが現れないとも限らない。no-opだから、実質は問題ないともいえるが、このような誤解を生むような本は書きたくない。

たとえば、exportは、ほとんどのコンパイラが実装していない。実際、標準化委員会でも、多くの者が、exportは失敗だったと考えている。これはあくまで、個人個人の考えである。標準化委員会としての意見ではない。結局、exportは、inclusion modelとseparation modelの両方をサポートしようとしたために、規格に入ったのだ。

exportについても、このことを、言及しておかなければならない。

たとえば、整数のオーバーフローは実装依存である。しかし、現実のコンピューターのアーキテクチャが、ほぼすべて、2の補数表現を用いている現状を知らなければ、「なぜ整数のオーバーフローが実装依存であることに注意しなければならないのか」ということが、理解できない。（ちなみに、atomic型の整数は、2の補数表現であることが規格で保証されている）

つまり、規格書の目次にそって解説するといえども、規格書の翻訳ではないので、実装依存の事を、完全に無視するわけにも行かないのである。ではどうするか。

思うに、必要最小限の、実装依存の事で、規格を理解する上で、特に知っておくべき事は、書くべきだと思う。ただし、それが実装依存の話であると分かるように、枠線で囲むだとか、インデントするだとか、印刷の際に、表現を変えて、通常のドキュメントとは違う文章であることを、明らかに分かるようにすべきだと思う。

どう思うだろうか？

本の品質を良くするために、どうか意見をコメントしてもらいたい。

2010-01-01

conversion functionの謎

template < typename T >
void f(T x)
{
    x = 1 ;// Error at VC
} ;

int main()
{
    int x = 0 ;
    f(std::ref(x)) ;
}

あれ？　これってVCだけかな。

規格を読んだが、どうもこのコードが通るような記述は載っていない。ということは、エラーが正しいのか。

ということはだ、C++0xのstd::refって、使えないんじゃないか。関数オブジェクト限定か？

天才だ

とある電気系出身者のいんでっくす

この人は頭がいい。

C++0x本：C++03からの差分をどうするか

本の品質を良くするために、どうか意見をコメントしてもらいたい。

私の執筆する予定のC++0x本は、一体どのように記述すべきだろうか。というのは、既存のC++03ユーザーを考慮するべきか、それとも、あくまで言語として解説すべきか

たとえば、referenceである。referenceの説明は、どちらがいいだろうか。

案１：referenceには、lvalue referenceと、rvalue referenceがある。この二種類のreferenceは、ほぼ同じものである。

案２：C++0xには、rvalue referenceが付け加えられた。従来のreferenceは、lvalue referenceと呼ばれる。この二種類のreferenceは、ほぼ同じものである。

私の本の対象読者は、C++03をある程度知っている者である。とすれば、C++03からの差分で説明すれば、わかりやすい。

しかし、今はそれでいいとしても、C++0x規格が発行されてから数年たてば、新しくC++を学ぶ者が現れるはずである。そのとき、大昔のC++03の差分で説明されても、意味がわからないに違いない。

それに、純粋に言語を解説するとなると、C++03からの差分というのは、どうもよろしくない。

ゆえに、私は、このような差分を使った説明を書かないことにしたい。

どう思うだろうか？

また、ためしに専門用語の名詞を英単語で書いてみた。もちろん、あくまで日本語なので、「二種類のreferences」とはならない。referenceでいい。

あけおめ、ことよろ

私は言語が好きである。日本人なら誰でも、「あけおめ、ことよろ」の意味が分かる。これは実に興味深い。

結局、私の興味は、言語にあるのだろう。それが自然言語であろうと人工言語であろうと、

今年、私はC++0x本の執筆に取り掛かる予定だ。入門書ではない。言語仕様を厳密詳細に解説する本だ。今年中に完成するかどうかは、分からない。おそらくは、今年中には完成しまい。しかし、私は急ぐつもりはない。私は真に優れた本を世に行いたいのだ。

どうかコメントが欲しい。このブログを読んでいて、C++0xの本を待ち望んでいる者は、どうか、本の執筆案の記事に、意見をコメントして欲しい。

さて、年越しそばを食べようと準備をしたのだが、うっかり寝てしまった。目がさめたので、そばをゆでた。とり肉とニシンが両方入った、不思議なそばができあがった。うまい。

今年は私にとって、やりがいのある年になるだろう。私の生活がどうなるかは、依然として分からぬが、そんな私事はどうでもいい。二旬にして九食らうのみだとしても、気にしない。まあ、適度な運動はするつもりなので、最低限、飯だけはしっかり食べる予定だが。第一、飯を喰わなければ頭も働かない。

子思立節

子思居於衛、縕袍無表、二旬而九食、田子方聞之、使人遣狐白之裘、恐其不受、因謂之曰、吾仮人遂忘之、吾与人也如棄之、子思辞而不受、子方曰、我有子無、何故不受、子思曰、伋聞之、妄与不如遺棄物於溝壑、伋雖貧也、不忍以身為溝壑、是以不敢当也。

この漢文通りに生きていけたら高潔だが、でも、誰か狐白の裘を送ってくれないかな。現実問題として、生きていくには、些少の金が入る。優れた小説には奴隷制度が必要不可欠というのは、村上春樹の言だか、さらにネタ元があるのかは知らないが、そのとおりだと思う。奴隷制度の倫理上の問題はさておき、日常の労働から免除されて、あるひとつの学問を専修する人間がいてしかるべきだ。奴隷というのは、無論、現代の倫理にそぐわないので、パトロンというのはどうか。

まあ、理想だが。

縕袍無表といえば、文字通り、一番分厚い外套のファスナーが壊れて、防寒着として意味をなさなくなってしまったのだった。