2010-02-28

理想主義者には金がない

Coding Horror: Cultivate Teams, Not Ideas

アイディアに価値はない。実行にこそ価値がある。

金がない。絶望的に金がない。しかし問題は、今、サラリーマンとなることは出来ないのだ。私は今、C++0xの本を執筆しなければならない。それには、時間が必要だ。

私は多芸ではない。学校をやめ、仕事をやめ、貯金を食いつぶしながら、ただひたすら学ばなければ、いまのC++の知識を得られれなかった。さて、どうするか。

金があればできる最適化というのは、たくさんある。たとえば、WQXGAのディスプレイを二台買えば、効率が上がるだろう。あるいは、SSDを買ってRAID0を組めば、効率が上がるだろう。この手の最適化は、必須ではないが、あれば、効率があがるのだ。

実際、私は、生活していかなければならない。残念なことに、この日本で生きていくためには、少なからず金がいる。一体どうすればいいのか。

私に金のない理由は、わかっている。私は作業が嫌いなのだ。私は理想を考えるのは好きだが、現実の諸問題に取り組むのは、嫌いだ。私は理想主義者なのだ。

たとえば、今度のプログラミング雑誌の創刊とて、私は、一ライターとして関わっているだけである。この雑誌をつくるにあたって設立した、ロングゲートという会社には、全く関わっていない。会社経営は、非常に現実的で、面倒な作業である。

ロングゲートという会社は、高橋晶さん、梶本裕介さん、DigitalGhostさん、そして、もう一人、私は面識のない人が関わっている。

ここ最近の彼らは、非常に忙しそうであった。会社設立のための手続きなどが、相当面倒らしい。

さらに、今は、雑誌の組版や印刷に奔走している。

ましてや、めでたく雑誌を発行できても、こんどは、営業にいかなければならないだろう。これも、また難しい。

つまり、現実には、根本的な問題の他に、必要な作業が多すぎるのだ。これは、理想主義である私には、耐えられない。だから、ライターの身分で参加しているのである。

実際、私は理想主義者である。私が何かを学ぶときは、必ず、一次ソースをみる。つまり、規格書だ。結局、それが一番、手間がかからないのだ。二次ソース、三次ソースは、間違っている可能性がある。一次ソースが間違っているのなら、そもそも、正しい答えなどないのだ。

この私の性格は、C++を学ぶにあたっては、非常に都合が良かった。結局、C++をまともに解説している、二次ソース、三次ソースはない。ましてや、C++0xとなると、一次ソースしかない。

そして、私は、二次ソースであるC++0xの参考書を書く。結局、これが、理想主義者としての、私が納得できる仕事なのだ。

金は頭が痛い問題だ。結局、私の理想を押し通そうとしたら、フリーのライターというのが、まあ、ある程度は、理想を実現出来そうな線だ。しかし、現実に、今、カネが必要なのを、どうすればいいのか。

gcc4.5がVariadic TemplateのDependant name resolutionに対応していない

追記:これはgccのバグではなく、規格上の問題であった。

Dependant Nameは、Point of instantiationに解決される。つまり、

// point of difination of f
template < typename T >
void f(T x) { g(x) ; }

// point of difination of g
template < typename T >
void g(T) { }

int main()
{
// point of instantiation of f.
// also g.
        f(0) ;
}

このコードは、well-formedである。たしかに、fのpoint of difinationからは、gという名前は見えない。しかし、g(x)という式は、type-dependant expressionであるので、Dependant nameである。したがって、gのname lookupは、point of instantiationに行われる。すなわち、mainの中である。mainでは、gはすでに宣言されているので、問題なくgを使うことができる。

gccはVariadic Tempalteをサポートしていると聞いたので、以下のようなコードを書いてみた。

template < typename T, typename ... Args >
T max( T const & a, T const & b, Args ... rest)
{
        return max( max(a, b), rest ... ) ;
}

template < typename T >
T max( T const & a, T const & b )
{
        return a < b ? b : a ;
}


int main()
{
        max(1, 2, 3) ;
}

ところが、gccは、このコードに対して、エラーを吐いた。しかし、どうもそのエラーメッセージがおかしい。試しに、以下のように書き換えてみたところ、

// 順番を逆にした
template < typename T >
T max( T const & a, T const & b )
{
        return a < b ? b : a ;
}

template < typename T, typename ... Args >
T max( T const & a, T const & b, Args ... rest)
{
        return max( max(a, b), rest ... ) ;
}

これは、コンパイルが通った。明らかに、Variadic TemplateがらみのDependant Nameを、point of difinationで解決している。これは誤りである。

2010-02-27

Adam Savageの失敗

FORA.tv - MythBuster Adam Savage's Colossal Failures

我々はプログラミング雑誌を創刊す

かつては、実に多くのプログラミング雑誌があったものだ。思い返せば懐かしい。雑誌に載っていたバイナリコードを、必死に打ち込んだ日を覚えているだろうか? カセットテープの音で、どのマイコンのデータかをあてる遊びをしたことはあるだろうか。かつては、NHKでさえ、記録テープを放送して、各家庭で録音させることで、マイコン向けのデータをブロードキャストしていたのである。

思えば、時代は変わった。我々のコンピューター技術は進化し、実に便利になった。誰か能く、リアルタイム3Dレンダリングを予想しただろうか。誰か能く、HD動画の、リアルタイムデコードを予想しただろうか。はた、今日のWebの興隆は如何。

コンピューターは進化し、便利になった。しかし、コンピューターをプログラムするのは、依然として、我ら人間である。プログラマである。プログラマが技術を習得すべきソースとなるのものは何ぞや。「ネットで誰かが書いてくれるからググればいい」、それもある。しかし、まとまっていて品質の高いソースは、依然として、参考書と雑誌である。

しかるに、今の雑誌の惨状は如何ぞや。貧弱の極みにあらずや。入門記事は頻繁に書かれている。入門記事は。しかし、はれて入門した後に、何を読めばいいというのだ。入門以上の詳しい内容の記事は、絶えて久しい。

然り。今や、プログラミング雑誌は、風前の灯、風の前の塵である。如何にしてかくはなりはてるや。それには主に二つの理由あり。

ひとつ、雑誌は売れない。

ひとつ、編集者が現代の技術に追いつけない。

Webが主流の今、雑誌は以前ほど売れない。今日のプログラミング雑誌の品質は、絶望的に低い。さらに雑誌が売れない。このネガティブなスパイラルを如何すべき。

我々は信ずる。雑誌の売れざることは、Webの為にはあらざるなり。若者の本離れの為にはあらざるなり。かつて、柳田國男翁云えらく、「最近の若者はダメだ、という言葉は、パピルスにも記されている」と。本の売れざるは、品質の低きが故なり。しかし、どうすればいいのだ。いくら我々が、高度な記事を書いたとて、取り上げてくれる雑誌の無きを如何すべき。

さらばよし。無ければ創るまでだ。我々は、新たな会社、LongGate Co., Ltd.を立ち上げ、独自の雑誌を出版し、以て現状を打破せんことを決意した。日本全国に、くすぶっている有能の同志を募り、記事を発表する場としての、雑誌を提供するのだ。もちろん、我々の雑誌の出版は、単に物理的な紙の本に留まらない。印刷と同等の内容を、電子媒体でも販売する予定だ。 

会社を立ち上げた同志の多くは、C++WG JPのメンバーである。このため、記念すべき創刊号は、C++に特化する。次号以降は、様々なプログラミング言語や技術を、詳細に取り上げる予定である。

ちなみに、創刊号では、多くの同志が、C++0xの具体的なコア言語機能やライブラリBoostライブラリについて記事を書く中、私はひとり、C++の歴史についての記事を書くつもりである。私は、そういう話が好きなのだ。

我々のこの試みは、果たして成功するのだろうか。しかし、我々は日本のプログラミングの未来の為に、是非ともこの雑誌を出版せねばならぬのだ。

2010-02-25

暖かくなってきた

もうすっかり暖かくなってきた。先日まで、分厚い上着なしに表を歩けなかったのだが、もう暑いぐらいだ。三ヶ月ぶりに、下駄や雪駄を履けるようにもなった。

ふと思ったが、和服を普段着にして生活できたら面白そうだ。金があったら、購入を考えてみよう。しかし、和服はどこで売っているのか。そもそも、どうやって着るのか。春夏秋はともかく、冬は寒いのではないのか。

謎だ。

今年も折田先生が京大に出現した

今年も折田先生像が顕現なされました on Twitpic

見てこようかな。

Javascript rules!

なんだか、最後に生き残るのは、Javascriptだという気がしてきた。

はてなブックマークをBloggerに取り込んだ

はてなブックマークエントリー情報取得APIとは - はてなキーワード

はてなブックマークの何が嫌いかといって、画像を使うほど嫌いなことはなかった。ブックマークボタンの画像ならともかく、なぜ、はてブ数を画像でよこすのだ。

ここは、Javascriptの真価を遺憾なく発揮するべき時である。さいわい、はてなのAPIは、JSONPを提供している。

さっそく、はてブ数を、文字列で表示することにした。さらに、はてブコメントを、ブログ内に埋め込んだ。

なかなか、悪くない。

ちなみに、IEはサポートしていない。というより、本来、どのブラウザでも動くべきだ。

JSONPを使いたいが、Operaの挙動がおかしい

http://www.example.com/が、以下のような内容を返すとする。

callback({
    "foo" : "bar"
}) ;

このとき、script要素を動的に生成することによって、same originを回避しつつ、しかもJSONデータをJavascriptから利用することが可能になる。

function callback(data) {}

var jsonp = document.createElement("script") ;
jsonp.setAttribute("type", "application/javascript") ;
jsonp.setAttribute("src", "http://www.example.com/") ;

document.head.appendChild(jsonp) ;
// callback()が呼ばれる。

このテクニックは、JSONPと呼ばれている。

実際のコードでは、HTML5のdocument.headに対応してないブラウザのため、別の方法でhead要素へのDOMを取得しているが、それは話の本題ではないので、省略する。

ここまではいい。しかし、このscript要素は、無駄であるので、できれば、消したい。

document.head.appendChild(jsonp) ;
// callback()が呼ばれる。
document.head.removeChild(jsonp) ;

わたしは予想では、これは動くはずであった。なぜならば、JavascriptによるDOM操作は、暗黙のうちに非同期になってくれたりはしないからだ。ひとたび、appendChild()が呼ばれたならば、DOMに追加され、読み込みが終わり、関連するすべての処理がおわるまで、Javascriptのコードは実行を続けることができないはずである。

これは、時として、ユーザーをブロックする原因にもなるが、この場合は、都合がいい仕様である。

Chrome, Safari, Firefoxでは、私の期待通りに、問題なくcallback()が呼ばれた。

しかし、Operaでは、動かなかった。

Operaでは、callback()は呼ばれるものの、その引数であるdataが、nullになっていた。removeChild()を呼び出さなければ、nullではなく、ちゃんと、JSONオブジェクトを参照しているのだ。

相変わらず、Operaの実装は分からない。最適化のために、script要素がDOMに追加された場合の、その中身の実行のタイミングを遅らせるなどの、妙なことをしているのではあるまいか。

実は、もう一つ、removeChild()を呼び出した場合の不都合が存在した。それは、ブラウザの「戻る」機能を使って、ページを戻した場合、動的に追加したscript要素内のコードが実行されないのだ。これは、すべてのブラウザに当てはまる。

結局、removeChild()を呼び出すのは、諦める事にした。script要素が存在することで、CPU時間やメモリなどのリソースの消費が、目に見えるほど増えることはない。

うはwwwwJSONP最強過ぎwwwwワロタ

たしかにJSONPは動く。しかも便利だ。

しかし、これは、本来、Cross-Origin Resource Sharingで解決するのが、正攻法である。

既存の画像のスケーリングアルゴリズムは、輝度を考慮していない

Gamma error in picture scaling

そもそも、ガンマは1.0じゃないというお話。

相撲終わったな

帰化でもダメ、外国力士「1部屋1人」徹底通達 : 大相撲 : スポーツ : YOMIURI ONLINE(読売新聞)

日本相撲協会は23日の理事会と評議員会で、外国人力士の採用は「1部屋1人」とする申し合わせを徹底させることを決め、武蔵川理事長(元横綱三重ノ海)が各師匠に通達した。

最近、幕下以下の外国人力士に日本国籍を取得させ、空いた枠を使って新たな外国人力士を入門させる例が増えており、事実上の「抜け道」に制限を加える狙いがある。

2002年から適用されている申し合わせ事項では、「外国人力士が在籍している部屋は当該力士が引退するまでは新たに採用できない」と定めている。今後は、外国人力士が日本に帰化した場合でも、原則、この規定が厳格に適用される。

また、2009年度決算も承認され、総収入約139億2000万円に対し、総支出は約135億7000万円。収支差額は約3億5000万円のプラスで、2年ぶりの黒字決算となった。このうち、本場所興行収入を柱とする事業収入は、新型インフルエンザや不況による観客減が響き、前年度から約3億円マイナスの95億8000万円。一方、「国技館改修基金」の拠出金の減少などで支出を縮減したため、収支全体ではプラスに転じた。

また、新たに相撲教習所長に就任した貴乃花理事(元横綱)の提案で、5月の夏場所初日前日に実施される土俵祭を教習所に通う若手力士が見学することも決まった。神事に基づく伝統行事を学ばせる狙い。

もはや相撲に見るべき価値はない。結局、伝統とはいえ、今の相撲と昔の相撲は違う。白洲正子も言っているように、ラジオの登場で、相撲はつまらなくなった。

2010-02-24

イタリアでは、インターネットは違法と相成りました

Official Google Blog: Serious threat to the web in Italy

ご愁傷さまです。

Google Videoに、プライバシーを侵害している動画をアップロードしたアホがいた。、Googleは、警察と協力して、その人間の居場所を突き止めた。

話は、これで終わらない。問題は、Google社員が、Google Videoにアップロードされた動画が、プライバシーを侵害しているとして訴えられたことである。しかも、裁判で敗訴した。

これは、インターネット上のあらゆる情報をホストするサービスが、犯罪であることを意味する。動画サイト、ブログ、掲示板、ソーシャルネットワーキングサービス、ありとあらゆる、テキスト、画像、動画が、プライバシーの侵害に成り得る。本来、プライバシーを侵害したのは、そのコンテンツをアップロードしたものであり、そのコンテンツを、ホストしている者は、要請に応じて削除し、またはそのコンテンツをアップロードしたものに対する情報の提供をすれば、義務を果たしたと言えるのである。EUの法は、明確にこれを言っている。これにより、表現の自由が保たれる。

しかし、ことイタリアでは、ホストするものも、たとえ削除要請に応じ、また捜査に協力したとしても、同罪に処せられる。つまり、イタリアでは、インターネットは死んだのである。

本物の手書き履歴書はつけペンで書け

前回の、手書き履歴書と万年筆が、予想以上に受けたので、本当に履歴書に使えば評価されるかもしれない、真面目でコアな話をする。つけペンである。

結局のところ、一本千円程度のデスクペンも、それほど悪くはない。ただし、わざわざ履歴書を書くためだけに、使い慣れない千円もするペンを買うのは、無駄だとということである。だいいち、万年筆は、上を望めば、値段にキリがない。実は、そんな事をしなくても、低価格で最高の道具は、手にはいるのである。良い筆記具で履歴書を書くことが評価につながると考える人は、続きを読むと良い。

硬筆というのは、様々である。単純にインクを使う硬筆用のペンだけでも、ボールペン、フェルトペン、万年筆、つけペン等がある。これらは、それぞれ特性が違っており、単純に良し悪しを比較することはできない。しかし、いまなお最高の硬筆用のペンは、なんといっても、つけペンである。

つけペンといっても、大部分の読者諸君は、全く実感がわかないことであろうと思う。おそらくは、「漫画家が絵を描く時に使うと聞く、アレのことか?」程度の感想しか出てこないはずである。しかし、昔から、つけペンは、硬筆用として、最高のペンであったし、今もって、そうである。硬筆の字がうまいことで名の知れた習字の先生で、つけペンを使ったことのない者は、まずいない。というより、およそ硬筆のプロと名乗るぐらいなら、いろんな種類のペンを使えるはずだが。

まず、道具を揃えなければならない。つけペンには、三種類の道具がいる。つけペンのペン先(ニブ)、ペン軸、インクである。

まず、ペン先である、これには、実に様々の種類がある。漫画家は、よくGペンを使うし、描きたい線に応じて、ペン先を使い分ける。しかし、日本語の文字を書く時には、たいてい、さじペンか日本字ペンが使われる。値段は、非常に安い。ひとつあたり、だいたい、70~80円である。三つで二百円程度。グロス単位で買えば、もっと安くなるだろうが、字を書く際には、漫画家ほど大量に使い潰すということはない。私は、タチカワか、日光ブランド(日光は潰れて、今はタチカワに吸収された)の日本字ペンを使っている。

次に、そのペン先をさして使う、ペン軸である。これも、数百円で売られている。ペン軸は、太さや重さなど、好みがあるので、何が良いということもない。私は、いろいろ試したあげく、タチカワのT-36を使っている。

最後に、インクである。これも、非常に安い。たとえば、パイロットの製図用インクは、30mlで五百円である。私は、いろいろ試したあげく、開明墨汁に落ち着いた。

これらは、ちょっと大きな文房具屋か、画材店に売っている。身近なところでは、アニメイトで売っている。そう、あのアニメイトは、画材店でもあるのだ。アニメイトは、字を書くというより、絵を描くための画材を取り扱っているのだが、たいてい、つけペン関連の商品も置いている。

さて、以上で、つけペン習字に必要な道具は、すべて揃った。これを考えれば、千円以内でつけペンを始めるのに必要な道具はすべてそろうということである。そしてこれは、およそ望みうる最高最良の道具である。

よく、弘法は筆を選ばずという。しかし、弘法大使は、良い字を書く時は、筆を選んでいたとも、言われている。実際、我々は、物事が上手くいかない理由を、自分の能力ではなく、道具のせいにしがちである。しかし、世に名高い、硬筆習字のプロも、上に挙げたような道具を使っているのである。

すなわち、この道のプロですら、ひとつ百円に満たないペン先、一本数百円のペン軸、一瓶数百円のインクを使っているのである。たかが千円で、プロと同じ道具を揃えられるのである。もはや言い訳はできない。デスクペン一本分の値段、千円で買い揃えた、君の道具は、この世で最高の道具である。

良い筆記具で履歴書を書くことが、評価されると信じている輩は、つけペンを使うといい。わずか千円足らずで、プロと同じ、文句のつけようがない、最高の道具が手に入る。

さて、こんなことを書いていると、本物のつけペンマニアからお叱りを受けるので、最後に、つけペンの価値について書く。

大部分の者は、誇るほど字がうまくはない。それでもつけペンを使う価値があるだろうか。もちろんある。

つけペンに関する誤解がある。曰く、インクで手が汚れる、頻繁にインク壺の中にペンを突っ込まなければならない、そもそも使いづらい。などである。これらは、誤解である。

インクで手が汚れるのは、使い慣れていないだけである。私も、最初はインクで手が汚れたものだが、今は、全く汚れることがない。

つけペンのインクは、予想以上に持つ。一度ペンにインクをつければ、驚くほど多くの文字を書くことができる。

使いづらいというのは、少しあるかもしれない。というのも、ペンにインクをつけたまま、書かずに五分ほど放置するだけで、インクが乾いてしまい、書けなくなってしまう。この場合、一度ペン先を洗わなければならない。私はいろいろ考えたあげく、手元に水とティッシュを常備するようにした。

つけペンの利点であるが、実に多くある。第一に、書きやすい。ボールペンのような不自然な力を入れずにかけるし、ボールペンのようにペンを不自然に立てて書く必要もない。好きなインクを使える。万年筆には使えないような渋いインクでも、つけペンには、全く問題がない。ペン先は安くて使い捨てるので、万年筆のように気を使う必要もない。

結論としては、つけペンは、安価で最良の道具が手に入る、遊び心満載の、すばらしい筆記具である。是非とも使うべきだ。

今日、面白かった文章二つ

あるVimmerのブログ: 諸君 私は補完が好きだ

諸君 私は補完が好きだ
諸君 私は補完が好きだ
諸君 私は補完が大好きだ

手動補完が好きだ 自動補完が好きだ インテリセンスが好きだ 部分マッチが好きだ
シェルが好きだ 予測補完が好きだ オムニ補完が好きだ

Vimで Emacsで zshで
Visual Studioで ATOKで Eclipseで

このプログラム上で行われる ありとあらゆる補完作業が大好きだ

FBI Investigating High Schools Alleged Webcam Spying - HotHardware

According to district spokesperson Doug Young, the school is vaguely aware it made a booboo. ""There was no specific notification given that described the security feature," Young said. "That... was a significant mistake."

Wearing one black sock and one blue sock is a mistake. Wearing one black sock, one white sock, and two different shoes when you're scheduled to give a presentation to the company CEO is a significant mistake. What Lower Merion has done falls under the category of "unbelievable world-class stupidity."

行政区の広報官をであるDoug Youngの発表によれば、学校は批判が起こるであろうことは、薄々気づいていたようである。「このセキュリティ機能にたいする広報は、特に行われていませんでした」とYoungは語る。「これは・・・・・・重大な間違いでした」

片足に黒い靴下、もう片足に青い靴下を履くのは、間違いである。片方は黒い靴下で、もう片方は白い靴下、しかも左右異なるバラバラの靴を履いて、会社の社長の前でプレゼンをするのは、重大な間違いである。Lower Merionの行ったことは、「信じがたい世界級のドアホ」である。

名前隠しと名前探し

目次案を更新。

name hidingとname lookupについて、いろいろと考えてきたが、結局、この案でいいのではないかと思う。

name hidingを、「名前隠し」とすることは、悪くない案であると思う。少なくとも、名前隠匿のように奇妙な名前ではない。基本的に、漢字が多く並ぶような訳語は、理系の研究者や技術者にありがちの、悪い訳語である。しかるに、名前隠しは、表現が難しくないばかりか、直訳とも一致する。

では、name lookupはどうか。名前調べという意見が出ているが、果たしてこれはどうだろう。まあ、悪くない。私なら、名前探しの方が、いいと思う。どちらでも、問題はないと思う。

ほかにも気にくわないところがあるが、単項演算子、二項演算子のたぐいは、おそらく、どうしようもないだろう。他に何があるというのか。一引数演算子、二引数演算子か。馬鹿げている。ユーナリーオペレーター、バイナリーオペレーター、やりすぎである。だいたい、unaryというのは、日本人にとって馴染みがないし、binaryといえば、思い浮かべるのは、二項や二進といった類の意味ではない。無理だ。

追記:やはり、名前探索でもいい気がしてきた。

手書き履歴書と万年筆

手書きの履歴書は、未だに広く行われている。しかも、甚だしきは、「万年筆を使うと評価が高い」という思い込みの元、わざわざ、千円程度のデスクペンを買ってきて、それで書くバカがいることである。

ここでは、彼らが万年筆を使うの愚を直接言わず、もし、履歴書を万年筆で書くことが評価される企業があるならば、その人事はどのようなものかという、仮想の物語をしたいと思う。

万年筆で履歴書を書くことが、評価されるとしよう。では、その会社の採用の評価手順は、どのようなものだろうか。

まず、万年筆である。詳しくは後述するが、千円程度で売っているデスクペンは、本物の万年筆ではない。あれは鉄筆である。たとえ万年筆が評価されるとしても、あのようなデスクペンを使う時点で、すでに評価はマイナスである。

次に、インクである。まさか、黒インクを使っていたりはすまいか。せっかくの万年筆に、黒インクなどを使っていては、評価はマイナスである。まず間違いないのは、ブルーブラックである。もちろん、古典的な製法で作られたブルーブラックインクでなければならない。現在出回っている。染料インクのブルーブラックもどきでは、評価はマイナスである。

さて、めでたく書類選考が通り、面接に望んだとしよう。ここからが問題である。履歴書が万年筆で書かれているかどうかが、評価の対象になるぐらいの企業である。面接は、よほどの万年筆マニアの人事担当が行うに違いない。果たして、そのマニアを説得できるだろうか。

面接の次第はこうである。まず人事担当は、履歴書が万年筆によって書かれていることをほめるだろう。ここからが問題だ。人事は君に、どの万年筆を使ったかを訊ねてくるはずである。ここでまごついてはいけない。最も避けるべきは、「えーと、よくわかんないんですけど、文房具屋で売ってた、千円程度のデスクペンってやつで」などと答えることである。評価は最低となる。

無難なのは、一万円前後の万年筆である。たとえば、PILOTのCUSTOM 74とか、プラチナ萬年筆の#3776あたりを答えれば、まあ、間違いはあるまい。人事は君を、凡人とみなして、面接を続けるだろう。

ここで評価を上げるのは難しい。というのも、万年筆は高ければ高いほどいいというものではない。それに、実際の書き味云々よりも、ブランド名で売っている万年筆もある。たとえば、殿様商売をしているモンブランのごときは、もはや製造中止となった、古い万年筆を使っている方が、評価が高くなるはずだ。

個人製作の万年筆とか、ニブに独自の加工を施した万年筆を使っていれば、評価はうなぎのぼりかもしれない。

もし、鉄筆がすばらしいと思うのであれば、ロットリングのような、製図用に名の知れたブランドの万年筆を挙げるのも、ひとつの手である。しかし、その場合、君は実際に、手描きの製図に優れていなければならない。

ここで、評価を上げる、意外な万年筆がある。PILOTのペチットや、プラチナのプレピーである。これらは、数百円の萬年筆であるが、評価が高い。しかし、この万年筆を使っていることで評価されるには、さらにマニアであることが求められる。このような万年筆を挙げた際に、理想的でスキルの高い人事が訪ねることは、決まっている。曰く、「ほほう、実は私もそれを使っていましてね。で、どのインクを使っているんですか」と。

ペチットやプレピーが人気である理由は、安いことだ。単なる万年筆以上にこだわるマニアが、よく使っている理由というのは、すなわち、インクである。ペン自体が安いので、渋いインクを使って詰まらせてしまっても、全く問題ないからだ。しかし、インクのマニアというのは、万年筆のマニアより、タチが悪いのである。

ここで評価される答えは、「Private Reserveのあのインクや、Noodler'sのこのインクを使っています」などという答えだ。ここでモンブランのインクと答えた場合、自分が単なるブランドでインクを選んでいるのではなく、実際にモンブランのインクの色あいが好きだから選んだのだと、よどみなく言えなければならない。ましてやモンブランは、最近、全面的なリニューアルを実施した。新旧ふたつのインクの違い、はては、インク瓶の形状の違いまで論じて、始めて評価してもらえるのである。

また、セーラーの極黒のような、カーボンインクを使っていると答えるのも、ひとつの手である。あるいは、最近パイロットやセーラーから出ている、染料系の鮮やかなインクも、もしその価値を説得できるだけの理由があるなら、答えてもいいかもしれない。

独自の色を調合してもらいました、あるいは、自分で調合しましたなどと答えるのは、相当の経験が必要である。素人の及ぶところではない。

しかも、これらの企業は、筆耕では断じてあり得ない。基本的に、彼らプロの筆耕は、あまり万年筆にこだわることはない。ましてや筆耕は、いかにクセを出さずに、普通の字を活字なみに普通に書くかが求められる仕事である。第一、硬筆といえば、万年筆も、もちろん使うが、やはりつけペンである。

結局、筆耕でないとするならば、ここまでの万年筆マニアを評価する企業とはなんだろうか。モンブランか(笑)

Togetter(トゥギャッター) - まとめ「手書き履歴書の実態」

追記:なんだか予想以上に受けているので、つけペンに関する話を書いた。
本の虫: 本物の手書き履歴書はつけペンで書け
良い筆記具で履歴書を書けば、評価につながると考える人間は、このリンク先を読んで、つけペンを使うべきである。

これは、笑い話に思えるかもしれないが、履歴書を万年筆で書くと評価されるという不思議な話が、世に出回っているのである。軽く検索をかけてみた結果、かなりの新卒が、これを信じている。

万年筆を評価する人間とは、どういうものであるかを示したのが、この文章である。万年筆を評価する人事である以上、最低限、このくらいは万年筆にこだわらなければならないのである。この文章は、万年筆のマニアにとっては、別に笑い話ではない。常識である。むしろ、かなりレベルの低い話である。本物の万年筆マニアは、この記事での万年筆に対する記述のレベルが低いと笑うことはあっても、この記事の万年筆の記述が、非現実的にやりすぎだと笑うことはないはずである。本物の万年筆のマニアは、もっともっと些細なことに、こだわるものである。

むしろ、この程度ほども万年筆を知らず、しかも履歴書が万年筆で書かれているかどうかを気にするような企業は、例外なくブラックであるので、避けた方が良い。つまり、就活をしている人間に、本来不必要な、デスクペン一本分の金銭的負担を強いるブラック企業である。

2010-02-23

括弧は演算子か?

括弧は演算子であると思う。基本的に、expressionは、すべて演算子である。とすれば、括弧だって演算子のはずだ。

でも、リテラルって演算子かな?

C++0x本:訳さなくてもいいもの

やや修正した目次案をアップロードしました。査読者様はご確認ください。

目次案の見直しをしている。あえて訳す必要のない言葉というものもある。たとえば、static castだ。これなどは、訳す必要が感じられない。結局、static_castというキーワードなのだから。

もし仮に、静的キャストと訳したとして、reinterpret castはどうするのかという問題がある。再解釈キャストか。馬鹿げている。

Simple type specifierとElaborated type specifierが問題だ。これは、Simple型指定子、Elaborated型指定子としているが、どうもこれでは、問題がある。しかし、単純に、単純、複雑などと訳してしまうのも、意味上、問題がある。

name lookupだが、今は、名前参照で統一している。

Class member name checking attributesは、非常に難しい。結局、そのまま日本語に直訳するしかないだろう。

candidate functionsは、直訳して、候補関数にすることにした。viable functionsは、呼び出し可能な関数、best viable functionは、最適な関数とした。

今もって、悩ましい問題がある。name hidingだ。これは、文字通り、明示的な宣言により、名前が隠れるという仕様である。

// グローバル変数
int x ;

void f()
{
    int x ;// #1 ::gを隠す。

    x ;// f()の中のx

    {
        int x ;// #2 #1のxを隠す
        x ; // #2のx
    }
    x ; // #1のx
}

このように、名前が隠れることを、name hidingという。

とはいっても、名前隠匿などという名称が、果たして受け入れられるだろうか。悩ましい。

Javascriptに強い静的型付けが欲しい

前回、私は底抜けにマヌケなミスを犯してしまった。あるNodeのオブジェクトが、ELEMENT_NODEであるかどうかを比較するのに、

function Foo(node)
{
// 間違い。
    if ( node == node.ELEMENT_NODE ) ;
// 正しくは、
    if ( node.nodeType == node.ELEMENT_NODE ) ;
}

などというコードを書いてしまった。

Javascriptには、緩い暗黙の型変換をせずに、同じかどうかを比較する演算子、===が存在する。しかし、この場合、役には立たない。なぜなら、型が違う場合、単にfalseを返すに過ぎないのだ。実行時エラーにすらならない。

できれば、このようなミスを防ぐために、強い静的な型付けがほしい。つまり、C++でいう、enumのような機能があればよい。そして、型が違った場合、コンパイルエラーになるようにしてほしい。

しかし、どうも、強い静的な型付けを導入してしまうと、Javascriptの理念に反するような気がしてならない。

不思議だ。私はC++によるバイアスを受けていると言える。とすれば、強い静的型付けは、諸手を上げて歓迎すべきものである。にもかかわらず、Javascriptに強い静的型付けが入ることに、ものすごい違和感を感ずる。

たとえば、クラスという機能もそうだ。Javascriptに、言語機能としてのクラスを導入してしまうと、どうもそれは、Javascriptの理念に反するような気がしてならない。

ところで、私が、Javascriptの理念上、どうしてもなくてはならないと感ずる機能は、letである。Mozillaの拡張機能である、block scope letが、どうしても欲しい。letがあれば、コードが非常に読みやすくなる。

Google Readerの横幅を制限しない方法

私は、多くのブログをGoogle Reader経由で読んでいる。しかし、Google Readerは、このように、max-widthを650pxに固定している。これは、左側のパネルを閉じれば、解除される。私は、このような制限を好まない。

私は、1920x1200のディスプレイを使っているのである。もし、文字の幅が広すぎて読みにくいというのであれば、自分でブラウザのウインドウサイズを調節する。サイト側で固定されたmax-widthのお世話になる必要はない。

そこで、Google Readerの、この制限を、extensionで書き換えてやろう。

#entries .entry-body, #entries .entry-likers
{
    max-width : 100% !important ;
}

これでよし。

あるchromeのextensionを作りたいが、効率のよい実装方法が分からない

dilbert.comというサイトがある。これは、Scott Adamsの手による、非常に有名なマンガである。一日一作、欠かさず更新される。

私は、このマンガが好きであるが、今まで、まともに読んではいなかった。理由は、読むのが面倒だからだ。

面倒というのはどういうことか。それは、このマンガの画像が、縮小版で提供されているのである。それゆえ、実に読みにくい。原寸大で表示するためには、公式サイトから、ルーペのアイコンをクリックしなければならない。原寸大画像のURLが、新しいタブで開かれる

このサイトは、もちろん、フィードを提供している。しかも、ちゃんとimg要素で画像が埋め込まれているフィードである。しかし、そのURLは、画像の縮小版である。

縮小版で、読めないということはない。しかし、非常に劣化していて、読みにくい。そこで、真にマンガを楽しもうと思ったならば、フィードから公式サイトに飛んで、さらに原寸大画像のURLを開かなければならない。こんな短い画像ひとつを閲覧するために、みっつもタブを開かなければならないのは、苦痛である。私は、原寸大の画像を、一覧表示して、だらだらと読みたいのだ。ひとつの画像のために、タブを三つも開くのは、時間の無駄である。

dilbert.comのフィードは、かなり前にGoogle Readerに放り込んでいたが、上記の理由で、まともに読んではいなかった。さて、手間を軽減するために、手間ひまかけるのが、プログラマのすることである。幸い、今日は朝早く目覚めて、たまたま面白いDilbertのマンガを読んだので、手間をかけようという気分になった。

実は、dilbertのマンガの画像は、単純なURL直リンでアクセスできるし、公式サイトは、べつにURLを隠そうともしていない。原寸大表示をすれば、その画像のURLを、新しいタブで表示するのである。URLは、以下の通りである。

原寸大URL:http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/80000/3000/000/83078/83078.strip.zoom.gif (1000×311)
公式サイトの縮小URL:http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/80000/3000/000/83078/83078.strip.gif (640×199)
フィードのURL:http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/80000/3000/000/83078/83078.strip.print.gif (560×174)

見ての通り、規則性のある、非常に単純なURLである。単に、URLの最後を、strip.zoom.gifに置き換えればよいのだ。だらだらと流し読みするには、Google Readerが最もふさわしい。ならば、Google ReaderのDOMを書き換えてやればいいのではないか。そのようなextensionは、Chromeならば、簡単につくれる。

単純にURLを置換するコードは、5分とかからずに書ける。

(function()
{
        // query for all img element in the Google Reader's items.
        var list = document.querySelectorAll("div.item-body img") ;
        
        for ( var i = 0 ; i != list.length ; ++i )
        {
                var node = list.item( i ) ;
                var src = node.getAttribute("src") ;

                // if img element is for dilbert cartoon URL.
                if ( src.match(/http:\/\/dilbert\.com/) )
                {// replace it to bigger image URL.
                        node.setAttribute("src", src.replace(/strip\..*\.gif/, "strip.zoom.gif") ) ;
                }
        }
})();

これは動く。しかし問題は、Google Readerは、非常に動的なサイトだということだ。DOMが、ユーザーの操作によって、後から後から、際限なく追加される。Google Readerの読み込み時に、一度置換すればいいというわけではない。

かといって、タイマーを使うのも、無粋である。img要素が挿入された時だけ呼び出されるEventがあればいいのだが。

DOMNodeInsertedを使ってみたが、どうも上手くいかない。これは、説明にあるように、childだけで、孫には働かないのだろうか。DOMSubtreeModifiedや、DOMNodeInsertedIntoDocumentも、どうも上手くいかない。なぜだろう。このようなハンドラを書いたのだが。

var listener = {
handleEvent : function( event )
{
        var target = event.target ;

        if (    target == target.ELEMENT_NODE
                && target.nodeName.toLowerCase() == "img"
            )
        {
                var src = target.getAttribute("src") ;
                console.log(src) ;

                /* if img element is for dilbert cartoon URL. */
                if ( src.match(/http:\/\/dilbert\.com/) )
                {/* replace it to bigger image URL. */
                        target.setAttribute("src", src.replace(/strip\..*\.gif/, "strip.zoom.gif") ) ;
                }
        }
}
} ;

Google Readerのスクリプトをいじるしかないのだろうか。しかし、それは、Google Readerの実装が変わると、動かなくなる恐れがある。

追記:target.nodeType == target.ELEMENT_NODEとすべきところを、target == target.ELEMENT_NODEとしてしまっていた。道理で動かないわけだ。

今日面白かったDilbert

Dilbert.com

Presenter、「このパワポをメールで送れば、五分で済みます」
Presenter、「でも、ここでこうやって、ゆっくり読み上げながら、一時間、ムダにすることにします」
Presenter、「まーずーはーじーめーにー」
Wally、「いっそのこと殺してくれ」

2010-02-22

今日、爆笑したAA

672:名無しさん@├\├\廾□`/:2009/10/20(火) 18:29:18 ID:oqedgD1/


        __
      /    ヽ
.     /      ヽ
.     i      ⌒ i
.     i       ( ●)\
      i  ./// (__ノ) ..\______,,
.      i.       ヽノ   /.パン:ティー//
      i         }   /  セット. //
.       ヽ,___.ノ  /.1200円.//
.      /      ヽ, ./η    //
.      { :   i  |/ヽソ.__//
.      | ̄ ̄ ̄ ̄|  | /  ̄ ̄ ̄      .| ̄ ̄ ̄ ̄|
  i二二|____|、__.ノ二二二二i二i二二|____|二二二二
  | | :: || i------|| ノ──、::::::::::::::| | :::::::::|| :::::::::::::::::||:::::::::::::::::
  | | :: ||,:ヽ.__{、__||___, } :::::::::: :| | :::::::::|| ;;;;;;;;;;;;;;;;;||;;;;;;;;;;;;;::::
  | | :: ||゙ ̄ ̄ ゙̄|| ̄ ̄|| | ::::::::::: | | :::::::::||゙ ̄ ̄ ゙̄|| ̄ ̄||:::::
  | | :: ||::::::::::: ::::::||::::::: ::|| | ::::::::::: | | :::::::::||::::::::::: ::::::||::::::: ::||:::::

673:名無しさん@├\├\廾□`/:2009/10/20(火) 18:30:23 ID:oqedgD1/


  .                       ____
                       /     \
                        /  ー  ー ヽ
                        | ( ●)  (●)|
                       |   (__人__)  i
  ..                    |    `⌒´  i
                           i           i
                         !         !
                        ヽ._   __.ノ
    | ̄ ̄ ̄ ̄|             /  ヽ,.ノ  \
    |____|             /       ,  }
  _||.____||_____ (. ( _{  ヽ,____.ノ.- ノ_.,:-y-、_
              /   __)_)__ \___ヽ  と)_/ /,.:':/|  .\
             /   6{””””}.、  ヽ;シ     /,.:':/ ::::|--、  .\
           /    (. ゙.ー '゙ )       .:i⌒⌒i:::: / ./   .\
          /       ゙ ー― '´         /i__i/ ./      .\
        /                   〈____/


676:名無しさん@├\├\廾□`/:2009/10/20(火) 18:37:11 ID:oqedgD1/


.        ____
      /     ヽ
       /         ヽ
       |.  u  ー  ‐i                      ___
      |.   ( ●) (●)  .                 / ー ー\
..     | u   (__人__) ・・・               /u (( Ο)) ((Ο)
.      i       `⌒´i                     / u.    (__人__)ヽ ~♪
       !        ノ                     |     )  )0i  |  ~♪
      ヽ._   __ノ                     \.__      /
      /  ヽ,.ノ  \                   / /匡i:””””}ヽ     .,-ー-、
.     /       ,  }                    //  .ノ ゙ー‐'´ .i    i\ ':.\
_(. ( _{  ヽ,_____ノ.- ノ_.,:-y-、___        __ヽ_/____i_i__ ,-yi::::::\ ':,\
  __)_)__.\___ヽ  と)_/ /,.:':/|  \      |\    6{””””}.、      |\ \::::::i⌒⌒i
..6{””””}.、 ヽ;シ    /,.:':/ ::::|--、 ..\     ||ヽ\  (. ゙.ー '゙ )  .,.―|::::::\ \i__i\
( ゙.ー '゙ )      .i⌒⌒i:::: / ./   .\    ||::::::ヽ\. ゙ ー― '´   \ \:::::::i⌒⌒i:⌒⌒i
 ゙ ー― '´      ./i__i/ ./         \  ||:::::::::::ヽ\   6{””””}.、 \ \:i__i:__i\
           〈____/          \ ::::::::::::::\\. (. ゙.ー '゙ )  \________〉

元スレ(らしい):やるお 交響曲第十番

2010-02-21

GMailのSent MailがBuzzで埋まる問題

Google Buzzは、すくなくとも、Twitterよりは、マシだ。しかし、既存のGMailアカウントで使うには、少々問題がある。Buzzは、単に変なラベルの付いたメールとして実装されている。つまり、GMailからみれば、ラベルがついている以外は、普通のメールと、何らかわりないのである。

となると、何が起こるか。Sent Mailが、Buzzであふれるのである。

直接の自分の発言の他に、connected sitesも、自分の発言として扱われる。つまり、BloggerやGoogle Readerのshared itemsが、Sent Mailに現れるのである。これでは、既存の、自分が送ったメールだけを見ようと思っても、Buzzのノイズの中に埋もれてしまう。

しかし、Buzzを使わないというオプションはない。Micro bloggingは、基本的に、ノイズを生成するものである。

では、現実に、自分が送ったメールだけ見たい場合は、どうすればいいのか。

これは、検索で解決できる。検索クエリーは、"is:sent -{label:buzz}"である。いちいち検索するのは面倒なので、Lab機能である、Quick Linksに登録しておけばよい。クリックひとつで参照できる。

C++0x本:目次案

とりあえず目次案を埋めた。査読者様はwaveからご確認ください。

えらく時間がかかったが、ページ数が足りないだろうという頭があるので、どう圧縮するが、何が重要なのかを考えるのに苦労した。

これは、ページ数が足りないかもしれない。優先して省略すべきところは、そのような表示をした。

さて、あとは、見直しだ。

mutable iterator

for_eachは、Non-modifying sequence operationsということになっている。では、たとえばこういうコードは、規格違反なのだろうか。

template < typename Iterator >
void f( Iterator first, Iterator last )
{
    std::for_each(first, last, 
        []( std::iterator_traits<Iterator>::reference value)
        {
            value = std::iterator_traits<Iterator>::value_type() ; // 書き換える。
        }
    ) ;
}

std::iterator_traits<Iterator>::value_typeは、デフォルトコンストラクタと、コピーコンストラクタを持つものとする。このように、参照で受ければ、for_eachで、イテレーターの指す要素を書き換えることが可能だ。

じつは、規格には、mutable iteratorというものがある。これは、あるイテレーターの変数、iに対して、*iという式が、リファレンスを返すイテレーターのことを指す。その場合、for_eachで、イテレーターの指す要素を書き換えることができるのである。

なぜリファレンスでなければならないのか。それは、こういう事だ。

struct Iterator
{
int operator *() ;
}

このように、operator *()がリファレンスを返さなければ、いくら関数オブジェクトの仮引数をlvalueリファレンスで受けても、書き換えることはできない。

C++0x本:アルゴリズム

後は、アルゴリズムだけだ。

問題は、アルゴリズムの全関数を律儀に解説しているページ数はないということだ。また、イテレーターや関数オブジェクトは、重要かつ根本的な概念なので、別に解説を設ける。とすると、アルゴリズムの章には、何を書けばいいのか。

Non-modifying sequence operations, Mutating sequence operations, Sorting and related operationsから、代表的なものをいくつか拾って、解説すべきか。

面白いネタ集

ネタが無いので、最近スターをつけたGoogle Readerの記事を、適当に貼り付けることにした。

ナウリと呼ばれるヨガらしいが、どうやれば腹筋をここまでコントロール出来るのか。

Not photoshoppedだそうだ。

すごい動きをする犬の動画。

サザエさんをどこまで美人に描けるか、挑戦してみようぜwww:ハムスター速報

ぬこ。

@nifty:デイリーポータルZ:ペリーがパワポで提案書を持ってきたら

なんという典型的で空虚なプレゼンだろう。

例の盗撮問題、FBIが動き出したらしい。

Pa. school official defended in webcam spy case - washingtonpost.com

本の虫: ラップトップのwebcamで全生徒を盗撮している学校で取り上げた問題に対し、FBIが捜査を始めたらしい。

Slashdotのコメントが面白かった。

Slashdot | FBI Probing PA School Webcam Spy Case

Because the absolute first thing *I* thought when I heard of this atrocity is: "Orwell would be proud."

Not Orwell, don't overuse it.

First thing I thought was "Pedobear would be proud."

参考:
George Orwell - Wikipedia, the free encyclopedia

クソだ

Open letter to Google: free VP8, and use it on YouTube - Free Software Foundation

クソすぎる。GoogleもなんでOn2なんか買収したんだか。VPに価値はない。

追記:とある人から、GoogleがOn2を買収したのは、On2の持つ動画関連の特許をまるごと買いたかったから、という動機があるのではないかとのことだった。さもありなん。

chronoって、コンパイル時定数にできない場合、どうするのだろう

durationのtemplate parameterである、Periodは、コンパイル時定数である。Periodは、Rep1カウントあたりの経過秒数を、秒単位で表現する。つまり、ミリ秒の分解能を持っているならば、std::milli(typedef ratio<1, 1000> milli;)が使える。

しかし、現実のハードウェアタイマーは、そんな分かりやすい分解能を持っていない。しかも、プログラムが実行される環境のハードウェアが、実行時にしか分からない場合もある。一体どうするのか。

いや、そもそも、そんなに使いづらい、ハードウェアの限界の分解能を使うだろうか、ミリ秒だとか、マイクロ秒だとか、分かりやすい単位にした方がいいのではないか。

たとえば、HPETを有効にした私のWindows環境では、QueryPerformanceFrequencyは、14318180を返す。

これは、一秒間に、14318180回のカウントができると言うことを意味する。すなわち、1クロックは、約70ナノ秒である。

しかし、私の環境でHPETを無効にすると、QueryPerformanceFrequencyは、3579545を返す。これは、1クロックあたり、約279ナノ秒である。

HPETの有無は、実行時にしか分からない。ということは、通常のx86なWindows環境に置いては、マイクロ秒単位が、安全なのだろうか。まあ、そういうきりの良い数字なら、コンパイル時に指定できるし。

なんとなく、Windows環境で動くhigh_resolution_timerを書いてみたけど、std::ratioとstd::chrono::durationとstd::chrono::time_pointがないために、実行できない。

namespace std { namespace chrono {

struct Freq
{
        LARGE_INTEGER freq ;
        Freq()
        {
                QueryPerformanceFrequency( &freq ) ;
        }

        
} ;

class high_resolution_clock
{
        static Freq freq ;
public:
typedef std::int64_t rep;
typedef std::micro period;
typedef chrono::duration<rep, period> duration;
typedef chrono::time_point<high_resolution_clock , duration> time_point;

static const bool is_monotonic = false ;

static time_point now()
{
        LARGE_INTEGER count ;

        //if ( QueryPerformanceCounter( &count ) == 0 )
        //{// エラーの場合、どうすればいいのだろう。規格は何も言及してない。
        //        count.QuadPart = 0 ;
        //        return time_point( duration.zero() ) ;
        //}

        QueryPerformanceCounter( &count ) ;
        rep tick = static_cast(double(count.QuadPart) / (double(freq.freq.QuadPart) / 1000000.0) ) ;
        //rep tick = count.QuadPart / (freq.freq.QuadPart / 1000000) ;


        return time_point( duration(tick) ) ;
}

} ;

Freq high_resolution_clock::freq ;

} }

boostのchronoのWindowsの実装に失望した

QueryPerformanceCounterは、マルチスレッド環境だとコケるって、誰かが言ってたので、timeGetTimeとtimeBeginPeriod(1)を使うことによって、お茶を濁しておく。

だめだこりゃ。こんな文章が、その問題の本質に言及せず、恥ずかしげもなく書いてあるぐらいだから、Boostの実装はあてにならん。バギーなBIOSのせいなのに。

timeGetTimeは、全然high resolutionじゃないよ。

我々は、HPETの布教活動をするべきなのだろうか。

2010-02-20

相変わらずwtfjsは面白い

wtfjs: More concat “fun”.

"3" + 1 // '31'
"3" - 1 // 2
"222" - -"111" // "333" (⊙﹏⊙)

一瞬、戸惑ってしまった。

一行目は分かる。文字列の連結だ。

二行目も簡単だ。引き算である。

三行目。え? あれ、何で。

実のところ、これは小学校の算数の問題である。Javascriptの自動的な型変換が、見た目をややこしくしているとはいえ、結局は、算数である。

ラップトップのwebcamで全生徒を盗撮している学校

School used student laptop webcams to spy on them at school and home Boing Boing

しかも、悪徳であるという自覚がないらしい。

この学校の生徒は全員、プライバシーの意味を知らない教師から教育を受けた、危険思想を持つ可能性の高い人物なので、かかわり合いになりたくない。

diggのコメントが面白かった。pedobear(クマー)がたくさん貼られていた。つまりは、こういうことだ。

これって、未成年の生徒が、ラップトップの前で服を脱いだら、この学校の校長が、児童ポルノの罪でタイーホされるってことだよね。

日本にはもう一度レッドパージが必要だと本気で思ったニュース

中日新聞:首相、発言また迷走 「検討」は「前向きではない」:政治(CHUNICHI Web)

鳩山首相が17日、大企業の内部留保への課税にいったんは前向きな姿勢を示しながら、後になって取り消した。

共産党の志位和夫委員長と国会で会談した際のこと。志位氏によると、首相は「大企業の内部留保に適正な課税を行うことも検討したい」と述べた。会談後、記者団が発言内容の確認を求めると、首相は「せっかく(内部留保対策を)持ってきたから、検討してみましょうと申し上げた。前向きではない」と説明した。

米軍普天間飛行場移設問題をはじめ、首相の八方美人的なリップサービスによって事態をこじらせるケースが目立つが、この悪い癖がまた出たようだ。

日本を共産主義国にするつもりなのだろうか。企業は一切の設備投資ができなくなるのだが。というか、私が経営者なら、即座に計画倒産する。

公共の場からのタバコの排除は当然であり、反対者は非国民である

公共の場からの、タバコの全面的排除は当然の措置であり、反対者は非国民である。

何故ならば、我が日本国は、たばこの規制に関する世界保健機関枠組条約に批准しているからである。この条約は、発行に必要な批准数に達したため、2005年の2月に発行されている。批准国は、五年以内にこの条約を守らなければならない。

批准した条約の効力は、日本国憲法に準ずることが、日本国憲法により保証されており、当然、条約に基づく法整備を行わなければならない。さもなくば、条約違反となる。

したがって、一切の公共の場から、忌々しいタバコを排除することは、国際条約と憲法とが保証するところである。したがって、この法律への反対者は、ただに法律への反対者ではない。国際条約と憲法への反対者であり、明確な非国民である。

非国民たるのそしりを免れるならば、条約を批准したことへの批判か、もしくは、日本国憲法の改正を提案しなければならない。しかるに、この忌々しき非国民どもは、そのような行動を起こさない。これに近いのは、革命家か。

なお、タバコ産業に関わるものが職を失うだの、暴力団の資金源になるだのといった批判は、正しくない。日本がこの条約に批准した時点で、こうなることは分かりきっていたことであり、いまだにタバコに依存している者は、情報弱者たるのそしりを免れない。また、暴力団の資金源になるというのは、甚だしい問題のすり替えである。大麻や覚醒剤のごときを合法化して、国が管理し、販売すれば、暴力団の資金源にはならなくなる。それをしないのは、何故かと、逆に問うたら、この種の喫煙厨は、回答に貧するのである。

では、酒はどうなのかというのは、またこれも甚だしい問題のすり替えである。この条約は、酒に関しては一切言及していない。そのような反論は、議論の成立しないアホだからこそ、なせる業なのである。

結論としては、忌々しい喫煙厨は、我が日本には必要としないのである。

ADLへの対処方法

C++のADLは、時として、意図しない結果を引き起こす。

// フサフサである自分の書いたコード
// 独自のコンテナを実装している。
// 表示用のprint()関数は、用意していない。
namespace FusaFusa
{
        template < typename T >
        class Container {} ;
}

// 同僚のハゲの書いたコード
// コンテナに格納する要素クラスを実装している。
namespace Hage
{
        template < typename T >
        class Element ;

        // Elementを表示するための、ジェネリックな関数。
        // Fooを引数に取ることを意図していない。
        template < typename T > void print(T) {}
}

// オブジェクトを印刷するための関数。
template < typename T >
void print_object(T const & x )
{
        // print()は表示用の関数。
        // Hage::print()が、意図せず呼ばれてしまう。
        print( x ) ;
}

int main()
{
        typedef Hage::Element<int> elem ;
        FusaFusa::Container< elem > cont ;
        print_object( cont ) ;
}

print_object()関数は、テンプレート引数の型のオブジェクトを、print()という関数に渡せることを期待している。呼び出せるprint()がなければ、当然、コンパイルエラーになってほしい。この例では、ADLが働くために、同僚のハゲの書いた、Hage::print()が、意図せずして、呼び出されてしまう。結果として、このバグは、実行するまで分からない。

言うまでもなく、ADLは邪悪な機能である。一体、このような場合、どうすればいいのか。

まずまっさきに責めるべきは、同僚のハゲである。ハゲの書いたprint()関数は、あまりにもジェネリックすぎる。たとえば、以下のように書けば、十分にジェネリックで、しかも、このケースで、コンパイルエラーになってくれる。

namespace Hage
{
        // あまりにもジェネリック過ぎる関数。
        //template < typename T > void print(T) {}

        // これならよし。
        template < typename T > void print( Element<T> ) {}        
}

しかしながら、現実は、そう上手くいかない。たとえば、ハゲは無能だがプライドだけ無駄に高い上司であり、自分の書いたコードの書き換えを拒否するかもしれない。あるいは、Hage名前空間のコードは、よそから提供されているライブラリであり、書き換えられないかもしれない。最良の選択は、そのような無能なハゲを、プロジェクトのメンバーから排除することだが、現実は、そう上手くいかない。ともかく、何らかの理由で、ハゲの書いたコードは、書き換えられないものとする。

では、どうすればいいのか。

ADLを回避する方法として、括弧を使う方法がある。

(print)( x ) ;

これは動くが、しかし、ADLの良い点も消してしまう。たとえば、FusaFusa::print()が存在したとしても、呼ばれることがない。

namespace FusaFusa
{
        template < typename T > void print(T) {}
}

ではどうするのか、結局、メタプログラミングに頼るしかないだろう。

// Primary Template
template < typename T >
struct print_traits ;

// 特殊化を付け加えて行く。
template < typename T >
struct print_traits< Hage::Element< T > >
{
        static void invoke( Hage::Element<T> const & value )
        {
                Hage::print( value ) ;
        }
} ;

結局、一番望ましいのは、conceptが言語機能としてサポートされていることだ。

もっと簡単な方法もある。ADLを使わないことだ。たとえば、必ずグローバル名前空間に、print()が定義されていなければならないものとする。

template < typename T >
void print_object(T const & x )
{
        // グローバル名前空間のprint()を明示的に呼び出す。
        // ADLは起こらない。
        ::print( x ) ;
}

あるいは、何らかの名前空間に定義されていなければならないものとする。たとえば、mohawk(モヒカン)という名前空間に定義しなければならないものとする。

template < typename T >
void print_object(T const & x )
{
        // Mohawk名前空間のprint()を明示的に呼び出す。
        // ADLは起こらない。
        mohawk::print( x ) ;
}

しかし、残念ながら、現実は、そううまくはいかない。ある者はADLを使うし、あるものは、print()ではなく、Print()を使うかもしれないし、またある者は、PRINT()を使うかもしれない。だからこそ、traitsが有用であり、conceptの必要性が叫ばれるのだ。

C++0x本:懸念事項

じつは、C++0xのドラフトは、まだstableとは言えない。

たとえば、N3033: Core issue 951: Various Attribute Issuesだ。

これが採用されると、attributeの書ける位置が、格段に広がる。小粒だが、かなり影響力のある変更だ。

しかし、今、本を書き始めなければ、到底、規格制定には間に合わない。規格制定の数年後に本を出すのは遅すぎる。しかし、ドラフトを元にして本をかくのは、危険だ。できれば、規格制定後に書きたい。

もっとも、これは今に始まった話ではない。1998年以前に書かれたC++の本も、この問題を抱えている。2003年以前に書かれた本も、この問題を抱えている。とすれば、いつだって、正しい時ではないのだ。

2010-02-19

東方の杜子春

たまたま拾った。おそらく、芥川龍之介の杜子春が元ネタ。

芥川龍之介 杜子春

この画像をみて、ふと、芥川龍之介の杜子春の、本来の元ネタが気になった。どうやら、杜子春伝というらしい。気になったので、原文を探してみた。

杜子春傳 李復言

杜子春傳   李 復言

杜子春者、蓋周隋閒人。少落拓不事家産。然以志氣閒曠、縱酒閒遊、資産蕩盡。投於親故、皆以不事事見棄。

方冬、衣破、腹空、徒行長安中。日晩未食、彷徨不知所往。於東市西門、饑寒之色可掬、仰天長吁。

有一老人策杖於前。問曰、「君子何歎?」春言其心、且憤其親戚之疎薄也、感激之氣、發於顏色。老人曰、「幾緡則豐用?」子春曰、「三五萬、則可以活矣。」老人曰「未也。」更言之、「十萬。」曰、「未也。」乃言、「百萬。」亦曰、「未也。」曰、「三百萬。」乃曰、「可矣。」於是袖出一緡、曰、「給子今夕。明日午時、候子於西市波斯邸。愼無後期。」

及時、子春往。老人果與錢三百萬、不告姓名而去。

子春既富、蕩心復熾、自以爲、終身不復羈旅也。乘肥、衣輕、會酒徒、徴絲管、歌舞於倡樓、不復以治生爲意。

 一二年閒、稍稍而盡。衣服車馬、易貴從賤、去馬而驢、去驢而徒。倏忽如初。

既而復無計、自歎於市門。發聲而老人到。握其手曰、「君復如此。奇哉! 吾將復濟子。幾緡方可?」子春慚不應。老人因逼之。子春愧謝而已。老人曰、「明日午時、來前期處。」

子春忍愧而往、得錢一千萬。未受之初、憤發、以爲、從此謀身治生、石季倫・猗頓小豎耳。

錢既入手、心又飜然。縱適之情、又卻如故。不一二年閒、貧過舊日。

復遇老人於故處。子春不勝其愧。掩面而走。老人牽裾止之、又曰、「嗟乎、拙謀也!」因與三千萬曰、「此而不痊、則子貧在膏肓矣。」子春曰、「吾落拓邪遊、生涯罄盡。親戚豪族、無相顧者。獨此叟三給我。我何以當之?」因謂老人曰、「吾得此、人閒之事可以立、孤孀可以衣食、於名教復圓矣。感叟深惠、立事之後、唯叟所使。」老人曰、「吾心也。子治生畢、來歳中元見我於老君雙檜下。」

子春以孤孀多寓淮南、遂轉資揚州、買良田百頃、郭中起甲第、要路置邸百餘閒、悉召孤孀分居第中。婚嫁甥姪、遷祔族親、恩者煦之、讐者復之。

既畢事、及期而往。老人者方嘯於二檜之陰。遂與登華山雲臺峰。入四十里餘、見一處室屋嚴潔、非常人居。彩雲遙覆、驚鶴飛翔。其上有正堂。中有藥爐、高九尺餘、紫焔焰光發、灼煥窗戸。玉女九人、環爐而立、青龍白虎、分據前後。

其時日將暮、老人者不復俗衣、乃黄冠絳帔士也。

持白石三丸、酒一巵、遺子春、令速食之。訖、取一虎皮鋪於内西壁、東向而坐。戒曰、「愼勿語、雖尊神、惡鬼、夜叉、猛獸、地獄、及君之親屬爲所困縛萬苦、皆非眞實。但當不動不語、宜安心莫懼。終無所苦。當一心念吾所言。」言訖而去。子春視庭、唯一巨甕、滿中貯水而已。 

道士適去、旌旗戈甲、千乘萬騎、徧滿崖谷、呵叱之聲、震動天地。有一人稱大將軍、身長丈餘、人馬皆着金甲、光芒射人。親衞數百人、皆杖劍張弓、直入堂前、呵曰、「汝是何人、敢不避大將軍?」左右竦劍而前、逼問姓名、又問作何物、皆不對。問者大怒、摧斬爭射聲如雷。竟不應。將軍者極怒而去。 

俄而猛虎、毒龍、狻猊、獅子、蝮蝎、萬計、哮吼拏攫而爭前欲搏噬、或跳過其上。子春神色不動、有頃而散。 

既而大雨滂澍、雷電晦瞑、火輪走其左右、電光掣其前後、目不得開。須臾、庭際水深丈餘、流電吼雷、勢若山川開破、不可制止。瞬息之閒、波及坐下。子春端坐不顧。

未頃、而將軍者復來、引牛頭獄卒、奇貌鬼神、將大钁湯而置子春前。長鎗兩叉、四面週匝。傳命曰、「肯言姓名、即放。不肯言、即當心取叉置之钁中!」又不應。

因執其妻來、拽於階下、指曰、「言姓名免之。」又不應。及鞭捶流血、或射或斫、或煮或燒、苦不可忍。其妻號哭曰、「誠爲陋拙、有辱君子。然幸得執巾櫛、奉事十餘年矣。今爲尊鬼所執、不勝其苦。不敢望君匍匐拜乞。但得公一言、即全性命矣。人誰無情、君乃忍惜一言!」

雨涙庭中、且呪且罵。春終不顧。將軍且曰、「吾不能毒汝妻耶?」令取剉碓、從脚寸寸剉之。妻叫哭愈急、竟不顧之。將軍曰、「此賊妖術已成。不可使久在世間。」敕左右斬之。

斬訖、魂魄被領見閻羅王。曰、「此乃雲臺峰妖民乎? 捉付獄中!」于是鎔銅、鐵杖、碓擣、磑磨、火坑、鑊湯、刀山、劍樹之苦、無不備嘗。然心念道士之言、亦似可忍、竟不呻吟。

獄卒告受罪畢。王曰、「此人陰賊、不合得作男。宜令作女人、配生宋州單父縣丞王勸家。」

生而多病、針灸藥醫、略無停日。亦嘗墜火墮牀、痛苦不齊、終不失聲。

俄而長大、容色絶代。而口無聲。其家目爲唖女。親戚狎者、侮之萬端、終不能對。

同郷有進士盧珪者。聞其容而慕之。因媒氏求焉。

其家以唖辭之。廬曰、「苟爲妻而賢、何用言矣。亦足以戒長舌之婦。」乃許之。廬生備六禮、親迎爲妻。

 

數年、恩情甚篤。生一男、僅二歳、聰慧無敵。盧抱兒與之言、不應。多方引之、終無辭。盧大怒曰、「昔賈大夫之妻、鄙其夫、纔不笑。然觀其射雉、尚釋其憾。今吾又陋不及賈、而文藝非徒射雉也。而竟不言。大丈夫爲妻所鄙、安用其子!」乃持兩足、以頭撲於石上、應手而碎、血濺數歩。子春愛生于心、忽忘其約、不覺失聲云、「噫!」

噫聲未息、身坐故處。道士者亦在其前。初五更矣。

見其紫焰穿屋上、大火起四合、屋室倶焚。道士歎曰、「錯大誤餘乃如是!」因提其髮投水甕中。

未頃、火息。道士前曰、「吾子之心、喜怒哀懼惡慾、皆忘矣。所未臻者、愛而已。向使子無噫聲、吾之藥成、子亦上仙矣。嗟乎、仙才之難得也! 吾藥可重煉、而子之身猶爲世界所容矣。勉之哉!」遙指路使歸。子春強登基觀焉、其爐已壞。中有鐵柱、大如臂、長數尺。道士脱衣、以刀子削之。

子春既歸、愧其忘誓。復自效以謝其過、行至雲臺峰、絶無人跡。歎恨而歸。

なるほど。芥川は劣化コピーだな。わざわざ仙人に語らせなくてもよかろうに。

2010-02-18

芸術的なcurse word

私は英語が好きである。特に、英語のcurse wordが好きである。英語のcurse wordには、日本語にない力がある。もはや、芸術と言ってもよいのだ。

さて、South Parkは、私のcurse wordの需要を満たしてくれるが、残念なことに、一年のうちの半年しか放送されない。しかし、まだまだソースはある。

まず、Angry Video Game Nerdだ。今週のエピソードは、

これは、James Rolfeなる、怒れるゲームオタク(Angry Video Game Nerd)によって、作成されている動画である。彼は芸術的なcurse wordを使う。

つぎに、zero punctuationだ。これ文字通り、句読点がない。今週のエピソードは、

こちらも、curse wordを芸術的に使っている。

これらは、もちろんすばらしい。しかし、私の中で、最高級の芸術品として認められる作品というものがある。これらだ。

Sony Releases New Stupid Piece Of Shit That Doesn't Fucking Work

I hate nature.

Olde English Comedy » I Hate Nature
Olde English Comedy » I Hate Nature 2

pseudoの発音は[sú:dou]だった

pseudoの発音は[sú:dou]だった。知らなかった。pがサイレントレターだったとは。

しかし、考えてみれば、私はpseudoを発音しなければならない状況に出くわしたことがないのはもとより、聞いた覚えすらない。しかし、読んだ覚えなら、いくらでもある。はて、これはどういうわけだろう。

ということを、IRCで愚痴っていたら、あるネイティブも、pseudoを表立って発音したことは、今まで一度もないということであった。しかし、pseudoは、珍しい単語というわけでもない。一体どういう事か。

pseudoは、科学関係によく用いられるので、一般に話されることは、少ないのだろうということだった。確かに、私の場合、プログラミング関係でしか、pseudoという言葉が使われているのを読んだ覚えがない。

pre-Pittsburgh mailingの簡易レビュー

ISO/IEC JTC1/SC22/WG21 - The C++ Standards Committee

pre-Pittsburgh mailingが公開された。なぜか、今現在は、post-Santa-Cruz mailingになっているが、これは間違いである。中身はpre-Pittsburghである。

現在のワーキングドラフトは、N3035となった。

N3021: Harmonizing Effects and Returns Elements in Clause 21

String Libraryの個々のメンバー関数の定義で、[structure.specifications]の定めるところの、EffectsとReturnsの使い方がなされていない。具体的な例を出すと、たとえば、string::operator +=の場合、

Returns: append(str).

となっている。つまり、現状ではReturnsだけで、Effectsも定義している。これを、[structure.specifications]が定めるところにより、正しく定義しなおす。具体的には、Returnだけで定義されていたものを、EffectsとReturnsに分離する。また、必要に応じて、その他の句も付け加える。

Effects : Calls append(str.data(), str.size()) .
Returns: *this.

N3023: Defaulting non-public special member functions on first declaration

特別なメンバー関数を、非publicに明示的なデフォルト化(explicitly-defaulted)できないという問題への対処。つまり、

struct Foo
{
// 暗黙に宣言されるデフォルトコンストラクタをprotectedにする。
protected :
    Foo() = default ;
// 暗黙に宣言されるコピーコンストラクタをprivateにする。
private :
    Foo( Foo & )  = default ;
} ;

このコードは、現状ではill-formedである。しかし、上記のようなコードは利点があるので、特別なメンバー関数は、明示的に非publicにデフォルト化できるべきである。という提案。

N3024: Proposal to Simplify pair (rev 4)

pairが複雑になりすぎているから、少し単純化しようという提案の、改訂版。

N3025: Specifying Pointer-Like Requirements

規格の複数の箇所で、型が、nullableかつpointer-likeであることが要求される。個々の場所で要求するよりも、そのようなrequirements、NullablePointer requirementsを追加し、参照するという提案。

N3030: Rvalue References as "Funny" Lvalues

lvalueを二種類に分ける。すなわち、従来のlvalueを、non-rref lvalueとし、ある特殊な値を、rref lvalueとする提案の改訂版。rref lvalueは、以下の場合の式によって生成される。

  • Function calls (explicit or implicit) that return rvalue references to objects
  • Casts to rvalue references to objects
  • Member selection and pointer-to-data-member dereference expressions where the object expression is an rref lvalue

N3031: Core issues 743 and 950: Additional decltype(...) uses

あのウメハラとガチで戦えるイケメンのアキラさんによって報告された、我らがC++WG JPの誇るべきコメントJP 8 (Core issue 743)の、decltypeをname qualifierとして使用できるようにする提案。また、base-specifierや、pseudo-destructor-name、mem-initializer-idにも使用できる。

struct Base
{
        typedef int type ;
} ;

Base base ;
// well-formed. use decltype in a name qualifier.
decltype(base)::type ; 

// well-formed. use decltype in a base-specifier.
struct Derived : public decltype(base)
{
        // well-formed. use decltype in a mem-initializer-id.
        Derived : decltype(base)()
        { }
} ;

// well-formed. use decltype in a pseudo-destructor-name.
base.~decltype(base)() ;

見ての通り、名前修飾子はもとより、ベースクラスの指定や、メンバー初期化子の指定、疑似デストラクタ名にもdecltypeが使えるようになる。

N3032: Core issue 374: Explicit specialization outside a template's parent

名前通り、C++ Standard Core Language Active Issuesの374を参照のこと。以下のコードをwell-formedにする。

  namespace NS1 {
    template<class T>
    class CDoor {
    public:
      int mtd() { return 1; }
    };
  }
  template<> int NS1::CDoor<char>::mtd()
  {
    return 0;
  }

N3033: Core issue 951: Various Attribute Issues

attributeを記述できる場所の追加。また、記述する場所の変更。

N2024: Core issue 968: Disambiguating [[

Santa Cruz会議で、我々は、[[をすべて、attributeとみなすことに同意した。しかしながら、それではちとばかし困る場合がある。

int p[10];

void f()
{
        int x = 42;

// ill-formed.
// a lambda expression and function call in a subscripting.
// but standard assumes it as attribute.
        int(p[[x]{return x;}()]) ; 

// ill-formed.
// almost same. again standard assumes it as attribute.
        new int[[]{return x;}()] ;
}

これをwell-formedにしようという提案。

N3037: Conceptless Random Number Generation in C++0X

randomライブラリから、conceptがドラフトに入っていた名残を撤去。また、細かな変更。

N3038: Managing the lifetime of thread_local variables with contexts (Revision 2)

thread_local修飾された変数が、いつ破棄されるのかという問題がある。thread::join以外の以外の方法でスレッドの終了を待機した場合、thread_local修飾された変数は、まだ破棄されていない可能性がある。

それに、スレッドプールのような仕組みで、一度作ったスレッドを使いまわす場合、thread_local就職された変数を、ある地点で、生成破棄して、再びやりなおしたい場合がある。しかし、現在の標準では、それができない。

そこで、thread_local_contextクラスを追加する。これは、thread_localの寿命を指定するクラスである。このクラス自体を、直接操作することはない。このクラスのオブジェクトのlife timeが、すなわち、thread_localなオブジェクトのlife timeになる。どういう事かというと、

// スレッドごとに独立して、ひとつ存在するべきクラス。
classs Thread_Local_Object ;

// そのクラスのオブジェクト。
// このオブジェクトは、スレッドごとにひとつ、生成される。
thread_local Thread_Local_Object obj ;

// スレッド関数
void worker_thread()
{
        {
                // ここで、新たなコンテキストが始まる。
                // すなわち、objのコンストラクタが走り、新しいobjが生成される。
                std::thread_local_context context ;
                // 処理

        }// ここで、コンテキストが終わる。すなわち、objのデストラクタが走り、objが破棄される。


        {
                // ここで、新たなコンテキストが始まる。
                std::thread_local_context context ;
                // 処理

        }// ここで、コンテキストが終わる。すなわち、objのデストラクタが走り、objが破棄される。

        {// コンテキスト #1
                // ここで、新たなコンテキストが始まる。
                std::thread_local_context context ;
                // 処理

                {// コンテキスト#2 ネストできる。
                        // ここで、新たなコンテキストが始まる。
                        std::thread_local_context context ;
                        // 処理

                        {// コンテキスト#3 ネストできる。
                                // ここで、新たなコンテキストが始まる。
                                std::thread_local_context context ;
                                // 処理

                        }// ここで、コンテキスト#3が終わる。すなわち、objのデストラクタが走り、objが破棄される。

                }// ここで、コンテキスト#2が終わる。すなわち、objのデストラクタが走り、objが破棄される。

        }// ここで、コンテキスト#1が終わる。すなわち、objのデストラクタが走り、objが破棄される。
}

このように、コンテキストを作ることによって、thread_localなオブジェクトのlife timeを、制御できる。

これはすばらしい提案だ。是非とも規格入りするべきである。

N3039: Constexpr functions with const reference parameters (a summary)

const T& argumentsに対して、constexpr specifierを使えるようにする提案。constな参照は、定数と言ってもいいので、これは当然だ。これが認められないと、標準ライブラリの多くが、constexpr化できない。

N3040: Various threads issues in the library (LWG 1151)

スレッドに対する、細かい文面の変更。iostreamの使用、race conditionの際に限りconstと見なされるSTLのメンバー関数のリストにat()を追加、atomic read-modify-writeの文面を変更して、分かりやすくする、標準ライブラリのイテレーターの競合についての文面の追加。

N3041: Futures and Async Cleanup

N2996とN2997は、前回、一緒に採用されたのだが、その中身が、前のドラフトを参照していて、現在のドラフトに当てはめるのに、問題がある。その問題を解決(編集さん、ごめんね)

N3042: Renaming launch::any and what asyncs really might be

launch::anyをany_asyncに改名。

N3043: Converting Lambdas to Function Pointers

lambda-captureが空なlambda expressionは、同じ引数と戻り値の型の、関数ポインタに変換できるようにする提案。すなわち、

void (*ptr1)(int) = [](int) -> void {} ;
int (*ptr2)(void) = [](void) -> int { return 0 ; } ;

このようなコードが書ける。これにより、既存の関数ポインタを引数に取るコードが再利用できる。もっとも、一番ふさわしいのは、テンプレートや、std::functionを使うことなのだが。

N3044: Defining Move Special Member Functions

デフォルトのコピーコンストラクタとムーブコンストラクタを生成するための、ドラフトの文面の変更。変更する箇所が、甚だしく多い。

N3045: Updates to C++ Memory Model Based on Formalization

メモリモデルとアトミックに関する、細かな文面の変更。

N3046: Iterators in C++0x

C++のイテレーターは、素晴らしく成功したと言える。がしかし、設計に多少の問題があるのも事実だ。本来ならば、コンセプトが、その穴を埋めてくれたはずなのだが、残念ながら、コンセプトの却下により、今までのイテレーターの改良案は、すべて水泡に帰してしまった。そこで、コンセプトの研究を踏まえつつ、現状の規格の範囲で、イテレーターを改良しようという提案。

Please, I beg you C++ Working Group members. Write your goddamn papers in the plain HTML! I don't want to take any shit from crappy PDFs! Please...

C++0x本:つまった

ここ数日、コンテナとアルゴリズムの目次が、さっぱり進まない。ひたすら悩みながら、何も進んでいないのだ。

問題はページ数だ。全関数と全クラスとその全メンバーを解説できるようなページ数はない。そこで、私は概念の説明をきっちりしようと決意した。しかし、関数オブジェクトやイテレーター、スマートポインターとは違い、コンテナやアルゴリズムの概念の解説は難しい。というのも、アルゴリズムというのは、所詮は、イテレーターを引数に取る関数テンプレートの寄せ集めであるし、コンテナの定義も、これこれの式がこのような動作をする、というものなのだ。コンテナが満たすべき最低限の定義をした上で、vectorだのlistだのmapだのunordered_mapだのといった、より詳しく、多くのことを定義した、サブクラスともいうべき、具体的なクラスが定義されるのだ。

したがって、アルゴリズムの解説は、具体的な関数の解説でしかなく、コンテナの解説をするには、ページが足りない。

そんな事をするぐらいなら、アルゴリズムは、最も単純な、for_eachに特化して、具体的な実装方法を解説した方が、よほどためになる。コンテナも、個々のクラスの列挙と、サンプルコードでも載せた方が、よほど実用的だ。コンテナひとつあたり、せいぜい数ページだ。

それに、その他のライブラリのこともある。iostreamなどは解説しなくてもいいとする。文字列のライブラリも、一般的だから、省くとする。しかし、新しく追加されたライブラリはある。乱数、正規表現、アトミック操作、スレッド。これらを解説するには、ページ数が絶望的に足りない。しかし、一切言及しなかったとしたら、読者は、その存在すら知ることがなくなる。たとえ一言でも、言及してあるならば、別の本や資料によって、詳しく調べようという意欲が湧いてくるのではないか。

どういうものかという根本的な概念の説明と、至極簡単なサンプルコードなら、2ページあれば書けるはずだ。たとい、実用上、役に立たなかったとしても、少なくとも、読者はその存在を知ることができる。そもそも、その存在を知っているかどうかの差は大きい。それならば、10ページ程度を割いて、これらのライブラリを、せめて紹介しておくのも、悪くないのではないか。

難しい。

Google日本語入力の開発版

Google Japan Blog: Google 日本語入力に開発版が追加されました。

Google日本語入力にも、開発版がリリースされたらしい。さて、どうするか。

2010-02-17

これは、及ばない

.sort.call(null)の深淵 - 素人がプログラミングを勉強するブログ

これは到底、及ぶところにあらず。いつか、私もこんなふうにJavascriptを語れる日が来るだろうか。

C++0x本:用語再考

Abstract classって、アブストラクトクラスでも通じるんじゃないか。

specializationも、スペシャライゼーションで通じるんじゃないか。

いや、しかし、難しい。

Akinatorで遊ぶ

目次案が詰まったので、Akinator, the Web Geniusで遊ぶことにした。

ZUN、ウメハラ、Linus Torvalds、Bjarne Stroustrup、ひろゆき、荒木飛呂彦、フリーザー、東方のキャラ、South Parkのキャラ、ジョジョの奇妙な冒険のキャラは、だいたい知っているようだ。

ところで、「その人物は自分と家族であるか」とか、「その人物は、自分を知っているか」などという質問があったので、もしやと思い、あてるべき人物を、「自分」としてやってみた。

質問に答えて行くと、「自分と同じ名字であるか」とか、「自分と同じ年齢であるか」などという質問がでてきた。明らかに狙っている。

そして、見事に、"You!!!"という答えが出た。画像が、なぜかチンパンジーだった。

Javascriptで改行が特別な意味を持つケース

というより、Automatic Semicolon Insertion(自動セミコロン挿入)なのだが。

postfix increment とpostfix decrement

var fail = 0 ;
fail // 自動的にセミコロンが補われる
++ ; // ill-formed.

fail // 自動的にセミコロンが補われる
-- ; // ill-formed.

continue statementとbreak statement

fail: while (true)
{
    continue // 自動的にセミコロンが補われる
        fail ;// ill-formed.

    break // 自動的にセミコロンが補われる
        fail ;// ill-formed.
}

return statement

function return_undefined()
{
    var fail = 0 ;
    return // 自動的にセミコロンが補われる。undefinedを返す。
        fail ;
}

throw statement

throw // 自動的にセミコロンが補われる。throw文のexpressionの省略はできないので、ill-formed.
    0 ;

}の場合

        var x = function (){ } // 自動的にセミコロンが補われる。well-formed.
        x() ;

結論:Javascriptは変態だ。

その他の奇妙なJavascriptのコード

本の虫: 訳の分からないJavascriptのコードに勝るコードは、今のところ見当たらないが、面白いコードも、いくつかあった。たとえば、

(function(){
    alert(window);  // "undefined"
    var window = window;
})();

なぜなら、Javascriptでは、変数の宣言は、関数の最初に行われるからだ。

[] == ![] // true

[] == falseの結果は、trueになるので、言語的には正しいのだが。

// alerts 111111111111111110000
alert(111111111111111111111);

浮動小数点は常にジョークの対象になる。

訳の分からないJavascriptのコード

wtfjs: I’m certain that this will end all debate about where curly braces belong… right?

function laugh_undefined()
{
  return
  {
    haha: "ha!"
  };
}
laugh_undefined();
// returns undefined
 
function laugh_okey() {
  return { haha: "ha!" };
}
laugh_okey();
// returns Object: { haha: "ha!" }

そんなバカな。期待と違う動作をするではないか。しかも、まともな解説がない。

I’m certain that this will end all debate about where curly braces belong… right?

とあるだけだ。

ここは、私が持っている唯一の能力である、「規格を読む程度の能力」を発揮する時だ。さっそく規格にあたろう。

まず、何が問題なのか。私は、この二つの関数が、全く同じように動作し、どちらも、オブジェクトを返すことを期待している。それなのに、laugh_undefinedの方は、undefinedを返す。これは一体どういう事なのか。

まず、{ haha: "ha!" }というexpressionだが、これは、規格では、Object Initialiserと呼ばれている。これは、改行があろうとなかろうと関係がない。

まてよ、もしかしたら、{}をBlock statementと解釈しているのではあるまいか。規格を調べたところ、果たして、名前通りの、Block statementは存在した。いやしかし、もしこれがBlockと解釈されているのなら、haha: "ha!"、は、文法エラーである。しかし、どのブラウザも、文法エラーを指摘しない。ということは、どちらも、Object Initialiserと解釈されているはずだ。

とにかく、return statementは、もしかしたら、expressionではなく、statementを期待しているのかもしれない。そうであれば、Blockが優先されるはずだ。ブラウザが文法エラーを出さないのは、単に実装の問題なのかもしれない。さっそく、return statementを調べよう。

return [no LineTerminator here] Expressionopt ;

[no LineTerminator here]というものが気になる。これはなんだ。

If the phrase “[no LineTerminator here]” appears in the right-hand side of a production of the syntactic grammar, it indicates that the production is a restricted production: it may not be used if a LineTerminator occurs in the input stream at the indicated position. For example, the production:

ReturnStatement :
    return [no LineTerminator here] Expressionopt ;

indicates that the production may not be used if a LineTerminator occurs in the program between the return token and the Expression.

なるほど、return statementでは、returnとexpressionの間に、改行があってはならないらしい。いや、mayなので、改行があってもいいのだろう。ただし、expressionを省略したことになるだろうが。

そして、return statementのexpressionが省略された場合は、"If Expression is omitted, the return value is undefined."となるので、undefinedが返される。

ちなみに、セミコロンを省略してもよい理由については、本の虫: Javascriptで改行が特別な意味を持つケースを参照のこと。

JavascriptはC++より難しい。

でも、規格は、C++より読みやすいと思う。すぐに理解できた。

wtfjsに掲載されているコードは、どれも非常に興味深いので、Javascriptプログラマは、ぜひ一読しておくことをおすすめする。

追記:昔、入門用に買ったオライリーを引っ張り出してきたら、return文に改行を書くと、セミコロンが補われるから気をつけろと書いてあった。さすがオライリーだ。しかし、これは重要だ。とすると、およそJavascriptの入門書なら、必ず書いておくべきであり、すべてのJavascriptプログラマは、これを知っているべきである。知らなかったのは、ひょっとして私だけなのだろうか。Javascript、怖い言語だ。

2010-02-16

世界の書籍展なるものがあるらしい

いつものようにジョギングをして、帰ってシャワーを浴びたら、無性にポカリスウェットが飲みたくなった。早速、近所のスーパーへ、買いに出かける。変える途中、ふと、一枚の張り紙が目に付いた。曰く、「世界の書籍展」

面白そうだと、帰ってググッたところ、どうも、あまり面白くなさそうな事が判明した。

まず、Flashだけで構築されたサイトが出てきた。Accessibilityという単語は、彼らの辞書にないらしい。

次に、主催が創価学会だ。なんだか、極端にうさん臭くなってきた。まさか法華経の展示会じゃあるまいな。

内容というのは、珍しい本を展示しているだけらしい。なんだそれは。本の価値は読めることにあるのだ。展示してあるだけの本には、何の価値もない。

行くのはやめておこう。

Japan sucks

asahi.com(朝日新聞社):光和コンピューター、電子書籍市場参入を示唆、書店でダウンロード販売 - e-ビジネス情報(提供:BCN) - デジタル

010年は「電子書籍元年」といわれる。米アマゾンの「Amazon Kindle」やソニーの「Sony Reader」をはじめ、多くのベンダーが電子書籍専用端末を発売。直近では米アップルがiPadを投入し、混戦模様の情況を呈している。そんななか、出版業界向けシステムを手がける光和コンピューター(柴崎和博代表取締役)は、他社とは一線を画する手法で市場に乗り込もうとしている。

同社が発売を検討している電子書籍専用端末は、試作品を台湾メーカーが製造。スマートフォン程度のサイズで、簡単に持ち運びできる形状だという。ユニークなのは販売方法で、電子書籍をダウンロード購入する場所を書店に限定する。現段階で詳細は明らかになっていないが、同社はこの販売形態を出版社や書店に働きかけていくという。

米アマゾンや米アップルのように簡単に書籍をダウンロードできる仕組みは、書店からの反発が強い。出版社の警戒感も強く、電子書籍に積極的とはいえない状況だ。

街の書店は地域の文化センターであり、書店がなくなることは文化の衰退を意味する」。柴崎代表取締役は、紙媒体の書籍の重要性を強調する。書店と出版社の両方が利益をあげる仕組みを構築する必要があるという。今後は、紙媒体と電子媒体で、市場の住み分けが起きるとみている。同社は書店経由の書籍販売を維持しつつ、電子書籍の利便性を享受できる商流を描こうとしている。

Don't you have the fuckingest clue what you are talking about?

Why some people loves ebook? Why some pirate bastards illegally download contents from the internet? The Money? No, because it's easier. What they need is just a few clicks and things done. They'll get their book.

On the other hand, people who doesn't use ebook, must driving miles away to go to the local book store, looking for a book(you have no google at the book store), purchased it, and again, drive miles to go back your home. What a waste of time!

So what is the point about this piece of shit that doesn't do the goddamn things they fucking supposed to?

That isn't the bloody ebook. The Japan is dead. Stone Fucking Dead. The Japan is no more. It has ceased to be.

書店といえば、アマゾンだって書店であることにはかわりはないわけだ。なぜこの御時世に、物理的な店舗を介してebookを買わなければならないのか。現在、米屋、酒屋、塩屋などという専門店は、ほとんど存在しない。書籍の専門店は、いつまで庇護の下にいるつもりなのか。

でも私は、米は米屋で買っている。その場で精米してくれるから、スーパーで精米済みのものを買うよりうまい。

2010-02-15

chrome 5 beta の font-family の規定値が serif になってるのが気に入らない

chrome 5 beta の font-family の規定値が serif になってるのが気に入らない - 雑用系

同意する。すべてのサイトは、私の愛する、あのフォント(お好みのフォント名でご置換ください)になっているべきだ。

あと、font-weightやfont-styleをいじるサイトも気に入らない。たとえ英文であっても、読みにくくて仕方がない。

しかーし!

@font-faceで、既存のフォント名を上書きするのは気に入らない。だいたい、フォントなんて星の数ほどある。いちいち上書きしていられない。

では、ユニバーサルセレクタと!importantを使うべきか。しかし、いざという時に、簡単に有効、無効を切り替えられなければ困る。

というわけで、extensionだ。

まず、manifest.json。

{
        "name": "Disable Ugly Font",
        "version": "1.0",
        "description": "Disable bold and italic",

        "permissions": [
        "http://*/*",
        "https://*/*"
        ],

        "content_scripts": [
                {
                        "matches" : [
                                "http://*/*",
                                "https://*/*"
                        ],
                        "js" : ["disable-ugly-font.js"],
                        "all_frames" : true
                }
        ]
}

次に、disable-ugly-font.jsだ。

(function()
{
 var style = document.createElement("style") ;
        style.setAttribute("id", "hito-disable-ugly-style") ;
        style.appendChild( 
                document.createTextNode( "* { font-face : 'メイリオ' !important ; font-weight : normal !important ; font-style : normal !important ;}" ) 
        ) ;

        document.getElementsByTagName("head").item(0).appendChild(style) ;
})();

最後に、無効にするブックマークレット。これは、ブックマークとして追加する。

javascript:(function(){
    var style = document.getElementById("hito-disable-ugly-style") ;
    if ( style )
        document.getElementsByTagName("head").item(0).removeChild(style) ;
})() ;

あとは、このextensionを読み込めばいい。

Unicodeの歴史

2009-04-19 - 未来のいつか/hyoshiokの日記 そろそろUnicodeについて一言いっておくか
2009-04-19 - 未来のいつか/hyoshiokの日記 プログラマのための文字コード技術入門を読んだ

興味深い。

日本はいい加減に、\をなんとかせい。今、\が円マークに見えている人がいるならば、私と同じ被害者である。

2010-02-14

こんな夢をみた「スキー」

こんな夢をみた。

私はスキー場に来ていた。どうやら、いまからスキーをするらしい。私と一緒に滑る外人が一人いた。どこの国の人かは、分からなかった。

我々は揃って同じリフトに乗った。私は外人に、日本語と英語で話しかけてみたが、通じないようであった。外人は、私の知らぬ言語で、ひっきりなしに、何事かを話してきた。言葉は分からないが、とりあえず日本語で答えておいた。

さて、リフトでスキー場の頂上にあがった。ふと気がつくと、私はスキー板を履いていなかった。どうやら、ついうっかり忘れてきてしまったようだ。スキー場に来て、リフトで上まで上がりながら、スキー板を忘れるというのも、よくよくありえない話である。しかし、夢の中の私は、ついうっかり忘れてしまったという、軽い心持ちで済ませていた。

さて、スキー板がなくては、スキーをすることはできない。仕方がないので、一度、リフトで下って、スキー板を持ってこようかと、リフトに乗りかけた時であった。突然、けたたましい車のエンジン音が響いた。見ると、あの外人が、車を空吹かししているではないか。一体、雪山の上のどこに車があったのか。タイヤチェーンを装着しなくても大丈夫なのか。いや、たといチェーンを装着していたとしても、この積雪と急斜面では、車など役に立たないのではないかという、私の疑問をよそにして、外人の車は、急発進した。ふもとから、私のスキー板を持ってきてくれるのだろう。

車は、急斜面の雪山を、文字通り、転げ落ちて行った。私はといえば、「よーやるわ、あの外人さん」といった心持ちで、見送っていた。

しばらくすると、まるでふもとからカタパルトで射出されてきたように、車が吹っ飛んできた。しかし、私のスキー板はなかった。どうも、話が違うらしい。直接ふもとに行って確かめようと、私も車に乗り込んだ。車は、再び、急斜面を転げ落ちて行った。

さて、ふもとに着くと、私の母親がやってきた。何でも、預けてあるスキー板を受け取るには、印鑑がいるらしい。さらに、必要な書類に記入して、身分証明証を持参して、しかも戸籍と住民票まで取らなければならないらしい。

私は説明を聞きながら、よくも母親は、こんな複雑な手続きを理解できるものだと考えていた。まあしかし、母親は、この手の手続きに慣れている人である。それを考えれば、特に不思議もないのだ。

ここで目が覚めた。一体、この夢は何を暗示しているのだろうか。

Google Buzzは、Gmail上に構築したのがまずかった

Watch Out Who You Reply To On Google Buzz, You Might Be Exposing Their Email Address
Google Buzz Abandons Auto-Following Amid Privacy Concerns

デフォルトの設定である、followersとfollowingを公開していると、メアドが駄々漏れでまずい。今すぐ無効にするべき。

@名前 という記法を使うと、オートコンプリート機能が働いてまずい。

CSSをやりすぎた

a:hoverの際、背景色を変更するようにしているが、丸角を使ってみたくなった。

まてよ、せっかくだから、文字サイズを大きくしてみるのも、面白そうだ。

その結果、こうなった。このブログのリンクにマウスカーソルを当てると、面白いことになる。これは、人によって好みがあると思う。続けるかどうかは未定。border-radiusはともかく、マウスカーソルの当たっている要素の背景色やフォントサイズを変えるのは、別に目新しい機能ではない。そういうサイトが少ないというのは、あまり好まれないのだろうか。わたしは、マウスカーソルを当てているリンクの背景色が変わってくれた方が、分かりやすくていいのだが。

ちなみに、一番上のナビバーは、インラインフレームで実装されているため、変わらない。

アイスが嫌いな人なんていないよね?

DOGHOUSE | Google Buzz Trick

C++0x本:ライブラリは難しい

ライブラリを網羅的に解説することはできない。たとえば、vectorの全メンバーをいちいち説明することは、できない。量が膨大すぎるからだ。ではどうするか。思うに、ライブラリを使うにあたって、理解しておかなければならない、概念を説明するべきだと思う。

そもそも、コンテナとは何か、イテレーターとは何かという、概念を説明すれば、そのライブラリを使うのは、容易ではないだろうか。

私の経験では、ライブラリの全メンバーを列挙している本が、役に立ったためしはない。ただ全メンバーを列挙しているだけなら、規格書とか、コンパイラの提供するリファレンスを読めばいい。私は、個々のメンバーの解説を読んでも、STLの使い方を理解することはできなかった。

必要なのは、概念の解説だ。

概念の解説なら、冗長にならないとはいえ、やはり、すべてを解説することはできない。では、何を解説するのか。

まず、イテレーターやコンテナは必須だろう。関数オブジェクトと、それに付随するfunctionやbindの説明も必要だ。

また、ライブラリを使うにあたって、最低限しておかなければならないこと。たとえば予約語とか、std名前空間の利用だとかについても、一言書いておかなければならない。

<cstddef>や、<cstdint>は、網羅的な解説になってしまうが、これは必須だ。std::size_tとは何か、とか、int8_t, int32_tなどの整数型は、説明しておかなければならない。numeric_limitsも、できれば解説したいが、ページ数を考えると、難しい。

<algorithm>はどうだ。<algorithm>の個々の関数を解説するのは、ページ数の関係上、難しい。しかし、イテレーターを解説する以上、<algorithm>の概念は、解説しなければならない。

Move Semanticsと、それに付随する、move()/forward()は、必ず解説しなければならない。

スマートポインターも、概念を解説する必要がある。unique_ptrは、auto_ptrより使い易い。

例外安全も、概念だけは、解説しておいた方がいいだろう。

いろいろ悩んだ挙句、threadやatomic関係のライブラリは、現時点では、解説しないことにした。これには相当の批判がでるだろうが、理由がある。およそ、スレッドやconcurrencyは、数百ページ程度で説明できるものではない。それだけで一冊の本が書ける。浅く紹介だけしておくのはどうかという意見もあるだろう。しかし、

「はい、std::threadで、こんなふうに書けば、スレッドが作れますねー。はい、これでおしまい」

とか、

「std::atomicを、こんなふうに書くと、同期できます。ん? 同期って具体的に何かって? 余白が足りないので説明できませーん。あしからず」

などといった解説が、果たして何の役に立つというのか。

その他、付録として、演算子の優先順位の表と、互換機能の一覧が必要だ。

果たして、ページ内に収まるだろうか。

Google Buzzだけに対するフィードが欲しい

自分のGoogle Buzzに、Bloggerを繋げたはいいが、このままでは、このBloggerにFeed listとして貼りつけても、主に、このブログの投稿が見えるだけだ。

もっとも、既存のサイトをつなげて、まとめてFeedにするGoogle Buzzの理念からすると、Buzzの投稿だけのフィードというのは、変なのかもしれない。

Twitterような馬鹿げた制限がないだけ、Google Buzzはマシだが、やはり私は、Micro Bloggingより、普通のブログのほうがいい。

Google Buzzとサイトを繋げる方法

自分のサイト内のページに、rel="me"属性を付加したアンカーを、自分のGoogle Profileに対して張ればいい模様。

仮に、BloggerがGoogle Buzzに対応していなかったとする。その場合、たとえばサイドバーのProfileにでも、以下のようなHTML片を貼りつけておけばいい。

<a red="me" href="http://www.google.com/profiles/自分のGoogle ProfileのID">俺のGoogle Profile</a>

まあ、そのサービスが、HTMLを張り付けられればの話だが。

実際、すべてのWebサービスは、ユーザーに、小さなHTML片やJavascriptを使えるようにすべきである。

笑いたいけど笑えない話

Sorting it all Out : How Windows 7 broke VB6's RightToLeft property, and how to get it fixed

さすがはMichael Kaplan。俺達に分からないことを平然と説明してのける。そこにシビれる! あこがれるゥ!

Windows 7で、VBのアラビア語、ヘブライ語のRTLが壊れたが、その理由を説明している。

また汚い互換性の問題が、将来に禍根を残す。

現状のshared_ptrの設計がまずい

// platform-specific handle type for resources.
typedef unsigned int handle_type ;

// platform-specific resource allocator and de-allocator function.
handle_type allocator() ;
void deallocator( handle_type handle ) ;

// user defined deleter.
struct handle_deleter
{
        typedef handle_deleter type ;
        typedef handle_type pointer ;

        void operator () ( handle_type handle ) const
        { deallocator( handle ) ; }
} ;

int main()
{
        // allocate a resource.
        // because of deleter, 
        // unique_ptr< handle_type, handle_deleter >::pointer is type of handle_type.
        // Not the handle_type *
        std::unique_ptr< handle_type, handle_deleter > handle( allocator() ) ;

        // move a resource to shared_ptr.
        // ill-fomed.
        // Because shared_ptr expects handle_type *.
        std::shared_ptr< handle_type > ptr( std::move(handle) ) ;
}

これはまずい。unique_ptrと違いすぎる。これでは、自前デリーターが使えない。

shared_ptrは、unique_ptrに合わせるべきではないだろうか。

しかしその場合、現行のshared_ptrにある、便利でType Erasureなデリーター指定が使えない。難しいものだ。

正しい方法じゃないなぁ

boost::shared_ptrでHMODULEなどを管理する - ベイダー日記

これが動くのは、そもそも、HMODULEが、ポインター型であることを前提としている。HMODULEがポインターであることを隠すために、わざわざHMODULEという名前を使っているというのに。このコードは、ポータビリティに問題があると言える。

unique_ptrならば、こんなことができる。

struct HMODULE_deleter
{
        typedef HMODULE pointer ;

        void operator () ( HMODULE handle )
        {
                FreeLibrary( handle ) ;
        }

} ;

int main()
{
        std::unique_ptr< HMODULE, HMODULE_deleter > handle( LoadLibrary( _T("kernel32.lib") ) ) ;
}

なぜならば、unique_ptr<T, D>は、remove_reference<D>::type::pointerが存在する場合、unique_ptr::pointerは、その型になるからだ。

しかし、残念ながら、これは現行のshared_ptrには使えない。shared_ptrは、unique_ptrを引数に取るコンストラクタを提供している。しかし、unique_ptrのこの機能を提供していないということは、デフォルトのデリーターを使っていないunique_ptrからは、初期化できなくなってしまう。

なぜ、shared_ptrも、デリーターをテンプレート引数に取らないのだろう。いまなら、意見を言えば間に合うだろうか。

追記:よく考えたら、remove_referenceに通しているわけだから、typeはいらなかった。

これはすごい歌だ。

こんな歌はどうだと勧められた。

なんという歌だ。これはすばらしい。私はこのような言葉遊びが大好きなのだ。

Major-General's Song - Wikipedia, the free encyclopedia

ちなみに、こんな替え歌もある。言語記号の周期表。

いい機会なので、面白い英語の歌を挙げてみる。

Oliver Cromwellの歌。John Cleeseは素晴らしい歌手だ。

まさに杞憂という言葉がぴったりの歌。

我愛中國人

金だ。世の中は金だ。欲しくてならぬ。

勇気の出る歌。

うほっ、いい男。

宇宙の歌。普通に歌としてもいい歌。

すべての精子は神聖なり。

万物はすべてクソだ。一体誰ぞ我らをかくは作りたもうたか。そうだよ、奴だよ。

ランサロット卿ほど勇敢ではなく、ドラゴンと戦いそこなったこともあり、ブリストルの弱者を守るために立ち上がろうと思った事もあり、バードン丘の戦いではションべんちびったこともある、ロビン卿の物語。

ジャズ?

2010-02-13

Javascriptのメモリリークを防ぐ方法

Memory leak patterns in JavaScript

たまたま読んだのだが、これが完結簡潔で、しかも非常によくまとまっていていた。

VS2010 RCが恐ろしく単純なコードでクラッシュする件

int main()
{
    typename(
}

このコードで、typenameに続く、開括弧を打った瞬間に、"Microsoft (R) Visual C++ Package Server"なるプロセスが、延々とクラッシュし続ける。

どうやら、テンプレートではない、普通の関数の中で、"typename("と打つと、100%の再現率でクラッシュするようだ。

一応、バグ報告したが、一体どういうテストをしているのだろう。

追記:

どういうテストを行えばこの問題が (RC ビルドの) リリース前に判明したか

テンプレート関数ではない、普通の関数の中で、typenameを使うこと自体が、ill-formedなので、難しいと思う。well-formedなコードなら、いくらでも自動的に生成できるかもしれないが、ill-formedなコードで、このような問題を引き起こすコードを、自動的に生成するのは、難しいのではないか。

ちなみに、私がこれを発見した理由というのは、typeidを、ついtypenameと、typoした為だった。その瞬間、ワトソン博士が大激怒(厳密にいうと、Vistaにはもう、ワトソン博士はいないのだけれど)。たまたま、MPLを変態的に使ったコードを書いていたため、問題を狭めて特定するのに、少し時間がかかった。

規格を知っている者、知らない者を、それぞれ集めて、テスターとして、延々とコードを書かせ続けるのはどうか。とはいっても、他ならぬ開発環境である。ベータ版以前の社内ビルドを、試験的に使うような人間は、MS社内にゴロゴロいるだろうし、実際試していると思う。それに、人力でのテストには、作業量に限界がある。バグを発見した後から、「テストが足りなかったんじゃないか」というのは簡単だが、果たして見つけられるだろうか。

C++0xの対応具合

まだドラフト段階で、変わる可能性のある部分が多いので、それほど大胆な機能を実装することは難しい。MSVCのようなメジャーなコンパイラが、規格違反のコードを通してしまったら、後々、ひどい互換性の問題を引き起こす。実際、MSVCは、あまり規格準拠のコンパイラとはいえないのだが。

しかし、auto, decltype, lambda, rvalue reference, static_assert, nullptrが入っているので、相当、C++0xの恩恵を受けられるだろう。

それから、トライグラフが廃止された。実を言うと、完全に廃止するのは、規格違反なのだが、(まだIBMの既存のコードとの互換性の問題で、少しだけトライグラフが規格に残っている)、これはいい変更だ。もし、何らかの理由で、トライグラフを使わなければこまるというのであれば、トライグラフを有効にするコンパイラオプションがある。

それにしても、ドキュメントには書いていないものの、新しい関数宣言構文が、ひそかに入っている。これなど、どうするつもりなのだろう。Unified Function Syntaxが入るか入らないか、もめている最中なのに。

2010-02-12

JavascriptによるJPEGエンコーダー

A JPEG Encoder for JavaScript [bytestrøm]

Javascriptで実装したらしい。原文では、jpegを得るAPIがgetImageDataとなっているが、おそらく、toDataURLのはずだ。

UIをブロックしないため、Web Workerも使ってみたそうだが、データをやり取りする方法が、文字列しかないために、難儀したらしい。どうしても、相当遅くなってしまうのだとか。

しかし、SafariやChromeでは、十分に速い。Firefox? ああ、そんな奴もいたね。

C++0x本:目次案、コア言語が完成

査読者の皆様は、Google Wave上でご確認ください。

さて、問題は、「その他」だ。

最優先するのは、コア言語の解説だ。しかし、その他はどうすればいいのか。物理的なページ数の都合がある。C++0xに追加されたライブラリに限定しても、すべてを深く解説するページ数はない。どうすればいいのか。

案1:広く浅く解説する。

各種ライブラリの目的と、短いサンプルコードを列挙する。

しかし、この案の場合、各種ライブラリについて、文字通り、「その目的と、短いサンプルコードを載せただけ」の薄っぺらい内容になってしまう。私は、未だかつて、そんな駄本が役に立った覚えはない。

案2:重要なものだけ選んで、深く解説する

これは、少なくとも、そのライブラリに関しては、満足できる。しかし、何が重要なのかは、人によって異なる。たとえば、私は<type_traits>は重要なライブラリであると考えている。しかし、乱数や、正規表現のライブラリの方が、重要だと考える人もいるだろう。あるいは、スマートポインタの方が重要かもしれない。いやしかし、なんといっても、std::vectorは重要だ。なにしろ、自分でわざわざrealloc()しなくてもいいのだから。

こう考えて行くと、「重要なもの」などという事は、選ぶことができない。一体どうすればいいのか。

案3:テクニックや概念を解説する

1を聞いて10を知る人間は存在しない。いくらリファレンスについて学んでも、move semanticsを思いつく人間はいないだろう。もし、そんな人間がいるとしたならば、そのような人には、本書は必要ない。規格書を直接読めば足る。Move Semanticsは重要だが、他にも、たとえば例外安全のような概念とテクニックもある。単に個々のライブラリを解説するのではなく、このような、概念やテクニックを説明するのはどうか。

単純にvectorの使い方を説明するのではなく、コンテナとは何か。イテレーターとは何かということを説明する。これは、私がC++を学んでいる間、本当に欲しいと思っていた本だ。そんな本は存在しなかった。どの本も、vectorをどのように使うかとか、その全メンバーを列挙してこれはこうだなどということは書いてあるが、イテレーターとはそもそも何ぞや、という事には、わずかなページ数しか割いていなかった。

テクニックと概念の説明にページを割くべきか。

また、これとは別に、通常のコンテンツのフローに、うまく溶け込めない説明というのがある。たとえば、演算子の優先順位だ。たとえば、属性のかける場所一覧だ。このような早見表を、Appendixとして、巻末にいれるのはどうだ。

とにかく、考えなければ。

Google Buzzで情報流出っていってるけど

あのアカウント設定の名前とか、今までも、見ようと思えば見れた気がするのだけれど。プロファイル部分は、以前からあったはずだ。

いまさら?

2010-02-11

Akinatorがすごい

Akinator, the Web Genius

質問に答えるだけで、考えている人物を当ててくれるというサイト。あらゆるジャンルからのキャラクターがそろっている。そして、どうやら、学習しているらしい。

たとえば、東方の射命丸文を一発で当てた。

他にも試してみたが、Michael JacksonやLady GaGa、中島みゆき、あたりの有名歌手は、一発で当てた。

Carole Kingは、なかなかうまくいかなかった。何度も続けた("go on")あげく、答えを聞いてきた。carole Kingを試す人が増えれば、精度が上がるかもしれない。

Visual Stdio 2010 RCが公開された

Visual Stdio 2010 RCが公開されたので、早速インストールした。

今回、どうもIDEがWPFで実装されているらしい。つまり、IDEに大量のコモンコントロールが描画されているように見えるが、ウインドウではない。

このため、System Requirementsにも、"DirectX 9-capable video card that runs at 1024 x 768 or higher display resolution"と書いてある。

いまどき、まともなCPUとともに、シェーダーの動くまともなGPUを積むのは当たり前であるから、これはいい実装であるといえる。

気のせいか、フォントの描画が変わっている気がする。また、Consolasを選択したのだが、指定したフォント外の文字を描画するのに使うフォントの選び方も変わった気がする(私の環境では、メイリオが選ばれた) WPFで実装しているためだろうか。

パフォーマンスが格段に良くなっている。Beta2は本当にひどかった。インテリセンスのパフォーマンスも上がっているし、<functional>をincludeしても、インテリセンスが動かなくなるなどということはない。

悪くない。なかなか悪くない。

さて、Javascriptも試してみたが、相変わらず、Javascriptのインテリセンスは、DOM level 2すら、まともにサポートしていない。まあ、自社製品のIE(笑)があれだから、どうしようもないのだろう。クソだ。

インテリセンスがDOMに対する補完をまともにサポートしてないことを除けば、Javascriptのエディタとしても、悪くはない。すくなくとも、自分の書いたコードに関しては、補完が効く。

しかし、世のJavascriptプログラマは、一体どんなエディタを使っているのだろう。

Google Buzzの感想

Google Buzzが使えるようになった。その感想を書いておく。

もちろん、あのgoogleのことだ。ミニマリズムではあるが、低機能ではない。

まず、Twitterのように、発言ができる。まあ、当然だ。では、Twitterと比べて、どんな機能を提供しているのか。

既存のWebサイトとの、相互のやり取りができるということだ。とくに、既存のWebサイトを、自分のGoogle Buzzにつなげられる機能がある。たとえば、自分でつぶやく他に、Google Readerのpublicなタグを流すだとか、Bloggerの記事を流すだとか、Picasaのアップデートを流すことができる。他にも、TwitterやFlickerやYouTubeもつなげられる。

もちろん、Google Buzzは、フィードを提供しているので、そのままGoogle Readerに放り込むこともできる。

Google Buzzの検索は、もちろんできる。

少なくとも、Twitterよりは気にいった。

Ryou Ezoe - Google Profile

誰が買うのだろうか

【楽天市場】純粋なゴールド 24金からできたインク 79ink ゴールドインク 象牙つけペンセット:ナガサワ文具センター

24金のインク。柘植製作所の21金つけペン付き。お値段は、価格500,000円 (税込 525,000 円) 送料込。

しかし、ほんのすこしだけ欲しくなってしまった。まあ、私は70mlで280円の開明墨汁と、ひとつ80円程度の日本字ペンのニブで満足だ。

2010-02-10

Variadicとは何ぞや

C++0xには、Variadic templatesなるものが存在する。あえて訳すとしたら、可変テンプレートか、可変引数テンプレートあたりだろう。

この引数には、仮引数や実引数のような、厳密な区別はいらないだろう。

しかし、Variadicという単語は、どこから来たのだろう。意味は分かる。variableから来ているに違いない。意味はわかるが、念のため、辞書で確認しておこう。

載っていない。辞書に載っていないとはどういう事だろう。variadicは、プログラミングでは、非常に有名な言葉だ。これが載っていないとは解せない。

-icというのは、ofとかlikeという意味の接尾語である。日本語にも、~的という都合のいい接尾語がある。では、dはどこから来たのか。単に発音上の都合なのだろうか。

さっぱり分からなかったので、ネイティブに聞いた。どうやら、variable + -ad + -ic らしい。

-ad - Wiktionary

しかし、なぜ-adなのか。それは、adicityから来ているのだ。

adicity - Wiktionary

adicityとは、「引数の個数」という意味である。これは、-ad + -icity を組み合わせた単語だ。つまり、ちょうど意味が似通っていたために、ここから借りて、variableと組み合わせて、造語としたらしい。

C++0x本:データメンバーかメンバー変数か

一般に、我々がメンバー変数と呼ぶところのものは、規格では、Data memberと呼ばれている。さて、これをどうしたものか。

しかし、ググッてみたところ「データメンバー」という用語も、かなり広く用いられている。メンバー変数でなくてもいいだろう。

GoogleのTwitterサービスは遅きに失するのではなかろうか

GoogleがTwitterと同等のサービスをはじめるという話だ。しかし、遅きに失するのではなかろうか。

私はMicro bloggingのすばらしさを理解できないが、今日のTwitterの興隆をみるに、価値があるとは認めなければならない。

たしかに、Googleのインフラを使えば、より高速で安定したTwitterサービスを提供できるかもしれない。遅延もないし、サーバーも落ちない。しかし、人気が出るかどうかは、また別の話である。

思うに、Twitter文化は、制限が強く、機能が劣っているからこそ、発展したのではないかと思う。たとえば、このBloggerは、一日中書き続けた文章量であろうと、問題なく投稿できる。当然だ。いまどき、テキストぐらい、実用上、無制限に書き込めなくては困る。しかしTwitterは、たったの140文字しか書き込めない。これは技術的に考えても、不必要な制限だ。しかしこれが、Twitter独特の文化を発展させてきたのである。

具体的には、文章だ。一投稿あたり、140文字しか書けないので、できるだけ短く書こうとする。これは、Micro bloggingの理念と一致する。

短く書くために、URLの短縮サービスが多用される。「私は今、うどんを食べています。」というかわりに、「うどん食べてるなう」で済ませる。「私はJavaがこの地球上でとてつもなく大嫌いです」というかわりに、「Java爆発しろ」で済ませる。「文句をいう、嫌う、遺憾の意を示す」などというかわりに、「disる」で済ませる。

サーバーが遅くて不安定なのも、ある意味、ネタになっているのではないだろうか。

サイトのUIが使いづらいから、専用クライアントが乱立する。

それに、ユーザーは互換性を非常に気にする。なにしろ、ユーザーはすでにTwitterを使っていて、それに慣れているのだ。Googleが、単にTwitterのようなサービスを提供しただけでは、既に構築されたTwitterの牙城を崩すことはできない。

それに、より高機能、高品質なサービスを提供すればいいのならともかく、Twitterは、低機能、低品質であることが、独特の文化を育む要因になっているのだ。たとえGoogleといえども、これに打ち勝つのは、かなり難しい。

2ちゃんねるも同じだ。今、Googleが2ちゃんねるのような掲示板サービスを始めたとする。Googleのインフラを使えば、2ちゃんねるよりサーバーが高速で安定しているであろう。しかも、画像のアップロードのような、付加機能を提供できるだろう。しかし、2ちゃんねるには勝てない。滅びの呪文「バルス」で鯖落ちしない強靭な2ちゃんねるに、何の価値があるというのか。

2ちゃんねるも、専ブラ(専用ブラウザ)という名の、専用クライアントが乱立している。

専用クライアントというのも、面白い文化だ。たとえばGoogle Waveだが、私の予想では、ブラウザのUIより高機能で実用的な専用クライアントは、開発されないだろう。携帯向けなどの、機能を制限しても問題ない、専用クライアントは出るだろうし、現に出ている。しかし、Google Waveの専用クライアントとなると、ブラウザと同じぐらいの大規模なものになってしまう。これは、到底個人の手におえるものではない。

一方、Twitterの専用クライアントや、2ちゃんねるの専ブラは、個人で開発できる規模である。サービスが低機能だからこその規模なのだ。

世の中は、最良のものが常に使われるわけではない。

2010-02-09

HTML5で規定されている、li要素のvalue属性をサポートしているブラウザがない

最近、私はコードを書くとき、常に規格書を参考にしている。というのも、規格書が一次ソースであるからだ。参考書は二次、三次ソースである。規格書が間違っている可能性は、参考書よりも低いと考えられる。わざわざ間違っている可能性の高い参考書を参照したくはない。

しかし、ことWeb関連の規格に限っては、規格書は全く当てにならない。まして、HTML5は、現実の実装を元に規格を回ているのである。本来とは順番が違うのだ。

HTML5 li elementによると、ol要素の子であるli要素は、value属性を持ち、その値は、要素に対応するリスト番号であるという。

しかし、Chrome, Firefox, Opera, Safariは、このvalue属性をサポートしていなかった。IEはテストしていないので分からない。

この属性は、非常に便利だと思う。querySelectorなどで取得したli要素の番号を取得できるのだ。ところが、主要なブラウザはサポートしていないではないか。

あるいは、deprecatedな属性なのだろうか。しかし、HTML5の規格にある以上は、実装して欲しい。

幸い、今の私のドキュメントでは、CSSでリストの番号をいじるようなことはしていないので、親に対して、何番目のli要素であるかを調べるだけで足る。XHTML限定のコードは、以下の通り。

// calculate nth child element from parent node.
function calculate_nth_li( element )
{
        var parent = element.parentNode ;
        var value = 0 ;
        for ( var i = 0 ; i != parent.childNodes.length ; ++i )
        {
                var node = parent.childNodes.item( i ) ;
                if ( node.nodeType == node.ELEMENT_NODE && node.nodeName == "li" )
                {
                        ++value ;
                        if ( element.isSameNode( node ) )
                                return value ;
                }
                
        }
        // shall not reach here.
}

親に対して、何番目のノードの子であるかを取得する方法が、DOMで規定されていれば便利だろう、と思ったが、考えてみれば、ノードは、要素だけとは限らない。テキストとかコメントなどもある。現実的には、あまり役に立ちそうもない。

コメントで、Element Traversal SpecificationというすばらしいDOM規格があることを教えてもらった。さっそく、これを使って上記の関数を書き直した。

function nth_child_element( element )
{
        var n = 1 ;
        var iter = element.parentNode.firstElementChild ;
        while ( !iter.isSameNode( element ) )
        {
                ++n ;
                iter = iter.nextElementSibling ;
        }

        return n ;
}

コードを簡潔にするため、li要素かどうかの判定はなくした。なぜならば、規格準拠のXHTML5では、ol要素の直接の子は、かならずli要素でなければならないからだ。このコードは、私の書いたドキュメントにしか適用しない。そして私は、常に規格準拠のXHTMLを書くよう心がけているので、全く問題はない。

冷静に考えれば、Element Traversalと同等機能は、DOM level 2 coreを使って、自前で実装することもできる。しかし、このような単純なものは、標準にあった方がいい。

Frog Fail

よくこんな瞬間を撮れたものだ。

MSVC曰く「decltypeはoperator(キリッ」

          ____   
       / \  /\ キリッ
.     / (ー)  (ー)\      
    /   ⌒(__人__)⌒ \    
    |      |r┬-|    |      MSVC曰く、「decltypeはoperator」
     \     `ー'´   /      
    ノ            \
  /´               ヽ              
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.    
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))


          ____
        /_ノ  ヽ、_\
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)
| / / /     |r┬-|    | (⌒)/ / / //  だっておwwwwwwwwwwwwwwwwwww
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/    type specifierにきまってるおwwwwwwwwwwwwwww
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー'´      ヽ /    /     バ
 |    |   l||l 从人 l||l      l||l 从人 l||l  バ   ン
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、    ン
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

Expressions with Unary Operators
decltype Operator

うーむ? MSVC的には、decltypeはoperatorなのか。type specifierだろうに。

Simple Type Names

やばい、本当にoperatorだと信じているようだ。type specifierの項目には載っていない。そもそも、namesじゃなくてspecifiersであるべきなのだが、なんだこのドキュメントは。

しかし、もし本当にdecltypeがoperatorだとするならば、expressionである。とするならば、

decltype( decltype(0) ) ;

このコードはコンパイルが通るはずである。なぜならば、decltypeは、decltype(expression)という文法だからだ。decltypeは、type specifierを取ることはできない。したがって、decltype(int)というのは、ill-formedであるように、decltypeの中にdecltypeを記述することはできない。しかし、もし本当に、MSVCがdecltypeをoperatorだと考えているならば、できるはずである。

果たしてVC10Beta2では、通らなかった。しかも、

error C3553: decltype expects an expression not a type

というエラーメッセージまで出すではないか。decltypeはexpressionではないのだから、これは規格準拠で当然だ。しかし、このドキュメントはなんだろう。

まともに規格通りのドキュメントが書けないから、コンパイラもマヌケな事になってるんじゃないか。

それはそうと、VS2010のRC版が、明後日あたりに公開されるらしい。

2010-02-08

C++0x本:オーバーロード鬼門すぎる

direct reference bindingなど、どう訳せばいいというのだ。どう訳したって、日本語として不自然になるに決まっている。

そういえば、この際に言っておくと、私は、共用体や列挙型も、あまりいい訳だとは思っていない。unionとenumはどうすればいいのか。それこそ、unionやenumとそのまま書いてもいいのではないか。結局、これらはキーワードなのだから。

しかし、unionやenumでは、やはりまずい気もする。難しい。

C++0x本:ellipsisについて

void f(...) ;

この...を、ellipsisという。ellipsisとは、英和辞書的にいえば、省略とか、リーダーと訳される。

しかし、世間一般には、可変引数リストという名称も用いられている。これは、...自体の名称としては、あまり適切ではない。おそらくは、K&Rの邦訳の、printfの実装例で、可変引数リストと書いてあるのが、そのまま用いられているのではないかと思われる。

邦訳のK&Rの、言語の定義では、省略形という言葉が用いられている。さて、どうするか。

conversion functionとuser-defined conversionの違い

conversion functionとは、operator type() の形で定義される関数のことである。

user-defined conversionとはconversion functionに加えて、コンストラクターも含まれる。

オーバーロードが不安になってきた

果たして、私はオーバーロードを詳細に解説できるだろうか。オーバーロードは理解しているつもりである。しかし、オーバーロードを解説となると、これは難しい。

いつも通り、訳語は問題だ。たとえば、candidate functionsだ。候補関数だろうか。関数の候補だろうか。あるいは、候補関数群とか、候補関数集合というのが、最も正しい訳語であるように思われる。数学には疎いので、群や集合という言葉が適切かどうかは分からないが、とにかく、ひとつ以上の集合というニュアンスが含まれている。これは、オーバーロードで呼び出すべき関数の候補のセットなのだ。

Viable functionsという用語も、また難しい。Candidate functionsというのは、シグネチャさえ一致すれば、選ばれる。たとえば、

void f(int) ;
void f(int, int) ;
void g(int) ;

int main()
{
    f(0) ;// この式でのCandidate functionsは?
}

この式での、Candidate functionsは、f(int)とf(int, int)である。f(int,int)は、f(0)という式では、f(int,int)は呼び出せない。しかし、Candidate functionsとして選ばれる。g(int)は、選ばれない。

このCandidate functionsの中で、実際に、呼び出すことのできる関数を、Viable functionsという。f(0)という式では、f(int, int)を呼び出すことができないので、Viable functionsは、f(int)だけである。たとえばもし、上記のf(int, int)の宣言が、

void f(int, int = 0) ;

となっていた場合、f(int, int)も、Viable functionsになる。デフォルト実引数があり、呼び出せるからだ。

つまり、Viable functionsとは、その関数呼び出しの式で、セマンティクス上、実際に呼び出し可能な関数を意味する。

Viable functionsが複数あった場合、一体どれが、最も最適な関数であるかが、決定される。この最も最適な関数を、文字通り、Best viable functionと呼ぶ。同じ程度に最適なviable functionsが複数あった場合、オーバーロード解決は、曖昧となる。

しかるに、既存の参考書は、ここまで詳しくオーバーロード解決のルールを解説していない。わずかに一ページ足らずですむ、このような解説さえ、していないのである。したがって、Viable functionsという用語に対する、既存の訳語はない。私は私の拙い詩才を以て、訳語を決定しなければならないのだ。

最も、オーバーロード解決のルールは、ユーザーに取って自然になるように定義されている。ほとんどのユーザーにとっては、ルールの詳細を知らなくても、自然に感じるはずだ。

知らなくてもいいとはいえ、規格を読む以外に、知る方法がないというのは、問題である。本書の存在意義は、規格と入門書の間の、大きな隔たりを埋めるためにある。初心者向けの、C++の入門書は、すでに数多く、世に行われているが、上級者向けの解説書は、存在しない。

C++0x本:子という接尾語

プログラミングでは、子という接尾語が多用される。たとえば識別子だ。たとえば演算子だ。私は今回、specifierに対しては、指定子という訳語を、qualifierに対しては、修飾子という訳語を用いるつもりである。

しかし、そもそも子とは何か。これは、英語の、-er, -orという接尾語に対する、直訳である。someoneとか、somethingを意味する。日本語の子も、同じような働きを持っている。

C++0x本:長音をどうするか

音訳する際に、長音をどうするかというのは、宗教的な問題である。タイガー戦車をティガー戦車と言ったり、マニアは発音にうるさい。ここでの問題は、長音記号である。プログラミングの外で考えても、プリンタなのか、プリンターなのか。非常に迷う。しかし、私の意見では、長音をつけるかどうかという議論自体がナンセンスである。長音記号をつけようがつけまいが、間違っていることにかわりはない。

つまり、コンストラクタと言おうが、コンストラクターと言おうが、関係ない。どちらも間違っているのである。正しくは、Constructorである。これ以外の表記は、皆間違っている。IPA発音記号を使えば、より正しい発音で表記できるという、理想主義的な主張もあるだろうが、通常の単語をIPA発音記号で記述するのは、全くもって現実的ではない。

しかし現実問題として、あるひとつの単語に対しては、どちらかに統一しなければならない事には、かわりはない。一冊の本で、あるところではコンストラクタといい、別のところではコンストラクターというのは、非常にややこしい。つまりこれは、はじめから正解などない問題を解決しなければならないのである。

少なくとも、やコンストラクターやデストラクターに関しては、長音記号をつける方が自然であると、私は考える。もし、最初に日本語でオブジェクト指向の概念を説明した者が、生成子とか、破棄子などという言葉を用いていれば、あるいは、このような問題に悩まされずに住んだのかもしれない。しかし、わかりやすければ(カナで表現しやすければ)、音訳するのも悪くないと考えている。

結局のところ、私は最近、規格にべったりだったので、C++を日本語で考えていないのだ。今、私がC++のコードを書く際は、英語で考えているし、コメントも英語になる。これは注意を要する。なぜならば、私は日本語の本を書かなければならないのだから。

C++0x本:Member accessとSpecial member functions

規格に準拠した目次では、クラスも、厳密に分割して教える。規格では、クラスは、主に四つの章に分かれている。すなわち、クラス、派生クラス、メンバーアクセス、特別なメンバ関数(コンストラクタやデストラクタ、初期化の詳細など)である。

本書の目的は、言語の詳細を解説することにあるので、これを分割することは、さほど問題にはならないと思う。

さあ、いよいよ問題は、オーバーロードとテンプレートだ。これは、相当に難しい。

C++0x本:Derived classes

Derived classに対して、どのような訳語を用いるかという問題がある。

C++の規格上は、サブクラスとスーパークラスという用語を用いていない。これは、他ならぬBjarne Stroustrupが、サブとスーパーでは、どっちがどっちだか分かりにくいと考えたためだ。これは、私も同意する。SubのかわりにDerivedが、SuperのかわりにBaseが用いられる。これは非常に分かりやすい。

では、どのような訳語を用いるかという問題がある。サブクラス、スーパークラスなら、このままカタカナで表記すればいい。これは、サブやスーパーという言葉が、プログラミング言語を離れても、一般的に使われているからだ。しかし、Baseはともかく、Derivedの音訳は、一般的ではない。デライブドといわれても、さっぱりわからない。

今、日本に定着している一般的な訳語は、派生クラス(Derived Class)と、基底クラス(Base Class)である。私はこの内、Base Classについては、ベースクラスでもいいのではないかと考えている。ただし、統一性を考えると、基底クラスとするのがいいかしれない。

Multiple base classはどうか。実は、規格での正式名称は、これである。ただし、注記として、一般的に、multiple inheritanceという言葉も用いられていると書いてある。multiple inheritanceは、多重継承と呼ばれている。いまさらこれを、マルチプルインヘリタンスなどと呼ぶのは、全くもって現実的ではない。それならば、multiple base classも、多重ベースクラス、多重基底クラスとなる。これは、それほど問題にならないだろう。

Virtual functionには、仮想関数という訳語がある。これは、このまま使わざるを得ない。しかし、Pure virtual functionはどうか。これには、純粋仮想関数という訳語がある。これも、このまま使わざるを得ないだろう。個々の単語は、音訳しても通じる。しかし、バーチャル関数とか、ピュアバーチャル関数、ましてや、ピュアバーチャルファンクションなどという言葉は、残念ながら、受け入れられないだろう。

Abstract classの一般的な訳語は、抽象クラスである。これは、あまり好きではないが、このまま使わざるを得ない。アブストラクトという音訳は、消して不自然には聞こえないし、ある程度使われているとは思う。しかし、アブストラクト・クラスと表記するのは、私の感覚では、慣れない。

2010-02-07

Windowsの電源オプションとWaveのパフォーマンス

Google Waveが遅い。文字入力さえストレスが貯まる。なぜ遅いのか。ブラウザが遅いのか。しかし、Chromeは、ある程度速いブラウザである。私のPCは、Core2Quadを積んでいる。なぜこんなに遅いのか。

気になったので、プロセスエクスプローラーで、表面的に観察してみることにした。

まず、CPU時間だが、これは、特に、問題ない。Chromeは、CPU時間を使い果たしているわけではない。だいいち、4コアあるうちの、1コアとて、使い尽くされていないではないか。CPUが遅いのではない。

次にメモリだ。メモリも、使い尽くされていない。余っている。

次にディスクアクセスだが、これは非常に少ない。waveを切り替えるときは、容量にして数MB単位のディスクアクセスが発生するが、waveを切り替えなければ、ディスクアクセスは発生しない。よって、ディスクアクセスが問題ではない。

はて、では、なぜこんなに遅いのだろう。CPUは十分に速いし、メモリも余っているし、ディスクアクセスは、そんなに発生していない。なぜ遅いのか。

ふと気まぐれに、Vistaの電源オプションを、高パフォーマンスにしてみた。するとどうだ、あくまで体感だが、レスポンスが向上したように思えるではないか。すると問題は、タイマーの精度とか、スレッドのコンテキストスイッチの時間だとか、そういう何かなのだろうか。以前、あんなことを書いたが、video、audioが一般的になり、WaveのようなWebアプリが存在する現在では、タイマーの精度も、重要になってくるのかもしれない。しかし、あの当時から、まだわずかに一年半しかたっていないのだが。

ああ、ありたきは、SSDをRAIDに組んだ爆速PCだ。CPU時間というは、動画のエンコードでもしない限り、もう余っている。メモリの速度は、相変わらず遅いが、容量は余っている。ディスクの容量は余っている。しかし、速度が足りない。HDDは、十年前も今も、シーク速度がぜんぜん向上していないのである。いくらシーケンシャルアクセスが向上しようと、これでは意味がない。

電話番号案内の使い方

電話番号案内は、104に電話をかけることで利用できる有料サービスである。

できることは、住所と名前から、固定電話の電話番号を引くことである。電話番号から住所を逆引きすることはできない。もっとも、固定電話の所有者が、電話帳への掲載を拒否していたならば、おそらく探せないかもしれない。

今回、電話番号案内を使う機会があったので、その使い方を解説しておこうと思う。どのようにして電話番号案内を使えばいいのか、ググッてもまったくヒットしないからだ。

まず電話をかけると、オペレーターが出る。オペレーターに住所や名前を知らせると、電話番号を教えてくれる。どうも、電話番号を知らせてもらった時点で、料金が発生するようだ。まあ、携帯からかけても、せいぜい百円ちょっとなのだが。

ちなみに、その電話番号案内を利用した理由というのが、結構、美談になる。

freenodeで、少し前に、PMが送られているのを発見した。「日本人の母親が急病になり、日本にいる親戚に連絡を付けたいが、連絡方法が分からない。連絡方法を知っているの唯一の人物は、当の母親であるが、現在、話せる状態にない。日本のオンライン電話番号案内サービスのサイトはないか」というものであった。

残念ながら、日本には、オンラインで、個人の電話番号を調べるサービスは存在しない。何が問題なのだろうか。やはり、プライバシーだろうか。しかし、電話帳や、口頭で調べることはできるのだから、オンラインかどうかなど、効率の問題でしかないと思うのだが。

ともかく、事が事なので、104を使うことにした。人間が対応するので、非常に使いやすかった。

しかし、残念ながら、肝心の情報が心もとない。日本人の母を持つとはいえ、日本語はさっぱりわからないと来ている。示された住所は不完全で、しかもローマ字表記である。名前もローマ字だ。これは、同音異義語が多い日本語において、致命的である。

しかし、住所と名前の組み合わせは、意外と、十分にユニークであった。数人調べたが、重複はなかった。なるほど、いざという時に、104は役に立つようだ。

ユニークといえば、私の名前は、完全にユニークである。おそらく、日本にひとりしかいないだろう。ただし、私は固定電話を持っていない。集合住宅に住んでいるので、部屋まではVDSLでネット回線を引いてる。面倒だったので、固定電話を取らなかったのだ。

教訓としては、いざという時の、自分の身内の連絡先は、書き記して、分かりやすい場所に置いておいた方がいいだろう。自分が話せない状態になっているかもしれないのだから。

C++0x本:conversionの訳語

現在、私は、規格のconversionに対して、型変換と言葉を当てている。しかし、あるいは変換でもいいだろうか。型変換の方が、誤解がなくていいと思うのだが。

NHKは救いようがない

NHK経営委員会|最新の議事録|第1110回

いろいろなところで講演していますが、講演して一番反応がないのは若者です。私の講演が悪いというのもあると思いますが、昔は大学の授業を聞いていて、学生が寝るということはありませんでしたが、今は授業中に寝ます。これは日本の大きな問題で、NHKもこういう問題を考えなければならないと思います。日本の未来を考えるときには、今の若者を根本的に立て直すことを考えることが必要です。カンボジアで授業をしていると、目をきらきら輝かせて聞いています。その反応と同じように彼らはテレビも見ています。日本の国際放送を見ています。それはそこから何かを吸収したいということです。バラエティーではありません。生きる糧をもらいたいと思って、発展途上国の人はNHKの国際放送を見ているわけです。日本に期待しています。そういうところにバラエティー番組を流されると、はっきり言って日本人でも腹が立ってきます。日本は、いつの間にか文明が成熟しているので、今の日本の若者の接触者率を増やさなければならないとか言っていますが、私は、今の若者に徴兵制はだめとしても、徴農制とか、徴林制とか漁村に行けとか、そういう法律で、テレビの番組も何時から何時まできちんと見るということにすればいいと思います。この番組を見なければ会社に就職させないとか、抜本的に政策を変えないと、日本は本当に大変なところへ行くのではないかと思います。したがって、そういう面でNHKの役割は非常に大きいので、許される範囲を超えるものもあると思いますが、もっときつい方策をとらなければならないところまで来ているのではないか思います。

安田喜憲 - Wikipedia

頭おかしいんじゃないのか? こんな委員が存在する時点でNHKは救いようがない。

昔は大学の授業を聞いていて、学生が寝るということはありませんでしたが、今は授業中に寝ます。

ダウト。今も昔も変わらない。しかし思うに、こんな人間の行う授業を、単位のために聞かなければならないとしたら、寝るのが正解だ。

カンボジアで授業をしていると、目をきらきら輝かせて聞いています。

まったく根拠のない安直な比較である。

その反応と同じように彼らはテレビも見ています。

日本ほどインターネット環境に恵まれていないからにすぎない。

そういう法律で、テレビの番組も何時から何時まできちんと見るということにすればいいと思います。この番組を見なければ会社に就職させないとか、抜本的に政策を変えないと、日本は本当に大変なところへ行くのではないかと思います。

俺の日本をどうする気だ? まず憲法改正からはじめなければならないな。

講演して一番反応がないのは若者です。私の講演が悪いというのもあると思いますが

こんな人間の講演を真面目に聞いている若者が日本にいたならば、日本の未来はない。