五日間、留守にします。
Cry's Tumblr, FCD (N3092) 20.9.11 に対する NB コメント (仮案)
weak_ptrって、そんなに積極的に活用することを想定されていないのでは。
2010-04-29
2010-04-28
難しい
ようやく、name lookupまでこぎつけたが、いったい、どのように説明したらいいものやら。あまりに詳細な説明は、無駄である。結局、そこまでの詳細を求める者は、最初から規格を読むべきなのだ。
とはいえ、単にプログラミングのために言語を学ぶのに、規格を読むというのは、鶏を割くのに牛刀を用いるの感がある。
しかし、本を書くのは難しい。ブログを書いている暇がない。
2010-04-27
deleted定義
Twitter / digitalghostの妹: int f(int); int f(double) ...
おお！
void f( int ) {}
void f( double ) = delete ;
int main()
{
f(0) ; // OK
f(1.0) ;// error
}
これはすごい。いままでまったく気がつかなかった。よく見たら、deleteは、Deleted definitionsという名前であった。Explicitly-defaulted functionsとは、名前からして明確に異なるのである。素晴らしいことに、deleted定義を指定できる関数に、制限はない。つまり、メンバー関数である必要すらない。
なぜ、いままでメンバー関数にしか使えないという思い込みをしていたのだろう。これは素晴らしい。
ちなみに、こういうこともできる。
void f( int ) {}
// f(int)以外すべて削除
template < typename T > void f( T ) = delete ;
int main()
{
f(0) ; // OK
f(1.0) ;// error
}
Visual Studio 2010が救いようのないほどクソだ
本の虫: Visual Studio 2010のword wrapの遅さで取り上げた問題だが、返事が返ってきた。
text flickering while using Word Wrap | Microsoft Connect
The VS 2010 editor has several known performance issues related to long lines, even without word wrap or for long lines that are less exaggerated than the ones in your video. This is on our list of areas to work on for the next version of Visual Studio, so I'm resolving it as Postponed for now. We're always interested in improving performance and plan to revisit this particular problem for a future release.
一行に50文字かそこら書いただけで、アホみたいに重くなる問題を認識していながら、製品をリリースしたというのか？ ありえん。
マイクロソフトは、多額の開発費と時間をかけて、世界一遅いエディタを開発したわけか？ おめでとう。
だいいち、VC10だって、C++0xの新機能を実装する前にやることがあるだろ。C++98にすら追いついていないんだから。
2010-04-26
MSVCのクソっぷりがどうしようもない
そりゃ、確かに、多くのill-formedなコードには、"no diagnostic is required"って書いてあるけどさ、せめてコンパイルエラーにしようよ。
2010-04-25
クラスのスコープが難しい
もし、クラスのメンバーの宣言の順番を変えたことにより、プログラムの意味が変わる場合、そのコードは、ill-formedである。
typedef int type ;// #1
class C
{
type x ;// このtypeは、#1の::type
typedef int type ;// #2
} ;
これを並び替えると、
typedef int type ;// #1
class C
{
typedef int type ;// #2
type x ;// このtypeは、#2の、C::type
} ;
したがって、この最初の例は、ill-formedである。
しかし、二つめの例も、メンバーの宣言の順番を並び替えると、ひとつめの例になってしまう。とすると、ill-formedなのだろうか？ いや、これは、問題なく動いて欲しい。さもなくば、安全のためには、常に、qualified nameを使わなければならない。
typedef int type ;
class C
{
typedef int type ;
C::type x ;// わざわざqualified nameにしなければならない。
} ;
もちろん、規格のsynopsisですら、そんなことはしていない以上、このコードは、問題ないのだと思う。しかし、規格の文面からでは、どうも、なぜwell-formedなのかが、わからない。
どういうことだろう。
規格には、"If reordering member declarations in a class yields an alternate valid program"と書いてある。最初の例は、このルールにより、ill-formedである。とすれば、ふたつめの例を並び替えても、validなprogramにはならないので、二つめの例は、well-formedなのだろうか。しかし、ひとつめの例をill-formedであると決めているのは、ほかならぬ、このルールである。これは、いったいどうしたものなのだろうか。
あるいは、一つめの例は、(2)の、"A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S."のルールにも抵触しているであろうから、そのため、一つめの例はill-formedであり、二つ目の例は、well-formedなのかもしれない。たぶん、そうなのだろう。
これは、本で説明するには、詳細すぎる。
追記：やはり、3.3.7 Class scope [basic.scope.class]の1, 2, 3の記述で、定義されている。
VCは、再評価や順番替えによってエラーになるべきコードが、警告も出ずに通る。クソだ。
追記２：基本的に、ルールとしては、クラス内の名前は、一貫していなければならない。もし、クラスの宣言を、最後に再評価して、意味が変わってしまった場合、ill-formedである。その次に、宣言の順番を変えて、合法なコードなのに意味が変わっていたら、ill-formedである。
2010-04-24
C++0x本：スコープ
色々と考えた挙句、無意味な詳細にこだわらないことにした。とくに、Lexical conventionsなどは、こればこるほど、通常のプログラミングでは、全く知っておく必要のない詳細の深みにはまってしまう。こんなことを書いても、無駄だ。
というわけで、思い切った切り捨てをした。そこまでの詳細は、普通、必要とされないし。必要な場合は、規格を直接読むべきだ。
いよいよ、肝心のBasic Conceptを書き始めた。ここは、重要だ。
ODRも、努めて単純に解説した。別の翻訳単位で、まったく同じ定義が重複できる例外的なルールに着いても、できるだけ簡単に解説しようと試みた。そもそも、大半のプログラマは、ODRという厳密な概念とルールを、強く意識せずにコードを書いてるのだし、当然、そうであるべきだ。
さて、スコープはどうするか。これも、そんなに詳細を意識せずとも、通常のプログラミングはできる。さて、どこまで詳細を書くべきか。
物云
今は昔、祇園の別当に、戒秀という坊主がいたが、ある有名な殿上人の妻の元に、忍んで通っていた。主人はこれを、薄々感づいてはいたが、知らぬふりをしていた。
ある日のことである。主人が家に帰ってみると、何やら妻子の様子がおかしい。もしやと思い、奥の部屋をみると、大きな箱に、いかにも不自然に、鍵をかけて置いてある。なるほど、この中にあの坊主がいるに違いない。さて、どうしてくれようか。
主人は、侍を呼んで、こう命じた。
「この箱、ただいま祇園に持って参って、誦経の料にさし上げてこい」
侍はこの旨を承り、人夫二人に箱を担がせて、祇園に向かった。妻子は、いかにも複雑な心境であったが、どうすることもできないので、ただ黙っていた。
さて、侍が祇園に行き、誦経の料を持ってきた旨を告げると、僧たちは思案した。これは、相当な宝が入っているに違いない。何はともかく、別当立ち会いのもとで、箱を開けなければならぬ。誰か、別当に知らせろと。
しかし、別当はどこにも見当たらない。侍はしびれを切らして、責め立てた。
「早く開きたまえ。主人の手前、確かに受け取ったことを確認するまで、帰ることはできぬのだ。己が立ちあえば、何かは苦しかるまじ」と
なおも僧たちが悩んでいると箱の中から、細くわびしげなる声がした。「誰でもいいから、ただ、開かせよ」と。
その場にいた、侍や僧ども、あさましく思い合えること限りなし。とはいえ、開けないわけにもゆかぬので、恐る恐る、箱を開けた。
箱より、別当が頭を出した。周りにいた僧どもは、驚いて逃げ出した。使いの侍も、驚いて逃げ出した。その間に、当の本人の別当は、箱から出て、どこかに隠れてしまった。
この主人というのは、賢い人であってので、その場で箱から引きずりだして、袋叩きにするよりも、恥を見せようと、かかるにくい事をしたのであった。戒秀は、もとより極めたる物云にて有りければ、箱の中より、かくも言ったのであった。
今昔物語、第二十八巻、祇園別当戒秀、被行誦経語 第十一より。
箱の中から、「只所司開キニセヨ」と言ったのが、なぜ物云になるのか。物云といえば、今昔物語では、「此事聞持テヤ、ヲヰ」と発言した物云が、二人存在する。柳田國男も、これに注目して、少なくとも当時、物云というのは、こういう決まり文句を言うものとされていたのではないかなどと書いている。
では、箱の中から開けてくれと発言することと、物云と、何の関係があるのか。
ふと思いついたのが、いわゆる昔話には、桃とか瓜とか、木の根っ子、箱の中から、主人公が生まれたという話が多い。このとき、爺が桃を切ろうとして、包丁を振り上げたところ、桃の中より、「爺、静かに切れ」などと声がしたという話が、結構ある。もしかしたら、これと何か関係があって、それで、極めたる物云という文が、効果的だったのかもしれない。
2010-04-23
今回のサウスパークのエピソードは、ネタではないそうだ
A Statement from Matt and Trey - News - South Park Studios
これまで14年間、我々はSouth Parkをやってきたが、その間、隠し立てのようなことは、ひとつのエピソードとして、していない。我々は、コメディ・セントラルに、今回のエピソードを提出した。コンテンツのどの部分を自主規制するかということは、コメディ・セントラルの決定に委ねられている。これは、断じて我々による一種のメタジョークではない。コメディ・セントラルが、自主規制のBEEP音を付け加えたのだ。そもそも、カイルの最後のスピーチの内容は、脅迫と恐怖に関する事である。ムハンマドについては、一切言及していないにもかかわらず、自主規制を受けた。来週は、something completely differentな話をお届けする予定だ。果たしてどうなることやら。
それにしても、something completely differentって訳せない言葉だよなぁ。まず、日本語圏にはあまりなじみのない、Monty Pythonから説明しないといけないのだから。
2010-04-22
回教徒は何とも自己言及的な奴らだ
回教のアホ原理主義者が多数抗議したため、今週のサウスパークのストリーミングは、現在、差し止められている。
何とも自己言及的な奴らだ。
追記：思ったのだが、これ、壮大な釣りではなかろうか。つまり、イスラムを笑うため、意図的に、無意味な自主規制を仕込んで、楽しんでいるだけじゃなかろうか。つまり、これ自体が、ジョークなんじゃないか。
ネット選挙解禁のワケの分からない制限。
ネット選挙運動 夏の参院選から解禁へ - MSN産経ニュース
者や政党になりすました虚偽の電子メールへの対策が難しく、今回は電子メールの使用解禁は見送り、選挙期間中のホームページ（ＨＰ）などの更新を認める方向だ。
メールを禁止というのは、訳がわからない。つまり、具体的には、SMTPやPOP3といったプロトコルを禁止するのだろうか？ 意味が分からない。HTTPプロトコルを使えば、メールとほぼ同じ機能は提供できるわけだ。禁止しても、何を防ぐというのだ。
なりすましを防ぐために、メールを禁止するというのであれば、HTTPプロトコルも、同様に、禁止すべきである。なぜなら、HTTPプロトコルは、信頼できないからだ。
つまり、すべてのコンテンツは、正しい証明書を用いたSSLを介して提供されなければならない。
しかし、現実は、おそらく、HTTPプロトコルも許可するのだろう。HTTPプロトコルを許可するのであれば、メールだって許可しても構わないはずだ。
第一、これらはすべて、アプリケーションレベルの話ではないか。当然、それより下層である、TCPプロコトルは許可するのであるから、なおさら、特定のプロトコルであるSMTPやPOP3を禁止する理由がわからない。
C++0x本：求む、簡単なBMP外の文字
C++0xでは、ユニバーサルキャラクターセットがサポートされる。
たとえば、UTF-8の場合、以下のコードと、コメント内のコードは、まったく同じ意味である。
// char utf8[] = { 0xe3, 0x81, 0x82, 0x00 } ;
char utf8[] = u8"あ" ;
今書いている本は、C++0xを解説することが目的なので、UTFのエンコードの詳細については、説明しない。ただ、このように例を示せば、興味のある人は、さらに深く調べるだろう。
UTF-16や、UTF-32の場合は、以下のようになる。
// char16_t utf16 = { 0x3042, 0x0000 } ;
char16_t utf16[] = u"あ" ;
// char32_t utf32 = {0x00003042, 0x00000000 } ;
char32_t utf32[] = U"あ" ;
できれば、UTF-16にも、サロゲートペアを使う例を示したい。しかし、都合のいい文字が思いつかない。なにか、うまいBMP外の文字があれば、教えて欲しい。
もちろん、BMP外の文字であれば、何でもいいわけだが、例なので、分かりやすい、印字可能な文字のほうがいい。見た目に単純な文字とか、日本人にとって馴染みのある文字であることが望ましい。さらに、Windows 7とか、多言語をサポートしたとあるLinuxのディストリなどで、デフォルトでその文字を表示できることが、望ましい。つまり、その環境で、必要なフォントなどが、最初から用意されている必要がある。
ともかく、実用的にパっと思いつくのは、Supplementary Ideographic Planeにある、まず日常生活で使わない、古い漢字とか、ありえない組み合わせのハングルとかの文字なのだが。
教えて、Unicodeに詳しい人。
アドベンチャーブック
280 – Calvinism (but no Hobbes) | Luke Surl Comics
56ページ
なおも旅を続けていると、道端で、ある老人に出会った。
老人の言によれば、我々の行動や意思決定は、すべて、あらかじめ予測できる事項であり、我々がよく、「自由意志」などと称するものは、体の良い方便に過ぎないということが、最新の神経科学の研究により、証明されたそうだ。
老人の説に同意するならば、72ページへ。
同意しないならば、72ページへ。
この本が、アドベンチャーブックであり、選択肢を選んで、該当のページに飛ぶ遊びの本であることが、この本末転倒なネタを最高に面白くしている。
コインのタワー
久しぶりに、何か面白いものをみて息抜きをしようと思った。
これはすごい。テキスト工科大学での講義した内容らしい。コインの構造を工夫することで、かなり建築物は丈夫になる。たとえば、
Penny Furniture Looks Like Wicker - Epic Win FTW -Awesome Photos and Videos
フィンランドには、ゲイシャという名前のチョコレートが存在する
Geisha Chocolate | International Chocolates
あるアニヲタのフィンランド人曰く、フィンランドには、ゲイシャという名前の有名なチョコレートバーが存在するらしい。確かに存在した。
いったい、ゲイシャという言葉は、フィンランドでは、どのようなステレオタイプの意味を持つのだろうか。よくある、売春婦のような意味があるとすると、どうも解せない。「売女チョコ」という名前の菓子は、まず売れないだろう。
ちなみに、このチョコレートは、名前はともかく、なかなかうまいらしい。
2010-04-20
マイノリティ・リポートの世界が現実に
Crime Prediction Software Is Here and It's a Very Bad Idea - Crime - Gizmodo
フロリダ州は、IBMの開発したソフトウェアを使い、将来犯罪を犯す可能性の高い子供を予測するシステムを導入予定であるとのことだ。予測された子供は、特別教育プログラムを受けさせられるらしい。
ヒント：プレクライム、プレコグ、マイノリティ・リポート。
C++0x本：rawをどう訳すべきか
socketには、Raw socketという概念が存在する。これは、しばしば、生ソケットなどとも呼ばれている。
C++0xには、Raw String Literalが存在する。果たして、これは何と呼べばいいのか。生文字列リテラルで通じるのだろうか。
しかし、これをロウ文字列リテラルなどと言ったところで、分かりやすくなるとも思えない。第一、日本語には、この発音は存在しないのだから、いくら音訳したところで、無意味である。生文字列リテラルでいくしかないだろう。名前は、それほど重要ではない。
2010-04-19
著作権について真面目に考えてみる 付記プログラミング雑誌について
著作権である。著作権について、深く考える機会があったので、ここで、今の自分の考えをまとめておく。
コンテンツホルダーは、こう主張する。コンテンツの創造には、莫大なコストがかかっており、対価を得ることによって、コストを回収しなければならない。許可無く無料で複製するのは、泥棒に等しい行為である。ISPはユーザーの通信を検閲して、著作権侵害を防ぐべきである。また、各ユーザーのコンピューターには、スパイウェアを強制的に導入して、著作権侵害を防ぐべきである。これらの著作権侵害への対策のため、特別に法を制定すべきである云々。まさに、RFC 3751を地で行く主張である。
これに対し、海賊たちはどうか。彼らの主張は、主にこうだ。今や、コンテンツの複製は、ほぼノーコストで行える。コストのかからない複製に、金銭的被害の生じるはずがない。ましてや、多くの価値のあるコンテンツは、正規の方法で手に入らないのである。例えば、海外では、マンガやアニメ、とくに同人もののコンテンツを手に入れるのが、非常に難しい。現在の著作権法は、コンテンツの複製に、莫大なコストがかかった時代の産物であり、現状にそぐわない。人類の文化の発展のため、海賊行為は合法化されるべきである云々。共産主義か？
私が思うに、どちらの主張も、やや極端すぎる。現行の著作権法は、見直す必要があるとは思うが、さりとて、現在の問題を、すべて解決できるルールというのが、あまり思いつかない。
コンテンツホルダーの言い分にも、一理ある。コンテンツを作るには、今なお、莫大なコストがかかる。それは事実だ。
とはいえ、歴史的に、従来の貨幣経済以前の文化の発展には、著作権は全く寄与していないのである。とはいえ、貨幣経済の行われている現在と、単純に比較はできない。
思うに、海賊行為の流行るのは、もっと即物的な理由ではないかと思う。コンテンツが入手できないか、仮に入手できたとしても、無駄に面倒なのだ。
たとえば、マンガやアニメだ。日本に住んでいてさえ、このコンテンツを手に入れるためには、最寄の店に行かなければならない。多くの日本人は、田舎に住んでいる。最寄の店というのは、家から5キロも10キロも離れているのである。日本以外の諸外国では、そもそも、売っている店が身近にないのである。
今は、アマゾンに代表される、ネット通販がある。しかし、大抵の場合、コンテンツの利用には、実際の物理的なコンテンツが郵送されるまで、数日を待たなければならない。
家にいながらPCで、あるいは、その場から携帯端末で、わずか数分にして、コンテンツを利用できるべきだと考えるのは、ごく自然である。しかしながら、正規の方法では、そんな手段がない。
仮に、インターネットを利用した、正規のダウンロード販売を提供しているにせよ。まず、住所、氏名、年齢、電話番号、クレジットカード、その他の、ややこしい情報を入力しなければならないし、さらにひどいことには、コンテンツには、DRMやDongleが用いられており、特定のプラットフォームや、特定の条件を満たさなければ、使えないのである。
たとえば、DVDやBDだ。正規の方法で物理的なディスクを入手して、プレイヤーで再生する。まず現れるのは、権利団体および、動画圧縮やDRM関連の技術の特許ホルダーのトレードマークである。つぎに、遅くて暗号のように理解不可能なチャプチャーメニューやシーンセレクションなどといったUIが表示される。
はたして、これが正しい技術の使い方であろうか。VHS時代はどうであったか。あの頃は、VHSテープを入手して、プレイヤーで再生すれば、すぐに、本物のコンテンツが利用できたはずである。それが、今やどうだ。早送り、巻き戻し、前回見たところから再生すら、満足にできぬではないか。果たして、これが技術の進歩といえようか。
私が、最近、マンガもアニメも映画も大衆小説も利用しなくなって、古典にばかり傾倒しているのは、結局、こういう利用上の問題も、関係しているのではないかと思う。少なくとも、平家物語なら、全文引用しても、著作権上、何の問題もないわけだ。
しかし、コンテンツがまるごと勝手に利用できるのが合法だとすれば、いったいどうやってもうけを出せばいいのだ？ 中世のパトロン式にまで、退行しなければならないのか？ それもあんまりだ。
話が、だいぶややこしい方向にそれた。そもそも、なぜ法律にも詳しくない私が、著作権について考察しているのか。そのきっかけは、まさに創刊しようとしている新たなるプログラミング雑誌である。
ロングゲートは、このプログラミング雑誌で、あまり利益を追求する予定はないそうだ。ただし、赤字にならないということだけは、真剣に考えている。
雑誌を出すというのは、非常に面倒なことだ。問題はいくらでもあるが、その中に、著作権というものがある。
一般に、雑誌の記事の著作権というのは、買い取りである。これは、雑誌という都合上、そういうことにしておかないと、非常に使い勝手が悪いからだ。
私は、ロングゲートを設立した、イケメンのアキラさんに対して、雑誌の著作権の扱いについて訊ねてみた。彼らは、色々と議論したあげく、著作権は、ライター本人が保持すると結論したらしい。したがって、雑誌に掲載した記事を書いたライター本人が、別の場所で公開しようが、それは、本人の自由であるということらしい。
これは、やや理想に走りすぎている。ライターとしては、文句はないだろう。ただし、雑誌としては、やはり、どうであろうか。
著作権には、著作者人格権というものがある。就中、同一性保持権は、厄介な存在だ。私は個人的に、現在の著作者人格権のありようには、やや疑問がある。たとえば、ひこにゃんの例や、パロディの合法性に関して考えると、多くの問題がある。現行法は、遺憾ながらも従わなければならない。議論は可能だが、さりとて、法治国家に済む以上、法に破るわけにもいかないのだ。
たとえば、技術の進歩などにより、雑誌を、今まで想定していなかった、まったく別の形態で提供したいとなった場合、どうするのか。安全のためには、著作者にいちいち許可を取らなければならない。これが現実的に不可能だから、ほとんどの雑誌では、著作権は買い取りなのだ。これをどう考えているのかと訊ねたところ、曰く、「まあ、その時になってから、許可を取ればいいのではないか」と。それは、うまくいかないだろう。
結局のところ、これも、現行の著作権法が、時代にあっていないことに起因する問題ではないかと思う。
それはともかく、肝心のプログラミング雑誌に関しては、どんどん進んでいる。まだ、解決すべき問題も多いが、出版はできるだろう。創刊号では、私は、Bjarne Stroustrupへのインタビューと、その翻訳を担当した。これには、なかなか興味深い話題が出ているので、おすすめだ。
因みに云う。パロディの合法性について、我が日本国の法は、明示的に規定していない。また、効力のある汎用的な判例は存在しない。一方、アメリカ合衆国では、パロディは、明示的に許可されている。
しかし、私が思うに、パロディは、日本の方が盛んである。アメリカにも、Weird Al Yankovicや、South Parkなど、パロディで有名なコンテンツはある。しかし、量でいえば、日本の同人とは比べものにならない。これは、実に奇妙な現象である。法の有無と、実態とが、かけ離れている。まあ、アメリカのfair useは、優秀な弁護士を雇う金があるかどうかにかかっているという批判もあるので、簡単ではないのだろう。
なぜ、how muchというのか
freenodeの##japaneseチャンネルで、「ここには、あまり多くの日本人がいない」という意味で、"Not much japanese here"と言ったところ、manyを使うべきだと言われた。
manyというのは、数えられる物に対して使う言葉であり、muchというのは、数えられない物に対して使う言葉である。"not much japanese"というと、ここでは、あまり日本語が使われていないというニュアンスになるらしい。それは、理解できる。
ではなぜ、「値段はいくらか？」という意味で、"how much?"、というのか。金額というのは、数えられるのではないのか。なぜ、金額に対して、"how many?"と言わないのか。
これはどうも、moneyというのは、金という一般的な総称であって、通貨を表すのではないらしい。たとえば、"three monies"とはいわない。
では、「5グラムの金に相当する」とか、「1キログラムの米に相当する」などという言い方も、moneyなのかというと、これまた違うらしい。それは、moneyの量を表すのであって、moneyそのものではないという。moneyは、あくまで、金そのものを意味するらしい。
しかし、一般的に、"how many USD is it?"（何米ドルだ？）よりも、"how much is it in USD?"（米ドルでいくらになる？）というフレーズの方が、よく使われている。
日本語で、このような区別のある言葉はないものかと考えたところ、「大勢」という言葉が浮かんだ。これは、人とか動物とか、兵力などに使うことができるが、単純に、金額とか物質量などに大しては、使わない言葉だ。
2010-04-18
2010-04-17
色々考えさせられた
新しいプログラミング雑誌に、Bjarne Stroustrupのインタビュー記事を載せようという話が決まって、StroustrupとC++について、色々話しあってみた。
初心者用のC++の参考書は、どうあるべきかというのが、なかなか考えさせられた。
良い入門書というのは、言語機能を教えるのではなく、プログラミングにしたがって、必要な言語機能をあわせて解説していくべきだという意見だった。Bjarne Stroustrupの、Stroustrup: Programming -- Principles and Practice Using C++は、そういう主眼をもって書かれたらしい。
私が今書いているC++の本は、到底、初心者用ではないのだが、果たしてどこまで、言語の詳細を書くべきか。
たとえば、overloadのcandidate functionsが、どのように選ばれるかということの詳細は、書いても、あまり役には立たない。確かに、言われれば、このように厳密に定義しなければならないというのは分かるが、だからといって、それを知っていても、優れたプログラマにはなれない。
難しい。とりあえず、インタビュー記事を翻訳し終わったので、執筆を再開する。このBjarne Stroustrupへのインタビュー記事は、プログラミング雑誌の創刊号に載る予定である。
2010-04-15
VS2010がちらつく問題を、たぶん再現できた
少なくとも、C++のエディタに関しては、あまり問題はない。問題は、HTMLとXMLのエディタだ。普通に使っている分には問題がない。ただ、いま編集中の、あるファイルに限り、ちらつくのだ。
これが、どうも良く分からない。試しにでかいHTMLファイルを、新しく作ってみたが、単にファイルサイズが大きいだけでは、チラツキは起こらない。
elementを増やしても、複雑にネストしても、やはり、チラツキは起こらない。
試しに、問題のあるそのファイルのテキストを、別のファイルにコピーしてみたところ、やはり、ちらついた。何が問題なのだろう。
前に書いた、別の、これまた数十KBのファイルサイズの、HTMLファイルを編集してみた。これは、ちらつかない。どういう事だろう。
再現する方法がわかった。
- Word Wrapを有効にする。
- 長い文字列を、改行を使わず、一行で入力する。
HTMLも、ファイルサイズも関係なかった。問題は、Word Wrapにあった。しかし、たったの十行程度、Word Wrapしたぐらいで、こんなにちらついてもらっては困る。実装に問題があるのではあるまいか。
さらに、半角アルファベットではなく、日本語を入力すると、この問題が顕著に現れる。IMEを使って入力すると、文字がちらつくので、さらに分かりやすい。ただ、普通に直接入力していても、やはり、ラグを感じる。
求む、マシなHTMLエディタ
こんなエディタが欲しい。
- Windows上で動く
- HTML、XHTML、XML、Javascript、CSSをサポートしていること
- UTF-8、UTF-16、UTF-32をサポートしていること
- シンタックスハイライト、補完機能あり、Javascriptに対しては、DOM level 3も補完可能。
- IMEも問題なく使えること
- ちらつかないこと、遅くないこと
VS2010のIDEがちらつく
たったの40KBのHTMLファイルを編集するのに、文字がちらつく。
IMEで、エンターを押して確定するたびに、入力した文字が、ちらつく。おい、いまどきフリッカーかよ。あり得ないだろ。おまえら何のためにWPF使ってんだよ。GDIによる描画よりひどくなってどうするんだ。アホか？ 脳髄まで完全にやられたか？
数GBのHTMLファイルを編集するというなら、分からないのでもない。たったの40KB程度のHTMLファイルを編集するのにちらつくとは、どういう事だ。これでどうやってWebを設計するのだ？ IE専用か？ 40KBものファイルサイズはでかすぎるってか？
VS2010のIDEがひどい
VS2010のIDE上で、IMEで入力しようとすると、チラツキがあり得ないぐらい多い。ナメてるのか。これじゃ、メモ帳の方がよほどマシだ。Betaよりひどくなっているではないか。
ちなみに、私は、nVidiaのGeforce GTX260を使っている。このGPUで不足というのであれば、大半の環境では、動かないはずだ。
だいたい、このモッサリ感は、どうにかならないのか。明らかに、IMEを使うと、マウスの動きや、キーの入力に対して、体感できるほどのラグがある。何を考えているんだ。
Visual Studioの開発チームに、IMEを使っているプログラマ、テスター、営業その他は、一人もいないに違いない。それどころか、おそらく、マウスもキーボードも使っていないのだろう。もし使っているとするならば、このモッサリ感に耐えられないはずだ。これじゃ、インテリセンスがないメモ帳の方がいくらかマシだ。何を使っているのだろうか。タッチパネルで入力しているに違いない。
2010-04-13
Visual Studioの最悪のユーザーエクスペリエンス
世間では、ユーザーエクスペリエンス（笑）とやらが主流である。特に、マイクロソフトなどは、このようなカタカナを頻繁に使う。では、Visual Studio 2008のアンインストールは、簡単なのだろうか。
Visual Studio 2008をアンインストールしようとして、呆然とした。プログラムと機能にリストアップされている、プログラムの項目が、非常に多い。Visual Studioだけではない、SQLサーバー（これがやたらと多い。同じような名前のプログラムが、いくつもある）だの、Pocket PC開発なんちゃらだの、デバイスエミュレーターだの、office SDKだのと、何十もの項目がある。なぜこんなに必要なのだ。インストールする時は、Visual C++しか選ばなかったはずだ。
普通、アンインストールするとなれば、一発で全部アンインストールして欲しいものだ。なぜ、個々の項目を、ひとつずつ手作業でアンインストールしなければならないのか。
マイクロソフトは、Visual Studioの開発チームをクビにした方がいいのではないだろうか。
ところで、Visual Studio 2010のパフォーマンスはどうか。これも、劣っていく一方だ。もっとも、このテストに使っているのは、パフォーマンスの変化をわかりやすくするため、メモリを256MBしか積んでいないWindows XPという、古臭いにもほどがある環境だそうだが。Visual Studio 2010は、まともにシェーダーをサポートしたGPUを積んでいる環境を前提としているので、まあ、あまり参考にはなりそうもない。
Visual Studio Face-to-Face battle | Tamir Khason - Just code
まあ、インテリセンスがより賢くなるのであれば、ユーザーが気がつかない範囲で、パフォーマンスが落ちても構わないのかもしれない。ユーザーのタイプに、１マイクロ秒、早く反応できたところで、あまり意味はないからだ。
とはいえ、このリンク先でも、やはり、やたらにインストールされるプログラムの数を、疑問に思っている。なぜこれがすべて必要なのか。
ちなみに、今回、私はもはや、学生ではないので、無料のVisual Studio 2010 Expressをインストールした。プログラムの数は、かなりすっきりしている。そして、Expressでも、インテリセンスなどの、主要な機能は、他のエディションと変わらないわけだ。どうなってるんだ。
やはり、Microsoftは、Visual Studioの開発チームを、一刻も早くクビにすべきである。さすが、いまだに、まともにテンプレートをサポート出来ていないC++コンパイラを作っているチームだけある。思えば、Microsoftのコンパイラが、当時、一番テンプレートのサポートが遅かった。
Chrome Devの興味深い変更
Google Chromeのバージョン5.0.375.3で、面白い変更があった。アドレスバーの表示するURLが、scheme nameと、それに続くふたつのスラッシュを、取り除いている。
考えてみれば、URLからサイトを判別するにあたって重要なのは、ドメイン以下の文字列であって、http://などというおまじないのようなschemeではない。
しかし、SSLはどうするのか。試しに、SSLを使うページを見てみると、こちらは、httpsを表示した。これは、当然だろう。SSLを使っているかどうかは、URLのschemeから判断できるべきだ。
また、アドレスバー内のテキストを全部選択してコピーすると、schemeも、もちろんコピーされる。これも、当然だ。
なかなか、悪くない変更と言える。SSLを使っていないWebサイトは、HTTPプロトコルを用いている。皆が同じschemeを用いているのであれば、http://は、意味のないゴミに成り下がってしまう。わざわざ表示する必要はない。それに、この方法の場合、SSLが使われているかどうか、前よりもはっきり分かるようになって、これまた、いいのではないかと思う。
Visual Studio 2010が出たけど、C++0xへの対応はお粗末すぎる
decltypeがnested-name-specifierを使えないとかもあるが、一番の問題は、ライブラリの、rvalue referenceへの対応がお粗末すぎることである。例えば、std::functonalは、rvalue referenceを正しくforwardできない。以下のコードは、VC10では、エラーである。
#include <functional>
struct Func
{
void operator () ( int && ) const { }
} ;
int main()
{
Func obj ;
std::function< void ( int && ) > f( obj ) ;
f(0) ;
}
これでは、せっかくrvalue referenceをサポートしている意味がないではないか。
Dinkumwareの実装が糞なのは、今に始まった話ではないが、一体何を考えているというのだ。コンパイラベンダーのライブラリ自らが、rvalue referenceをforwardできないとは、笑わせるつもりか。
decltypeは、つい先日、ドラフトが変わったばかりなので、仕方がないにしても、rvalue referenceは、つい最近の変更ではない。std::functionが対応していないというのは、お粗末すぎる。
結論として、VC10のC++0x対応は、まったくもってお粗末である。
だいたい、今持ってTwo Phase Lookupをサポートしていないのは、許しがたい蛮行である。これは、C++0x以前の問題だ。
struct Base
{
void f() {}
} ;
template < typename T >
struct Derived : T
{
void g()
{
f() ;// エラーとなるべき。
}
} ;
int main()
{
Derived< Base > obj ;
}
2010-04-10
C++0x本：UnicodeとUCSについて
C++0xでは、Universal Character Setをサポートしている。これは、ISO/IEC 10646で規定されている文字コードである。
ところが、ユニバーサル文字セット、UCS、あるいは、ISO 10646などと言っても、通じない人もいると思われる。ところが、そういう人は、Unicodeと言えば、「ああ、あれねー」と合点してくれるのである。
実際、私なども、日常会話では、Unicodeで済ませている。ユニバーサル文字セットとか、ISO 10646などと言ったりはしない。というのも、それでは、通じないからだ。
さて、C++0xの本を書くにあたって、これを何とかしなければならない。
最も簡単な方法は、単に、Unicodeと呼んでしまうことだ。これは、もちろん、正しくはない。C++0xの規格では、Universal Character Setである。しかし、現実として、Unicodeと混同されているし、実際、コードポイントもエンコード方式も、すべて同じだ。
果たして、あえて「ユニバーサル文字セット」などと書く意義はあるのだろうか。誤解を招くだけではないか。
2010-04-09
limechatに設定しているサーバーパスワードを忘れた場合
LimeChatに設定している、サーバーパスワードを忘れてしまった。IRCのサーバーパスワードと言うのは、結局、平文で送らなければならないわけだ。とすれば、LimeChat2は、何らかの方法で、平文のパスワードを保存しているはずである。
LimeChat2の設定ファイルを見てみたところ、それらしき文字列があった。ただし、何らかの方法で暗号化されている。もちろん、結局は、平文でサーバーに送るしかないパスワードなのだから、当然複合できるはずである。見たところ、何らかの方法で暗号化して、HEXにしているだけのようだ。
とはいえ、これだけの理由で、LimeChat2を解析するのは骨が折れる。なにか方法はないものか。
サーバーパスワードを表示するEDITコントロールは、●で埋まっている。これを取得してみるのはどうか。
残念ながら、設定ファイルに使われているのと同じ、HEXが返ってくるだけであった。抜かりはない。
とすると、limechatをデバッガにかけて解析するしかないのか。まてよ、結局、IRCサーバーには、平文でパスワードを送らなければならないわけだ。ならば、IRCサーバーに送るパケットを読めばいいのではないか。
パケットキャプチャをインストールするのも面倒だったので、socketをbindしてlistenしてacceptしてrecvするだけの、簡易なサーバーを書いた。結果として、無事、パスワードはサルベージできた。
しかし、この程度のことに、C++を使うのは、どうも、鶏を割くのに牛刀を用いているような気がしてならない。何か、socketも話せる、スクリプト言語をひとつ覚えるべきか。
しかし、私は好き嫌いが激しいので、世に出回っているスクリプト言語は、あまり気に入っていない。唯一、Javascriptは気に入っている。Javascriptに、明示的に整数やバイト列を扱う機能を付け加え、さらに、ファイルの入出力やソケットなどのライブラリを付け加えれば、結構面白い処理系になりそうなのだが。
2010-04-08
C++0xでは、識別子にUCSが使えるのではなかろうか
いままで、あまり強く意識していなかったが、識別子に、UCSを使えるのは、規格で明確に保証されているようだ。
UCSは、プリプロセッサで、universal-character-nameに置換される。UCNは、もちろん、識別子に使うことができる。
ということは、
int 変数 = 0 ;
このコードは、well-formedであり、このコードをコンパイルできないコンパイラは、規格違反である。はずだ。
追記：いつの間にか、規格の中に、明確にUCSを識別子として許可する文面が入っていた。
2010-04-07
歴史的経緯と理解
C++のテンプレートに関する、歴史的経緯は、是非とも知っておくべきである。Inclusion ModelとSeparation Modelに関する論争。Inclusion Modelをサポートするために、One Definition Ruleに例外を設けたこと、exportなど、知っておくと理解が進む、歴史的経緯が多い。
これらの歴史的経緯は、新しいプログラミング雑誌の記事として、現在、執筆中である。目標は、簡潔なPost D&Eである。D&Eに書いてある事を、今更書いても仕方がない。D&E以降の歴史について、書いている。
2010-04-05
三寒四温の本当の意味
どうも、三寒四温というのは、本来、春先に急に暖かくなったり、寒くなったりということを意味するのではなかったようだ。
朝鮮半島や中国北東部では、冬季に、そのような典型的な寒さの変化があるために、三寒四温というそうだ。日本でも、影響はあるが、あまり強くは感じられないので、春先の気温の変化を指すようになったらしい。
それはともかく、ここ最近は、いかにも日本的な三寒四温だった。
2010-04-04
2010-04-03
2010-04-02
C++プログラマ向けのゲーム
ルールは、10秒以内に、ソースコード上のエラーを見つけて、該当箇所をクリックすること。
追記：よく考えたら、フィード経由で見ている人には、解答が丸見えだ。
一問目：文字列リテラル
二問目：return文
三問目：int tの初期化式
四問目：条件式の中で、代入。
五問目：Addメンバー関数。平均を計算するはずなのに、単なる代入になっている。
六問目：std::string return_valueの初期化式。basic_stringの代入演算子のオーバーロードは、CharT const *型の引数を取る。しかし、0はnullポインターとして扱われるという、C++の欠点によるもの。
floating pointの仮数部を取る
C++では、floating pointの内部表現は、実装依存である。ExponentやFractionを得る、ポータブルな方法はない。
ただし、numeric_limitsに、is_iec559というメンバーがある。これがtrueの場合、IEC 559 Standard準拠であることを意味する。
ということは、もし、is_iec559がtrueであれば、float、double、long doubleのうち、サイズが32bitか、64bitである型は、ビット演算を使うことによって、ポータブルに内部表現を調べられる。
しかし、1 byte = 8 bitである保証はないので、やはり、ポータブルなコードは書けない。
最も、exponentやfractionを取得することを前提としたコードは、もとよりポータブルには書けない。どうでもいいといえば、どうでもいいのかもしれないが。
芥川の杜子春について
Mixiの芥川龍之介のコミュニティで、芥川龍之介の杜子春は、原作の杜子春におけるひとつの結論を出したのではないかという高尚なトピックが立っていたので、バカバカしくなって、ふと書いたコメント。なかなか悪くないと思ったので、記録のために、ここにも貼りつけておく。そもそも、原作と、芥川版で、結論は違うのだ。
そもそも、原作と芥川版の、根本的な違いというと、
杜子春は、三度目に金を受け取るのを断ったが、結局受け取った。 こんどは、田地屋敷を買い、妻をめとり、子をもうけ、使用人を雇い、それなりに堅実な生活をした。 しかし、それでもまだ、満足できずに、仙人の住む、山奥の屋敷を訪れ、自分も仙人になろうとした。
その後、芥川版とほぼ同じ幻が、地獄まで続く。
あの世でも、杜子春は一切口を聞かなかったので、地獄に落ちた。 地獄の拷問でも、杜子春は、一切声を上げなかった。 さて、刑期を終えて、転生することになった。 一切口を聞かない反抗的なものを、男として転生させる価値はないとして、女として生まれ変わった。
杜子春は、生まれ変わっても、一切口を聞かなかった。
杜子春は、美しい女性へと育っていった。 しかし、無口な妻の方が、おしゃべりな妻よりいいという男と結婚して、子供も産んだ。
ある時、夫が、実の子にすら、一言も口を聞かないのは、どういうことだと腹を立て、子供を投げ落として、殺してしまった。 杜子春はそれを見て、「あ」と声を挙げた。
その「あ」の声が未だ終わらないうちに、現実に引き戻された。
仙人は、仙人になるための仙薬を作っているところだったが、あと少しというところで、杜子春は仙人のテストに合格できなかったことに失望した。
「お前の心は、すでに喜怒哀懼惡慾を離れたが、愛だけは離れることができなかった。仙才の得難きや。たとえ薬を飲んだとしても、お前は仙人にはなれん」
杜子春は、諦めて、家に戻った。
後に、ともかくお礼だけは言っておこうと、再び仙人の住んでいる、山奥の場所を訪れたが、そこには、すでに何もなかった。
しかし、そもそも、芥川の杜子春と、原作の杜子春傅は、ぜんぜん違うものでしょう。
原作は、仙人になるのがいかに難しいかということに重点を置いているのに対して、芥川版は、一切の苦楽を排除しても、愛だけは遠離できなかったということを、結論としているわけですから。
じゃあ、芥川版で、仙人が、「お前を殺してしまうつもりだった」と言っているのは何なんだという疑問もわくのです。 愛のない人生なんて、いくら仙力があろうと、無価値であるから、自分と同じ轍を踏ませたくなかったのでしょうか。 それなら、最初から、大金を渡さなかったほうが良かったのではないかと思うのですが。
芥川は、他にも、「仙人」というタイトルの小説を、二つ書いています。（厳密には、三つありますが）
ひとつは、乞食のような格好をした仙人が気まぐれに、貧乏人に金をやる話で、仙人はこの世を超越しているから、貧苦が恋しくなって、わざとそんな格好をしているのではなかったかと結論しています。
もうひとつは、純粋すぎる男が、いともあっさりと仙人になった話です。
これをみても分かるように、芥川の仙人感は、まったく一致していませんね。
まあ、基本的に、芥川という男は、古典を適当にひねくり回して、それで食っていた、売文の徒ですからね。あんまり深い意味を期待しても、無駄だと思いますよ。
サウスパーク：医療用フライドチキン
最近、サウスパークは、英語圏の文化に強く依存したエピソードばかり放送している。今回も、解説が必要だと感じたので、解説しておく。
医療用のマリファナについて
まず、アメリカの一部の州では、末期がん患者やエイズ患者などの病人のために、医療用のマリファナを処方しているところがある。マリファナの効用としては、鎮痛作用や、嘔吐抑制などがある。マリファナには、依存性や副作用があるが、それは、どんな薬でもあるのであって、利点が優っているのであれば、薬としても使えるのである。例えば、睡眠導入剤や、咳止め薬の類も、依存性がある。
Jamie Oliverについて
彼は、学校における、KFCやマクドナルドなどの、加工品を給食として出すことに反対している。作中で、カーネル・サンダースが、彼を嫌っていて、暗殺指令までだすのは、そのためである。
半裸の女性が、ケンタッキのフライドチキンを用意しているのは、有名な犯罪映画、New Jack Cityや、American Gangsterへのリファレンスと、違法な麻薬としてのマリファナというものは、あのように仕分ける作業があるということを、念頭に置いている。
また、作中では、カートマンが、キリスト教によって行われた、複数の小児性愛に関する事件を参照して、"Do I wanna do it? Does the pope help pedophiles get away with their crimes?"、と発言している。
2010年のジョークRFC：パケットに気分を表現するTCPオプション
RFC 5841 - TCP Option to Denote Packet Mood
面白い部分だけを訳した。
概要
このドキュメントは、気分を表現する、新しいTCPオプションを提案するものである。
この文書について
本文書は、インターネットの標準規格ではな、情報提供の目的を持って公開せられる。
説明
パケットというビット列は、気の遠くなるほどのハードウェア上のレイヤーをくぐり抜けて、世界中を駆け巡る。而して、パケットは、気分を有せざるなり。彼らはデータをひとつのシステムから他へ運ぶの目的によりて作られたるものにして、感ずる能わざるものなり。
さりながら、ある特殊の状況においては、気分という情報を付加して可なり。
例えば、いつまでたってもACKが返ってこず、再送を余儀なくされたとき、パケットは、「怒り」の気分情報を付加されべきものである。また、なんども再送が起こるの時は、それ「イライラ」パケットなり。
これらの気分をパケットに付加するためには、TCPヘッダーに、TCPオプションを付け加えて、ASCII文字にて、一般に使われている、気分を表現する文字列を送信するべきである。
単純気分表現
一般的な気分を、パケットの気分として付加する。パケット自体は、気分を感ずることはない。この気分は、ユーザーの気分を反映したものである。
したがって、パケットが人間の気分を表現する場合は、ソースは人間となる。
以下の単純気分が提案されている。
ASCII Mood ===== ==== :) 幸せ :( 悲しい :D 興味津々 %( 混乱 :o もう飽きた :O こりゃ驚いた :P クソ :@ イライラ >:@ 怒り :| 無感情 ;) コソーリ >:) 邪悪利用例
パケットの気分は、二種類の状況で表現される。まず、TCPセッションの状態による気分。それと、もっと高位、高レイヤー上での状況を反映した気分である。
幸せパケット
健康的なパケットは、幸せなパケットである。もしACKパケットが、両者間において、10ミリ秒以内に返された場合、双方向で高速な転送能力があることを意味する。そして、再送が必要なく、すべてのACKが受信されたならば、後続するすべてのパケットは、「幸せ」とマークされるべきである（SHOULD）。
ロスがなく、低レイテンシーのパケットは、ユーザーをも、幸せにするものである。したがって、このパケットは、エンドユーザーエクスペリエンスをも、反映していることになる。
悲しいパケット
もし、あるセッションにおけるパケットの再送率が20%以上である場合、そのセッションは、善良なる一般パケット達にとっては、インターネットにおける世紀末、ヒャッハー状態であるといって差し支えない。
この状態を、「怒り」と混同してはならない。
興味津々パケット
テキストのジョークを運ぶすべてのパケットは、「興味津々」とマークされるべきである（SHOULD）。
例：
パケット「いいか、お前ら送信押すなよ！ 送信押すな！ 絶対に送信押すなよ！」
ユーザー「このデータ誰が運ぶ？」
パケット「いや、それはちょっと」
他のパケット群「俺がやる！」、「いや、俺がやるよ！」、「俺に決まってるだろ！」
パケット「あ、じゃあ俺も・・・」
一同「どうぞどうぞ」このような使い古されたジョークで笑うには、オバサンの笑い声などの、明示的なマークが必要である。
混乱パケット
パケットが混乱しているとはどういうことか。ネットワーク上には、パケットのロードバランスを調整しているハードウェアが存在する。このようなハードウェアを介した、ホスト間の通信には、レイテンシーが定まらず、out-of-orderなパケットが到着することが、起こりうる。
受信ホスト側が、out-of-orderパケットを受信したならば、返信するTCP ACKパケットは、混乱とマークされるべきである（SHOULD）。
また、アプリケーションの開発者は、パケットの送信するデータが、複雑怪奇な哲学上の疑問、例えば、「人生の意味とはなんぞや」であるとか、「宇宙における各人の立ち位置とは如何」、などを含む場合、混乱とマークするべきである（SHOULD）。
もう飽きたパケット
デビットやクレジット番号などのデータを含むパケットは、「もう飽きた」とマークされなければならない。（MUST）
多くの人は、RFCとはつまらないものであると考えている。RFCのテキストを含むパケットも、「もう飽きた」とマークしてもよい（MAY）。
電話帳のデータを送信するパケットは、「もう飽きた」とマークされなければならない（MUST）。
法的文書を含むパケット、あるいは、学術用語やラテン語を含むパケットは何でも、「もう飽きた」とマークされるべきである（SHOULD）。
こりゃ驚いたパケット
20ミリ秒も待ちぼうけたあげく、やってきたパケットが、out-of-orderパケットであったならば、万人の驚くところである。
パケットには誕生日はない。そこで、パケットが良きせぬエラーに見舞われた場合は、こりゃ驚いたとマークできる（can）。
つまり、ICMP到達不能メッセージを受信した場合、（おそらくは、ルーティング・ループや混雑により破棄されたなどの理由で）、後続するパケットはすべて、こりゃ驚いたとマークされるべきである（SHOULD）。
クソパケット
すべてのパケットは、セッションによって送信されるのではない。TCPセッションにおける、クライアント・サーバー間のランダムなkeepaliveなどだ。このようなランダムで遊び要素を含む通信は、クソとマークされるべきである（SHOULD）。
イライラパケット
一度以上再送されたパケットは、イライラとマークされるべきである（SHOULD）。
怒りパケット
再送されたパケットは、怒りとマークされるべきである（SHOULD）。
コソーリパケット
パケットが、とても賢い方法で使われている時、コソーリとマークされるべきである（SHOULD）。「賢い」とはなんであるかという事については、異論が多い。そこで、該当のパケットが賢いかどうか、複数の意見を参考にするべきである。
邪悪なパケット
TCPパケットが、モラルを認識するのは、困難である。例えば、「人生の意味」であるとか、「邪悪の明確な定義」であるとかなどだ。とはいえ、TCPベースのアプリケーションの開発者は、ある種の行動を、邪悪であると考えている。そのようなパケットは、邪悪とマークされるべきである（SHOULD）。
ある団体は、この気分を禁止しているかもしれない。IP ヘッダーのセキュリティフラグである、[RFC 3514]を禁止するのと、同じ理由である。
セキュリティに対する考察
悪意ある攻撃者によって、幸せ":)"パケットの口が、ねじ曲げられ、しかも、ウインクを付加されるかもしれない、";("。これは、送信者の意図した気分をねじ曲げるものである。
RFC4041、モラルに対する考察の項目も、欲しかったところだ。
2010-04-01
Raw String Literalは、まだ決定していない
実は、標準化委員会内に沸き上がっている、意見に、Raw String Literal自体が、プリプロセッサの逆変換の対象になるべきだというものがある。
つまり、
R"delimiter( )deli\ miter" )delimiter" ;
は、
" )deli\\\nmiter\" "
となる。現在の文面では、このコードは、ill-formedである。
そもそも、プリプロセッサは、文字列リテラルを、ひとつのトークンとして、認識できなくてはならないので、これは、当然だと思う。
文字列リテラルを、ひとつのトークンとして認識するので、Raw String Literalの中に、Preprocessor Directiveがあっても、問題はない。
C++標準化委員会より、FCDへのNBコメント募集のお知らせ
通知
とうとう、C++0xの、FCD(Final Committee Draft)が発行されました。これに伴い、一般からでも参加出来る、C++標準化委員会のアドホック会議と、一般からの、FCDに対するコメントの募集を行います。私は、今回、コメント募集の受付を担当します。
予定スケジュール
現在： FCD発行完了。NBコメントの募集を開始。
5月23日： NBコメントの募集を〆切。
5月29日： アドホック会議の開催。
以降：議論の結果、NBコメントとして送ることを決定したコメントの英訳。送信。
C++0xのFCDに対する、コメントの募集
FCD(Final Committee Draft)の投票が始まりました。ドキュメントは、以下のURLからダウンロードできます。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf
今後、発行されたFCDに対して、日本のC++標準化委員会から、日本国としての意見、NBコメント（National Body Comments）を出します。
NBコメントは、一般から広く募集しています。
コメントとは、FCDに対する、スペルミス、英文法違反などといった単純な間違いから、矛盾点、文面では定義されていないケースで、特に明確な定義を要するもの、などの指摘です。FCDでは、もはや、大幅な変更はできません。
募集の締め切りは 5月23日(日)です。
寄せられたコメントについては、5月29日(土)に開催する会議にて議論したいと思います。
なお、書式を合わせるため、コメントは以下の形式でお願いします。
- N3092に対する、章番号,パラグラフ番号 (全般に関わるコメントについては、不要)
- 指摘内容
- どのような修正を要求するか
例：（この問題は、すでに、他の箇所のサンプルコードも、把握しています）
場所：8.5.1 Aggregates [dcl.init.aggr] paragraph 7
指摘内容：
サンプルコードで、文字列リテラルから、char *への代入がある。4.2 Array-to-pointer conversion [conv.array]には、もはや、文字列リテラルから、暗黙のうちに、非constな文字型へのポインタに変換する文面はないので、これはill-formedである。
修正案：
char *をchar const *に変更する。
コメントは、メールで、boostcpp@gmail.comまで送ってください。寄せられたコメント案に対して、折り返し質問を送る場合があります。
コメントは、もちろん日本語で構いませんが、できれば英訳版も一緒に出してくれると助かります。最終的に、英訳しなければならないからです。
C++標準化委員会の、アドホック会議
私は、アドホック会議受付の担当ではありませんが、関連するために、告知だけしておきます。
FCDの公開に伴い、日本のC++標準化委員会では、アドホック会議を開催します。これは、一般からの参加ができる会議です。アドホック会議では、募集したコメント案を議論して、日本のC++標準化委員会として、本部に送るNBコメントを決定します。
日時と場所は、以下の通りになっています。
日時: 5月29日(土) 10:00～17:00
場所: 東京都港区赤坂2-17-22 赤坂ツインタワー サイボウズ・ラボ、地図
アドホック会議への参加希望の受付は、サイボウズ・ラボの、光成滋生さんが管理する予定です。光成さんが受付方法を公開しだい、リンクします。
光成さんが、参加受付を作成しました。下記のリンクから、アクセスできます。
現在の予定では、一般からは、十人程度参加出来る見込みです。
メモリ内だろうがHDD内だろうが、ダウンロードはダウンロード
高木浩光＠自宅の日記 - Nyzilla Pro版、ストリーミングプレーヤ搭載へ
メモリ内だろうが、HDD内だろうが、ダウンロードはダウンロードではないのか。それを考えれば、ストリーミングなどというものは、始めから、単なる概念に過ぎないのではないのか。
つまり日本は、Winnyによる著作権侵害をしているかどうか、合法的に調べることが出来ないし、マルウェア解析も、合法的にできないのである。
問題は、情を知ってファイルをダウンロードすることは、違法であるという事実である。しかし、そのファイルが違法であるかどうかは、実際にダウンロードして、確かめるしかない。Winnyでは、ダウンロード以前には、ファイルの情報というのは、ファイル名やファイルサイズ、MD5ハッシュ値しか得られない。まあ実際のファイルをダウンロードせずとも得られる情報というのは、このぐらいなものである。もし、検証のためにダウンロードしたファイルが、ファイル名とは全く別の内容で、自分が著作権を持っていないとしたら、それは、違法である。なぜなら、確実に、事情を知っているわけだからだ。
まてよ、Winnyによる著作権侵害をしているかどうか、合法的に調べることができないのであれば、そもそもそれは、摘発不可能ということではないのか。証拠がないのに、摘発、検挙、起訴出来るわけがない。
これは問題ではないのか。というのも、違法な捜査による証拠は、認められない。これを認めてしまうと、色々と問題が起こるからだ。とすれば、違法をしているのは明白であるのに、その確実な証拠を得ようとする捜査が違法である今の日本の現状は、著作権侵害天国とも名づくべき状態になっているのではないだろうか。
結局、望ましいのは、法律を訂正することである。
しかし、思うのだが、法律こそ、バージョン管理システムを用いて、diffを公開すべきだと思うのだが。
using directiveは、宣言にあらず
本の虫: ADL再考の問題が解決した。
using directiveは、宣言ではない。name lookupに、直接影響するのである。よって、ADLには、何の影響も及ぼさない。ADLが動くべき時には、相変わらず動く。
完全に自信を喪失中。これは、難しい。
今年の四月一日ネタ
Google Japan Blog: Google日本語入力チームからの新しいご提案
Google Japan Blog: Google 音声検索が動物の鳴き声にも対応しました。
Google Japan Blog: 本日、Google検索にしりとり機能を追加しました!
GIGAZINEが、それなりに網羅的なまとめをしている。
【リアルタイム更新中】エイプリルフールに便乗しているサイトまとめ2010年版 - GIGAZINE
GeForce GTX 480: Is it Hot Enough to Fry an Egg?
GeForce GTX480では、卵を調理出来るかどうか実験。結果は、出来なかった。
追記予定