まず、名誉ある受賞から、今井真（滋賀医科大学講師）、漆畑直樹、種村秀輝（シームス）、田島幸信（香りマーケティング協会理事長）、後藤秀晃、溝口浩一郎（エア・ウォーター防災）、村上純一（琵琶湖病院）の七名の者は、イグノーベル化学賞を受賞した。これは、眠っている人を起こすのに最適な空気中のわさび濃度を発見したためである。これは、火災などの警報器で、聴覚障害者を起こすのに使われる技術である。
不名誉な受賞は、麻原彰晃とその他大勢の終末予言者、世界は1997年に終わると予想し、数学的予想と計算には注意すべきだと、世界に知らしめたことをもって、イグ・ノーベル数学賞を受賞した。
「オ゛ー、ミ゛ー ラ゛フ゛ ク゛ッキ゛ー オ゛ー イ゛ェア゛」
～都道府県ドメインについて、クッキーモンスター「ちょっと待てや」
～都道府県ドメインについて、高木 浩光
高木浩光＠自宅の日記 - JPRSに対する都道府県型JPドメイン名新設に係る公開質問
以下は素人丸出しの説明である。
cookieは、今日のWebサイトにとって、非常に重要であると同時に、プライバシー、セキュリティ上、気を付けなければならない機能でもある。あるWebサイトによって設定されたcookieが、全く別のWebサイトによって読み込まれることがあってはならない。このため、cookieにはsame origin policyがある。異なるドメイン間では、基本的にcookieを共有できないのだ。example.comで設定されたcookieは、example.orgからは読み込むことはできない。
ところで、今私がexample.comというドメインを取得し、Webサイトを運営したいとする。この場合、第三レベル以降のドメインは、自由に名付けることができる。自作の音楽は、music.example.comで公開し、ブログはblog.example.comで公開するとしよう。この二つのドメインは、異なるものであるから、cookieは共有できない。しかし、このドメインは、どちらもexample.com下にあるものであり、私の所有するドメインであり、私の運営するWebサイトである。したがって、このふたつのドメイン間でcookieを共有できたとしても、セキュリティ上の問題にはならない。
そこで登場するのが、super cookieである。このcookieは名前の通りスーパーなクッキーなので一部ドメインを指定しないことができる。たとえば、.example.comを指定すれば、music.example.com、blog.example.comまた他のあらゆる、「任意.example.com」で共有することができる。
しかし、もしこのスーパーなcookieを、.comに対して指定すればどうなるだろうか。この場合、私の所有するexample.comだけではなく、トップレベルドメインがcomでさえあれば、どのドメインからでもスーパークッキーの読み書きができる。これはまずい。
もちろん、問題はcomだけではない。トップレベルドメインはもっとたくさんある。では、トップレベルドメインに対するスーパークッキーを禁止すれば、問題は解決するのだろうか。
例えば、example.co.jpは、co.jpまでがパブリックなサフィックスである。トップレベルドメインの禁止だけでは、この問題を解決できない。
問題の解決方法とは、パブリックなサフィックスのリストを作成し、スーパークッキーの指定が、そのリストに該当するときは、使用を禁止することである。これは、クソなサイトからユーザーを守るためにも、ブラウザー側で対処する必要がある。
今、都道府県のサブドメインを導入するということは、日本全国の47都道府県の分だけ、パブリックサフィックスが相当に増えることになる。もし市町村も導入ということになれば、1722市町村。もちろん、これはブラウザーをアップデートすることで対処しなければならない。誰がやるというのか。アップデートされないブラウザーはどうしようもない。
明らかに、極東の小国は非常に重要なので、時にはこんな乱暴も許されるのだろう。
C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)
なんと、Non-static data member initializersがGCC 4.7で実装されているという。早速試してみようと、昨日ビルドされたばかりのgccのバイナリを落とした。さっそく試してみたが、sorry, unimplementedと表示される。何故だろう。
struct X
{
int member = 0 ;
} ;
今日は気分転換に、本物の日本語を読むことにした。私の言う本物の日本語とは、数百年前に書かれて、今なお読まれている文章のことである。まだ書いた当人の生きているような新しい文章は玉石混淆であり、しかもほぼすべて石である。数百年前以前に書かれて、今なお読まれている文章は、名文の可能性が高い。路傍の石の中から玉を拾うより、世間から何百年も玉だと言われ続けている石の中から玉を探すほうが簡単である。ちょうどブックオフで、新潮日本古典集成の説教集が投げ売られていたので、それを読むことにした。
今からたったの400年ほど前、日本には説経説き、または説経者と呼ばれる下層階級の芸人がいた。彼らは当時、三十三間堂の境内で、大きな傘をかざし、ササラと呼ばれる、竹で作った、こすりあわせて音を鳴らす原始的な楽器を擦り鳴らしながら、地蔵や仏像の由来を往来の人々に説き聞かせ、おひねりを得ていたのである。
三十三間堂の近くに住む者として、これがどうにも実感がわかない。今の三十三間堂は、決して無料見はさせじとばかりに周りを厳しく塀で取り囲み、たった一箇所の入り口から、拝観料を払って入る、まあなんとも近代的で罰当たりな商業施設である。地獄で銅の湯を飲ませられることは、まず間違いあるまい。それが、かつては人通りの激しい往来であり、しかもこのような所謂「ササラ乞食」の商売の場所であったとは。今の四条大橋のような雰囲気だったのだろうか。
さて、恐らく説経の中で一番有名な話は、「さんせう太夫」であろう。これは、森鴎外の「山椒大夫」という小説のためである。しかし、実際に説経のさんせう太夫を読んでみると、森鴎外の作品は、単なる劣化コピーに過ぎないことが分かる。もちろん、当時の説経説きと森鴎外とでは、力の入れどころが違うというのもあるが、原典はさすがに強烈である。安寿は凄惨な拷問によって焼き殺されるし、返り咲いたつし王丸がさんせう太夫に行う報いも、やはり残酷な処刑である。また、誓文の文句も興味深い。
コンビニでは、懐かしのマンガを再録したペーパーブックが売られている。今日、ふと売り場を見ると、興味深い本が売られていた。スライム冒険記である。
スライム冒険記とは、かねこ統によって描かれ、当時のVジャンプで連載されていた、ドラクエの世界観を元にしたギャグマンガである。灼熱炎が吐けるボケキャラのスライムのスラきちと、ツッコミ役の山賊ウルフのウルフ、その他のドラクエにおなじみのモンスター達が、なんとなく勇者を目指す物語である。
作風は、随所に鳥山明へのオマージュが感じられる。
なんとなく、ドラクエ4コママンガ劇場を読み返したい気分になった。思えば、ドラクエ4コマからは、かなり良質なマンガが生まれた。衛藤ヒロユキしかり、柴田亜美しかり。思えば、エニックスは、ゲームだけではなく、出版事業でも、結構新しいことをしていたのだな。今は見る影もないが。
しかし、どうも今、ドラクエ4コママンガ劇場は売られていないようだ。中古を手に入れるしかないのだが、近所のブックオフには見当たらない。クレカさえあれば、アマゾンの中古市場から買えるのだが。
早いところ執筆を終わらせて、まじめに働かなければなるまい。
C++の参考書を書くのがつらい。どうも、日本語という言語の限界を感じる。
日本語で技術書を書くのは、苦痛極まりない。どんなにわかりやすく言葉を選ぼうと、結局やっていることは、英語の翻訳でしかない。それならば、最初から英語で書けばいいではないか。明治になってから、医学はドイツ語から翻訳されたオランダ語ではなく、元のドイツ語で学んだように、プログラミングも英語で学ぶべきなのだ。確かに、一般人は翻訳で学んだが、専門家たる医者は原語で学んだのだ。専門家であるプログラマーも原語で学ぶべきである。
実際のところ、今や、もはや参考書というもの自体が時代遅れなのではないかと思う。何故ならば、誰もが一次ソースたる規格書を読むことが出来るからだ。まあ、C++はISOの規格なので、規格書は無料ではない。とはいえ、たったの352スイスフランだ。クソの役にも立たぬ参考書を何冊も買うより、規格書を買ったほうがいい。
むしろ、今の時代に日本語のプログラミングの参考書を出しても、害悪でしかないのではないかと思い始めている。日本語の資料がなければ、まともにプログラミングを学びたいものは、自然と英語を学ぶようになるはずだ。かつて私は、プログラミングを学ぼうとしたが、まともな日本語の参考書がなかったので、まず英語から学ぶことにした。この2011年になっても、まともな日本語の参考書が存在せず、世間一般に良書とされている日本語の参考書は、すべて英語からの翻訳（それもかなりひどい翻訳）であるという事実からしても、私の取った戦略は正しかったといえる。
とすれば、日本語の参考書をこれ以上増やしても、害悪でしかない。
結局、今の私は、自分自身が全く必要としていない、それどころかむしろ、害悪であるとまで考えるような参考書を書いているわけだ。道理でつらいわけだ。
追記：確かに、352スイスフランは、個人で買うにはちょっと高い。恐らく来年頃には、ANSIから数十ドル程度の値段で、規格書が買えるようになるはずだ。
株式会社ロングゲート - 製品案内
『プログラミングの魔導書 Vol.2』予約開始！ - Faith and Brave - C++で遊ぼう
プログラミングの魔導書 Vol. 2の予約受付が始まった。今回、私はDave Abrahamsへのインタビューを敢行し、また、constexprの入門記事を書いている。
Dave Abrahamsは、C++プログラマーでその名前を知らなければモグリであるほどの有名なプログラマーである。
私自身のconstexpr記事は、constexprを紹介する入門的な記事である。まだ、constexprの具体的な活用例が少ないので、応用よりもむしろ、基礎を書いたほうがいいと思ったのだ。constexprをまったく知らない読者は、この記事を読めば、constexprの機能と使い方は、ひと通り分かるであろう。逆に、constexprの応用を期待している読者は、失望するかもしれない。
紙媒体が好きな人は、紙を注文できるし、電子媒体を好む人は、お世辞にも電子書籍として優れているとは言えないフォーマットであるPDFを買うこともできる。
ともかく、ようやく二冊目の刊行となったわけだ。今回は、前回のように理想を語るのではなく、批判をしようと思う。魔導書はこれから、方向性を変えるべきであると思う。電子媒体に絞るべきなのだ。
紙媒体は、すでに終わっているコンテンツである。コンテンツを印刷物で公開するのは、非常に労力がかかる。今の規模では、まあ、年に一冊が関の山だろう。これは思えば、非常に不思議である。何故ならば、今日び、コンテンツというものは、一瞬にして全世界に公開できるからだ。
たとえばこのブログだ。この本文は、書き終えた後、即座に公開されている。この文章は念入りに校正されていない。おそらくはtypoを含むだろうし、同じ助詞の連続などの、読み易くない文章も含まれている可能性もある。とはいえ、そんな誤りは些細なものである。感じの誤変換であるとか、てにをはな間違いだあるとかは、一見して明白であり、読者は容易に本来の意図した意味を推測できるであろう。それよりも、コンテンツの作成、公開にかかる労力を削減できれば、コンテンツ作者はより積極的にコンテンツを作成することができるようになり、世の中により多くの良質なコンテンツをもたらすのだ。
現代の技術を持ってすれば、一瞬で可能なことに、半年以上もの時間を費やす。無駄の極みにはあらずや。例えば、いまだに活字拾いから始めたり、写本したり、レコードで音楽を聞いたりするような無駄さ加減だ。もちろん、道楽としての活字拾いや写本やレコードを否定するつもりは毛頭ないが、それは趣味や道楽だからこその芸当であって、真面目なプロジェクトでは、やはり無駄である。
しかるに、プログラミングの魔導書は、いまだに紙媒体に固執しているため、実際の記事自体は何ヶ月も昔に完成しているというのに、印刷という障害物のせいで、半年がかりの労力になっている。これは明らかに、時代遅れである。
追記：組版自体は一ヶ月ほどでできるらしい。
たとえば、インタビューも今年の前半に行われたが、公開するまでに何ヶ月もたってしまっていては、せっかくの価値も減じてしまう。私の書いたconstexpr記事だって、当時のドラフトを参照にしていたので、最終的なC++11とは少し違ってしまっている。これはできるだけ修正したが、どうしても付け焼刃的な感は拭えない。FDISが当時読めていたならば、こうは書かなかっただろうという箇所も多い。これは、C++11発行の最終段階のツメの作業を行なっている途中での執筆だったので、仕方がないといえば仕方がないが、魔導書の発行が遅すぎるとも言える。
PDFの問題は厄介だ。PDFは印刷を前提としたフォーマットであり、電子書籍のフォーマットには適していない。電子書籍は、あくまでコンテンツを記述するフォーマットを使うべきである。コンテンツをどのように表現するかというのは、クライアント側の仕事だ。フォント、文字色や背景色、余白、さらには禁則処理や文字のツメやアキなどといった組版は、クライアント側が表現すればいいのだ。
世間では、Windows 8（仮称）の詳細の発表に湧いている。とうとう、Windows 8のDeveloper Preview版が公開されたのだ。同時に、かねてから噂されていた、Metroの詳細や、プログラミング方法も公開されている。
Building your first Windows Metro style app using C#, C++, or Visual Basic
では、さっそくC++のコード例を見てみることにしよう。
// C++
// ...
void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
DisplayText->Text = "Hello World";
}
ん？ 何か違和感を覚える。非常に気になるが、先に進もう。
Platform::String^ _title; Platform::String^ _author; Platform::String^ _pubDate; Platform::String^ _content;
何じゃこのdeclaratorらしき^は？
はよう、MSの独自規格スパゲッティ量産言語、C++/CLIというものならん。
と考えた私の予想はるかに上回るクソ仕様であった。
Windows Runtime objects and ref new
Note that you use the ^ (“hat”) symbol instead of the pointer dereference operator (*) when declaring the variable
そんな馬鹿な。C++/CLIではない、通常のネイティブコードを生成するC++に対する拡張だというのか。やおれMSよっく聞け。そちはC++を何と心得る。偉そうに口ヒゲなど生やしてる場合か。もっとも、最近は剃っているそうだが。そもそも、declaratorとしての*は、declaratorであり、ポインターデリファレンス演算子ではない。爾、C++規格を知らざる者にドキュメントを書かせたるか。
結局、これがMSの選択か。attributeではなく、特別なdeclarator、^を選んだということか。
もちろん、MSを標準規格に従わない、常に独自規格を再発明する、独裁者だと批判するのは容易であるが（実際、その通りであるが）、もう少し考えてみる。MSはdeclaratorに^を使うことには、合理的な理由がある。C++/CLIで全く同じ構文を提供しているので、実装経験と実績があるのだ。この構文に決定するにあたって、既存のC++コードとの互換性を保てるかどうか、相当な検証を行ったはずである。C++/CLIとは、既存のC++のコード資源が使えるという利点のみが、C#より優れているのであって、C++のコード資源の利用が必要なければ、まともな頭をしていれば、普通はC#を選ぶはずだ。
もちろん、attributeも互換性に関しては申し分ないが、実装経験の差で、選ばれなかったのだろう。実際の実装で使われないならば、規格には意味がない。
言語拡張自体は、悪いことではない。C++の標準規格は、どの実装でも必ずサポートされるべき最小限の必須機能だけを規定している。たとえば、C++98の時点では、アライメントの指定は、あらゆる環境でサポートされるべき必須機能ではなかった。それ故、MSVCやGCCその他の、アライメント指定を必要とするコンパイラーは、#pragmaや独自のキーワードを用いた言語拡張によって、アライメント指定をサポートしていた。
C++11では、このような言語拡張の中でも、とくにコードに付加的な意味を与える要素に着目して、attributeという文法を付け加えた。これを使えば、独自の汚いキーワード（例：__declspec、__attribute__）を導入することなく、言語拡張が行えるはずであった。少なくとも、机上の理論ではそうであった。
しかし、__declspec(hogehoge)と[[hogehoge]]では、汚さには余り変わりはない。むしろ、attributeの方が見た目に宜しくないとも言える。
だいたい、C++11の機能からして、当初attributeで提供されるはずだった、アライメント指定やoverrideやfinalといった機能は、「公式な標準規格の言語機能は独自のキーワードを与えられる資格がある」という理由で、独自のキーワードを与えられた（厳密に言うと、キーワードではなく、contextual keywordなのだが）。あとに残ったのは、carries_dependancyとnoreturnという、まあ、言わば、それほど重要ではない機能だけである。
おそらく、attributeはasmと同じ轍を踏むだろう。どの実装からも顧みられることなく、黒歴史となるのだ。
BBC News - Rock veterans win copyright fight
ビートルズの録音は、あと数年で著作権が切れるはずだった。しかし、この法改正で、著作権は存続するようになった。情けない話だ。どうせ、20年後にも、保護期間をさらに延長するように法改正されるに決まっている。過去の栄光にしがみつくようでは、音楽はこれ以上成長しないだろう。
日本ではどうなるのだろう。ビートルズの最初の音楽、Love Me Doは、1962年に録音、発表されている。日本では、映画以外の団体名義の著作物の保護期間は、50年である。ビートルズは団体であろう。とすると、日本では、2013年以降は、Love Me Doの当時の録音の著作権が切れるのだろうか。
問題は、たとえビートルズの著作権が切れた所で、私にとってはあまり意味がないということだ。世代が違いすぎる。まだレコードという物理的な音溝に針をあてて音を再生する古代の装置を使っていた時代の話なのだ。
post-Bloomington mailingが公開された。
ISO/IEC JTC1/SC22/WG21 - Papers 2011-09
N3301: Defect Report: Terminology for Container Element Requirements
見逃していた文面上の僅かな誤りを修正。
N3302: Constexpr Library Additions v2: complex
N3303: Constexpr Library Additions v2: chrono
N3304: Constexpr Library Additions: containers
N3305: Constexpr Library Additions: utilities v2
それぞれのライブラリーで、constexpr化できる関数をconstexprにする変更。
N3306: A Proposal to Tweak Certain C++ Contextual Conversions, v2
幾つかの場所では、式の評価には、ある種の制限が課せられる。例えば、if文やwhile文のオペランドの式を評価した場合、boolに変換可能であることが求められる。このような制限を、規格では、contextualという用語を用いている。
ところで、規格の文面中に、このcontextualとよく似た意味を、それぞれ別の言葉を使って表現している箇所が、4箇所ある。その箇所では、オペランドがクラス型であった場合、期待される型への、「唯一の非explicitな変換関数」が求められている。
この4箇所の言葉を統一するために、新たな用語、contextually implicitly convertedを定義して、その用語に置き換えようという提案。
N3307: Issues Found Implementing C++0x
C++0xを実際に実装している途中で見つかった不具合集。多いので説明はしないが、興味深い問題も多い。特に、constexprと例外指定に関する問題が多いように思われる。例外指定は、私の印象では、些細なものが多いが、constexprは厄介だ。
しかし、いくつかの問題を解決するためには、それなりに大きな変更が必要になる。例えば、ある問題を解決するためには、テンプレートコンストラクターも、コピー/ムーブのコンストラクターとし、他のあらゆる箇所を、それに対応して修正し、さらに既存のコードの意味を変えないために、テンプレートなコピー/ムーブのコンストラクターは、暗黙のコピー/ムーブのコンストラクターの生成を妨げないという条件も付け加えなければならない。
N3308: constexpr consternation
constexprの原案では、constexpr関数を前方宣言することはできなかったし、定数式の入力に対しては、常に定数式を出力しなければならなかった。そのような制限は後に変更されたが、文面上では、その変更を正しく適用できていない箇所がいくつかある。その修正案。
ちなみに、今回のcore active issuesは、タイトルだけで詳細が書かれていないものが多い。これは、次のmailingで修正される予定らしい。
しかし、今書いているC++の参考書は、ある部分では1年以上前のドラフトを参考にして書かれたので、今とはだいぶ異なっている。constexprのような、明らかに多大な変更が入るであろう機能は、当時執筆を保留したが、実際にFDISを読んでみると、殆どの項目で、一年前とは文面が改良されている。問題は、そのような改良を、参考書にも適用しようとすると、ほぼ書きなおしになってしまうということだ。これでは、いつまでたっても本が完成しない。結局、不完全でも僅かな修正だけで済ますしかないだろう。やはり、C++の参考書を日本語で書くべきではなかったのだ。しかし、英語でいいとなると、なおさら今書いている本のようなものは必要ない。英語でいいのならば、規格を読めばいいからだ。なんともニッチな需要であることよ。
Windows Vistaの開発中、アプリケーション互換チームは、rundll32の呼び出し規約の仕様に従わない関数を無理やり呼び出した挙句のスタック破壊の問題を抱えていた。
訳注：Windows上で動く32bitコードにおいては、関数の呼び出し規約が統一されていなかったので、呼び出し規約の誤りによるスタック破壊はよくあることである。もっとも、呼び出し規約が統一されていたからとて、意図的にスタックポインターをずらされてしまってはどうしようもないが。
問題は複雑だ。例えば、rundll32を間違った方法で使っていたバッチファイルが動かなくなった。なぜならば、rundll32プロセスが終了しないからだ。スタックアライメントの誤りは、スタックからのレジスターのリストアの誤りを生じさせ、rundll32の終了時のコードを動かなくさせてしまうからだ。以前のバージョンのWindowsは、この問題を、たまたま、避けることができていた。Windows Vistaで使っているコンパイラーは、最適化方法が異なるので、スタックやレジスターの使い方が異なり、以前のバージョンのWindowsでは、たまたま問題にならなかったスタック破壊が、問題になるのだ。偶然は何度も続かないものだ。
私はこのrundll32の問題を解決して、間違った方法で使っていた人々を救うよう、命ぜられた。つまりは、他人のバグの尻拭いというわけだ。
解決方法とは、関数を呼び出す前に、呼び出された関数がスタックから余計にpopする可能性を考えて、スタックをあらかじめ数百バイトほど余計にpushしておくのだ。そして、スタックポインターをグローバル変数に保存しておく。関数から戻ったら、関数がスタック操作を誤った場合に備えて、そのグローバル変数からスタックポインターをリストアする。たしか、他のレジスターもグローバル変数に保存しておいたような気もするが、何だったかは忘れた。
もちろん、これを悪用してはならない。コンビニの前にゴミを投げ捨ててはいけないのと同じ理由だ。
訳注：アプリケーションの互換性を保つためのworkaroundは、ユーザーのためにあるのであって、プログラマーのためにあるのではない。
出版社からスキャン代行業者への質問状を全文公開、潮目は変わるか - 電子書籍情報が満載! eBook USER
それなら俺にも考えがある。長えことジョジョとゴルゴ13のファンだったが、今日限りだ。
今や、あらゆるコンテンツは物理的な媒体の拘束を受けずにすむのだ。これは不可逆な時代の流れであり、誰も抗うことはできない。仮に対抗しようとしたとて、かの進化神は歩みを緩めず、障害物を物ともせずに蹴散らし、より一層荒々しく、物事を先に進めるだけである。故に、かの進化神の途上に横たわる障害物を除くのは、我々、今を生きる者の努めである。写本は死んだ。版木は死んだ。活版印刷は死んだ。いかに紙書籍のみ、無常の理を逃れんや。