2010-03-31

ADL再考

以下のコードが、どうも解せない。

namespace A
{
    class class_in_A {} ;
    void f(class_in_A) {  }
}

namespace B
{
    void f(A::class_in_A) {  }
}

int main()
{
    A::class_in_A obj ;

    // lookup A::f via ADL.
    f(obj) ;

{
    using B::f ;
    f(obj) ;// ambiguous.
// B::F is using declaration. Y is not empty.
}

{
    using namespace B ;
    f(obj) ;// lookup B::f.
// because it is not a using declaration, Y is empty.
// GCC, MSVC, Comeau disagreed and make it ambiguous.
}

{
    using namespace B ;
    using B::f ;
    f(obj) ;// ambiguous? because it also contains using declaration?
}

}

規格を素直に解釈すると、こうなると思うのだが。

追記:ambiguousが正しかった。

Raw String Literalとプリプロセッサ

行連結は Raw string literal を解釈するフェーズより前のはずなんだが、
どうなってるんだろう?

いい質問だ。日本もまだまだ捨てたものではない。惜しむらくは、そこまでわかっていながら、なぜドラフトやペーパーを読まないのか。

そこは、なかなか面白い。簡単に言えば、Phase 3で、Raw String Literalに限っては、Phase1, 2で加えられたプリプロセッサによる変換の、「逆変換」を行うのだ。

2.2 Phases of translation [lex.phases] p3

Within the r-char-sequence of a raw string literal, any transformations performed in phases 1 and 2 (trigraphs, universal-character-names, and line splicing) are reverted.

もちろん、ユーザーは、このような規格上の定義は、気にする必要はない。ただ、Raw String Literal内では、プリプロセッサによる変換が行われないと考えておけば、それで問題はない。詳細は、Language lawerの仕事だ。

N3077: Alternative approach to Raw String issues

追記:C++の規格というのは、規格の定義する意味と同じであれば、どのような実装をしても構わないものである。だから、Raw String Literalであることを認識する、賢いプリプロセッサがあってもいいし、実際、ペーパーによれば、多くのコンパイラの実装では、この変換を、覚えているらしい。

Apparently many compilers already keep track of those transformations internally.

どうも、Chromeのパフォーマンスが落ちたような

どうも、最新のDev版のChromeのパフォーマンスが、悪いような気がしてならない。ページのが完全に読み込まれるまで、反応がなくなる。まあ、Dev版なので、こういうこともあるだろうが、早く直して欲しいものだ。

ブログのレイアウトの調整中

セーブして、デフォルトのテンプレートに戻してみるか。どうも、エラーが取れない。

デフォルトのテンプレートを使っても、エラーが出る。Bloggerのせいだろう。

どうも、Bloggerのテンプレートが生成するHTMLで、</p>がひとつ、ミスマッチしている。Bloggerのテンプレートが、あまりにもぐちゃぐちゃで、どこを修正していいのか分からない。

追記、問題箇所を発見した。公式テンプレなのに、p要素がネストしていた。ひどい。

threadは明示的に使うべし

FCDで、thread周りの文面が、さらに明確に定義されるようになった。

たとえば、threadのデストラクタだ。もし、joinable()がtrueを返すthreadオブジェクトのデストラクタが実行された場合、terminate()が呼び出される。それ以外の場合、なにもしない(スレッドは、自分で実行を終えるまで、動き続ける。)

なぜか。もし、暗黙的に、join()やdetach()が呼び出される設計であれば、バグの温床になりえるからだ。

move代入演算子は、move元のオブジェクトが、joinableであった場合、terminate()を呼び出す。これはどうだろう。まあ、たしかに、join()している最中にmoveされたら、たまったものではない。join()出来る可能性があるオブジェクトをmoveするというのは、バグとみなしてもいいのかもしれない。

ChromeがFlash Playerをバンドルした

Chromium Blog: Bringing improved support for Adobe Flash Player to Google Chrome

Flash Playerは、最も普及している、ブラウザのプラグインである。

最新のChromeのDev版は、Flashをバンドルすることにした。つまり、Chromeのアップデートのフレームワークを使って、Flash Playerも、自動的にアップデートされる。

これにより、古いバージョンのFlash Playerを使い続けることによる、セキュリティのリスクがなくなる。Chromeと同じく、自動的に、静かにアップデートされるからだ。

現在、この機能は、実験的なため、コマンドライン引数に、--enable-internal-flash、を指定しないと、動かない。

また、ごく初歩的な、プラグインの管理機能を、about:pluginsタブに、実装した。

この機能は、なるべく早く、安定版にも取り入れるべく、努力されている。

まあ、何と理想をいおうとも、現時点では、まだ、Flashを捨て去ることはできない。とすれば、これは、現実的な問題の解決方法なのだろう。

例外指定について

そもそも、例外指定をdeprecatedにする意味は、例外指定が、現実の世界では、全く役に立たなかったからである。

noexceptの目的は、関数は例外を投げないと明示することより、コンパイラに、最適化のヒントを与えるものである。静的なソースコードの解析が目的ではない。

例外指定の、かつての目的は、単なるシンタックスシュガーであった。最適化のヒントは、全く意図していなかったのである。

なぜ、現実世界では、例外指定は、笑えるほどに失敗したのか。テンプレート引数がどのような型なのか、わからないからである。

template < typename T >
void f( T x ) 
{
// Tのコピーコンストラクタが例外を投げるかもしれない。
}

このようなコードで、例外指定で、実際に投げる例外を指定出来るわけがない。

では、noexceptを指定したコードで、例外を投げるパスがある場合、コンパイラはエラーを出すべきであるという意見はどうか。これは、非現実的である。そのためには、翻訳単位を超えた、大規模な静的解析が必要である。すべてのコンパイラに、そのような実装を求めるのは、現実的ではない。

確かに、エラーになれば、理想的だ。しかし、そんな機能は、exportと同様、主要な実装から、無視されるだけである。

もう一度いう。従来の例外指定は、現実的に無意味なため、廃止された。noexceptは、最適化へのヒントという役割のためだけに採用された機能である。

ただし、規格の文面は、コンパイル時のエラーを、禁止していない。つまり、優れた実装ならば、そのような機能を提供できる。現在、そのような意味を含めた文面を、明示的に追加するべきかどうか、議論中である。

2010-03-30

post-Pittsburgh mailingの簡易レビュー

post-Pittsburgh mailingが公開された。

最新のWorkind Draftは、N3090となった。また、FCDが、N3092として、公開された。中身は、ドラフトとほぼ同じである。これで、後は、修正ぐらいしかできない。がしかし、ひょっとしたら、またもう一度、FCDを出すかもしれない。いずれにせよ、C++0xの規格は、2011年内に、制定されるだろう。

N3047: Fixing is_constructible and is_explicitly_convertible

is_constructibleを、is_explicitly_convertibleと同等にする提案。その結果、is_explicitly_convertibleは、廃止される。

N3048: Defining Swappable Requirements

Swappable Requirementsの追加。言語機能としてのconceptが廃止されたので、概念として定義する必要がある。

N3049: Core issues 743 and 950: Additional decltype(...) uses (revision 1)

decltypeを、より、「型」として使えるようにするための修正。

N3050: Allowing Move Constructors to Throw (Rev. 1)

ライブラリのMoveコンストラクタのrequirementsで、throwを禁止しているが、これをやめる。moveコンストラクタ内からthrowして欲しくない場合は、std::move_if_noexceptw()を使う。

N3051: Deprecating Exception Specifications

例外指定をdeprecateにする。例外指定は、現実では、まったく意味がなかった。例えば、テンプレートが絡むと、明示的に投げる可能性のある例外を指定するなどということは、不可能になってしまう。

ただし、いくつかのコンパイラでは、何も指定しない、throw()を、関数は例外を投げないという指定とみなして、そのような最適化をしている。そこで、noexceptというキーワードを、新たに導入して、「この関数は例外を投げないと保証できる」と宣言出来るようにした。

互換性のために、nothrow()は、noexcept(true)と、同じシグネチャになる。

// noexceptと、noexcept(true)と、throw()は、同じシグネチャとして、認識される。
void trust_me() noexcept ;
void trust_me() noexcept(true) ;
void trust_me() throw() ;

// noexcept(false)と、throw(...)は、同じシグネチャとして、認識される。
void I_will_throw() noexcept(false) ;
void I_will_throw() throw(std::exception) ;

// 例外指定のない関数は、noexcept(false)やthrow(...)とは、違うシグネチャとして、認識される。
void dunno() ;

ちなみに、noexcept、noexcpt(true)、throw()と指定された関数が、もし、例外を投げた場合、std::terminate()が呼ばれる。こう規定することには、ひと議論あった。しかし、この指定はそもそも、例外を投げないという保証を、ユーザーが宣言するのである。例外を投げた場合、どうなろうと、知った事ではない。ユーザーの責任である。

ではなぜ、undefined behaviorではないのか。undefined behaviorでは、ポータブルなコードを書くことができない。たとえば、最適化の結果として、オブジェクトのデストラクタなどが呼ばれず、例外が関数外に送出されるということが起こり得る。これは、セキュリティ上、非常にまずい。

また、std::terminate()を呼び出すと規定しても、パフォーマンス上の影響はないと、その場にいた実装者は、全員同意した。meetingの後に、gccの実装者が、MLで、gccの現状の実装では、コストは全くないとはいい切れないと訂正したが、では、実際に目に見えるコストがかかるかどうかは、その実装者としても、断言できないそうだ。というわけで、コストは、ほぼない。

N3052: Converting Lambdas to Function Pointers

キャプチャリストが空のlambda式を、関数ポインタに変換出来るようにする提案。

void (* ptr )( int ) = [](int) {} ;

N3053: Defining Move Special Member Functions

データメンバーが、すべてmovableであった場合、moveコンストラクタを自動的に定義しようという提案。

N3055: A Taxonomy of Expression Value Categories

lvalueとrvalueを細分化してカテゴリ分けする。詳細は、本の虫: N3055: A Taxonomy of Expression Value Categoriesを参照されたし。

N3056: Conceptless Random Number Generation in C++0X, version 2

乱数ライブラリから、conceptの名残を取り除く提案。

3057: Explicit Initializers for Atomics

atomicオブジェクトのメモリオーダーなどを、明示的に指定して初期化出来るようにする提案。

N3058: Futures and Async Cleanup (Rev.)

futureとasyncライブラリに対する、雑多な細かい修正。

N3059: Proposal to Simplify pair (rev 5.2)

息の長い、pairを単純化しようという提案。

N3060: Extensions to the C++ Library to Support Mathematical Special Functions

C99の数学用の関数を、C++に取り入れる提案。誰が使うのだろう。

N3062: Core issue 789: Fixing Raw Strings wrt. Trigraphs (revision 1)

トライグラフの大半を、規格から削除する。IBMが使っているトライグラフだけは、互換性のために、残す。

N3063: Core issue 968: Disambiguating [[ (revision 1)

attributeと、lambda式、配列とで、文法が曖昧になる。今までの規格では、[[というトークンは、すべてattributeとして解釈するという文面だったが、問題なので、修正する。

以下のようなコードが、問題になる。

int x[10] ;

// x[1] = 0 と同じ。
x[[](){ return 1 ; }()] = 0 ;

N3064: Core issue 374: Explicit specialization outside a template's parent (revision 1)

名前空間の外側で、明示的な特殊化を許可する。

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

N3065: Removing Export

exportの廃止。deprecateではなく、完全な削除。ただし、exportというキーワードは、予約語として残す。exportの経緯については、Stroustrup: HOPL-3を参照されたし。よくまとまっている。

N3066: Iterators in C++0x

conceptの研究で得られた成果を、イテレーターに反映させる。

N3067: Core issue 951: Various Attribute Issues (revision 1)

attributeに対する、細かな変更。

N3068: Equality Comparison for Unordered Containers (Rev 2)

unorderedコンテナ同士を、同じかどうか、比較出来るようにする。

N3069: Various threads issues in the library (LWG 1151) (revised)

スレッド間のライブラリの利用における、いくつかの問題を解決。たとえば、複数のスレッドから、ひとつのストリームを読み書きした場合、同期されるのかどうかなど。

N3070 - Handling Detached Threads and thread_local Variables

detachされたスレッドの、thread_local変数のデストラクターが走るタイミングと同期に関する問題の解決。

N3071: Renaming launch::any and what asyncs really might be (Rev.)

名前の通り。launch::anyという名前を、launch::sync_or_asyncに変更する。

N3072: Harmonizing Effects and Returns Elements in Clause 21

stringライブラリの文面が間違っているので、それを修正。

N3073: pecifying Pointer-Like Requirements (Revision 1)

名前通り。ポインターのように振舞う型というrequirementsを定義する。

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

同期まわりの文面の修正。

N3077: Alternative approach to Raw String issues

Raw string literalが、大幅に変わる。

まず、"[...]"ではなく、"(...)"という形に変わる。さらに、Raw string literalは、本当に、Rawになる。つまり、UCNのエスケープシーケンスや、トライグラフ、プリプロセッサの、行末に\を指定することによる、改行の削除の影響すら、受けなくなる。

char const * ptr = R"delimiter(\u1234
\
)delimiter" ;

これは、従来の文字列リテラルでは、

"\\u1234\n\\\n"

と同じである。つまり、UCNも気にしなくていいし、プリプロセッサによる改行の削除の影響も、気にしなくてよくなる。ついに、本当の意味でRawになった。

N3078: Allowing constexpr for reference parameters

constexprな関数の仮引数に、参照を使えるようになった。

constexpr int f( int const & value )
{
    return value ;
}

N3079: Redrafting: issues 667, 861, 990, 818

Issue 667, Issue 990, Issue 818, Issues 861, 919, 920、への解決策。例えば、issue 818については、本の虫: こんな変更ありかよを参照されたし。

N3055: A Taxonomy of Expression Value Categories

N3055: A Taxonomy of Expression Value Categories

lvalueとrvalueが、新たに細分化されてカテゴリ分けされる。

そもそも、rvalueというのは、実際のストレージを持たなくてもいいオブジェクトである。これに対して、rvalue referenceは、実際のストレージが必要である。rvalue referenceを、既存のrvalueという概念に当てはめると、問題がある。

しかし、rvalue、lvalueは、60年代から使われている用語である。その当時からすでに、単なる右辺、左辺という意味ではなかった。

そこで、lvalueとrvalueを、細分化する。

xvalue(eXpiring value)
rvalue referenceに束縛した結果を、xvalueという。これは、eXpiring valueである。rvalue referenceというのは、valueのリソースをmoveするのに使われることから、このように名付けられた。
lvalue
以前と変わらず。
prvalues(pure rvalues)

既存のrvalue、つまり、C++03の意味のrvalueを、prvaluesという。

rvalues

xvalueとprvaluesをあわせて、rvaluesという。

glvalues(generalized lvalue)
xvalueとlvalueをあわせて、glvaluesと言う。

lvalue, rvalueを、左辺値、右辺値などというのは間違っているように、これらは、あえて訳さない方が良い。

これは、新しい機能や概念を導入したわけではない。ただ、既存の概念を、細分化しただけである。

How NOT to write a good javascript code

これでできる! クロスブラウザJavaScript入門:第2回 完全版:ブラウザとデバッグ環境|gihyo.jp … 技術評論社

この記事では、いかにして、バージョンの古いブラウザ環境を構築するかに、紙面の大半を割いている。有害すぎる。

そもそも、バージョンの古いブラウザは、規格を正しく実装せず、必ずセキュリティホールを含んでいるのである。このようなworkaroundは、何も生み出さない。ただ、問題をややこしくするだけである。この記事は、クロスブラウザのための環境構築という大義名分のもと、その実、自分自身が、クロスブラウザに多大な労力をつぎ込まなければならない環境構築の片棒を担いでいるのである。本末転倒も甚だしい。

何のためにWeb標準が策定されているのか。何のために、各ブラウザベンダーは、ブラウザをアップデートしているのか。クロスブラウザなどということを、考えなくても済むようにするためである。この記事は、それらの、より良い未来への努力を、蔑ろにする行為である。もしそれ、真にWebの将来を信じているならば、ブラウザのアップデート方法にこそ、紙面を割くべきである。

今や、ブラウザは、自動的かつ静かにアップデートするのが、主流になりつつある。Chromeは、すでに、この両方を達成している。FirefoxやSafariやOperaやIEは、まだ、ユーザーの許可を求める。これは問題がある。今一歩をあえて進めて、静かにして、かつ、強制的にアップデートするべきである。

クロスブラウザが必要不可欠であるという状況も、変わりつつある。マイクロソフトも、ようやく本腰を上げて、Web標準に追随しだした。現在の発表を信じれば、IE9で、ようやく、他のブラウザの尻に追いつくぐらいのことは、できるだろう。

今や、最大の障害であった、IEですら、変わっていこうとしているのである。それを、このような有害、邪悪な記事でもって、妨げるというのか。

もちろん、実際に、ブラウザのアップデートをしないアホどものために、対応しなければならないという現実がある。それはある。しかし、そのような汚い小手先のworkaroundのための、古い環境の構築方法を公開して、何になるというのだ。

この記事が公開される否や、即座に、はてなブックマークの数字となって、反響が現れていた。そのタグに曰く、「ノウハウ」と。何がHowだ、何が。ユーザーはもとより、Web開発者すら、その心境で、どうしてWeb標準などが普及するというのか。このままでは、Web標準の将来は暗い。

この記事の筆者は、ブログにて、「とくに、Safari/ChromeのWeb Inspector*1や、OperaのDragonflyとかは知らない人も多いと思うので、この機会に試してもらえたら良いなぁと思います。」などと言っている。馬鹿げているにもほどがある。

もし、現段階で、Web InspectorやDragonflyを知らないWeb開発者がいるとすれば、そいつには、開発をさせるべきではない。

嘆かわしいかな、Webの未だにかくあるを。憂うべきかな、ユーザーはもとより、Web開発者の心境すら、旧世紀に異ならざるを。さりとて、吾人、何らの解決策をも持たざるなり。また、やんぬる哉。

こういう記事をありがたがる浅はかなWeb開発者の典型的な例:clear sky source - とてもCSSハックが面倒ですので、何か用意してください

2010-03-29

こんな変更ありかよ

Core Issue 818の解決が、FCDに入るのだが、いやしかしこれは、何の役に立つのだろうか。

template < typename T, typename ... Types >
void f(Types... args, T )


// このコードはill-formed。non-deduce contextのため。
f(0, 0, 0) ;

// FCDにより、well-formedになるコード。
f<int, int, int>(0, 0, 0) ;

ようするに、パラメータパックを、引数リストの最後でなくても、指定出来るようにする変更。ただし、non-deduce contextになる。つまり、argument deductionができないので、明示的に、テンプレート引数を指定してやる必要がある。

何に使うんだろう。こういうことは、できるかもしれない。

// non-deduce contextなので、template parameter packを最後に書かなければならない。
template < typename T, typename ... Types >
void f( Types... , T ) { }

template < typename ... Types >
void g( Types ... args )
{
    f< Types..., int >( args... , 0 ) ;
}

しかし、単に引数の順番という以外の利用方法を、思いつかない。第一、deduceできないのだから、その利用方法が、極端に限られているし、書きにくい。それに、正しいコードを書くためには、argument deductionの、詳細なルールを知っていなければならない。

例えば、以下のコードは、ill-formedである。

template < typename ... Types, typename T >
void f(Types... args, T ) ;

なぜなら、fはnon-deduce contextだからだ。詳しい理由が知りたければ、14.9.2 Template argument deduction [temp.deduct]を熟知する必要がある。こんな微妙すぎる言語仕様、果たして、誰の役に立つというのか。ちなみに、こういうふうに変更した理由は、inconsistentだからだそうだ。いくら言語的にconsistentだとしても、誰も恩恵を受けない言語仕様は、language lawyerはともかく、必要あるのだろうか。

3Dプリンター

すごい時代になったなぁ。

古典的なチューリングマシーン、開発さる

これはすごい。

2010-03-28

attributeは難しい

post-Pittsburgh mailingの公開まで、いよいよ日が迫ってきた。FCDが公開されたならば、直ちに変更点を把握して、参考書の執筆を始めなければならない。

ところで、実は、いまもって、よく理解出来ないことがひとつある。attributeだ。

attributeがよく分からない。というのも、あまりにも、記述出来る場所が多すぎるので、一体、どこに書いていいのか、迷うのだ。

たとえば、ある変数に対して、アラインメントを指定したいとしよう。

// 16バイトにアラインメントされてほしい。
char buffer[64] ;

目的は様々だが、とにかく、この変数が、16バイトのアラインメントされていてほしい。では、既存のコンパイラは、どのような拡張機能を提供しているのだろうか。

MSVCの場合、__declspecというキーワードの、一種の、specifierが存在する。以下のように使う。

// どちらも同じ意味。
__declspec( align(16) ) char buffer1[64] ;
char __declspec( align(16) ) buffer2[64] ;

GCCの場合、__alignof__や、__attribute__という、キーワードがある。

// すべて同じ意味。
__attribute__ ((aligned (16))) char buffer1[60] ;
char __attribute__ ((aligned (16)))  buffer2[60] ;
char buffer3 [60] __attribute__ ((aligned (16))) ;

両者とも、何とも、ファジーな文法ではある。

まず、C++0xの、attributeの文法を見てみる。attributeは、実に様々な場所に、記述できる。

[[/* #1 */]] char [[/* #2 */]] buffer [[/* #3 */]] [64] [[/* #4 */]] ;

さて、アラインメントは、どこに記述すればいいのだろうか。

7.6.2 Alignment attribute [dcl.align] p1を読むと、アラインメントのattributeは、「関数パラメーターか、register」以外の(つまり、関数パラメーターや、registerな変数には指定できないという意味)、変数(Variable)か、クラスのデーターメンバー(ただし、ビットフィールドを除く)に指定できる、と書いてある。

この文、非常にわかりにくかったので、わかりやすく改行して引用する。

The attribute can be applied
  to a variable that is neither(i.e except followings)
    a function parameter
  nor
    declared with the register storage class specifier

and(can be applied)
  to a class data member that is not a bit-field.

ということは、一箇所にしか記述できない。すなわち、#3である。

唯一の正しい例は、以下の通りである。

// well-formed.
char buffer [[ align(16)]] [64] ;

以下はすべて、間違った例である。

// ill-formed.
[[ align(16)]] char buffer[64] ;
char [[ align(16)]] buffer[64] ;
char buffer[64] [[ align(16)]] ;

何故か。そもそも、variableというのは、3 Basic concepts [basic] p6に書いてあるように、宣言文によってもたらされる、名前(name)である。ここで、変数の名前とは、bufferである。では、この名前にattributeを指定したい場合は、どこに書けばいいのか。

8 Declarators [dcl.decl] p4に書いてあるように、

noptr-declarator:
    declarator-id attribute-specifieropt

である。つまり、名前の直後に、attributeを指定しなければならない。

この、variable(変数)に対して、指定しなければならないというのは、統一的で、分かりやすい文法である。というのも、C++は、ひとつの宣言文で、複数の変数を宣言できる言語である。

int (*a)(int), b ;

一目瞭然であるが、aは、関数ポインタ型であり、bは、int型である。もし、以下のように、アラインメントattributeを指定できるとしたら、どうにも、言語の文法的に、分かりにくい。

// これはエラー
[[align(16)]] int (*a)(int), b ;

int (*a [[align(16)]] )(int), b [[align(16)]] ;

変数(つまり、変数の名前)に指定するというルールは、文法的には、分かりやすい。ただ、どうも、人間には、わかりやすくないと思う。

int (*a [[align(16)]] [10])(int) ;

まあ、これは、極端な例で、関数ポインタの配列をアラインメントしたいという事は、あまりないだろうが。

基本的に、標準のattributeはすべて、名前に付くとしておけば、とりあえず、参考書の解説としては、分かりやすいだろうか。どうもこの詳細は、参考書で書いても、無駄にページを浪費するだけだと思う。

読み方の分からなかった漢字:蟇

U+87C7、ひきがえる

手持ちの、角川の新字源には載っていなかったので、しかたなく、手書き認識で調べた。

ちなみに、異字体に、「蟆」(U+87C6)という字もあるそうだ。

2010-03-27

中国は、本当にどうしようもないな

中国国内に配置される、DNS ルート・サーバーが閉鎖された? « Agile Cat — Azure & Hadoop — Talking Book

先日、Youtubeや、Wikipediaのドメインが解決できなかった理由というのは、これか。

中国というのは、常に圧政の歴史をたどってきた。西遊記を読めば分かる。西遊記に出てくる妖怪は、時の政府のことである。つまり、西遊記というのは、政府に民衆が立ち向かう話なのだ。これは、司馬遼太郎の言だ。たしか、「街道をゆく」の、どこかに書いてあった気がする。今調べたところ、おそらく10巻だ。

思うに、中国は広すぎるし、多様すぎる。結局、あんな国を、民主主義で治めるのは、無理があるのだ。それゆえ、アカい国になってしまうのである。中国は、ソ連のように分割するべきだと、私は信じる。たとえ、短期的に、混乱があるとしても。たとえ、それによって、経済的にも、人命にも、多大な被害を被るとしても、長期的に見れば、正しい方向であると信ずる。日本も、対岸の火事ではいられない。中国が崩壊すれば、短期的には、直接的にも、間接的にも、不利益を被るだろう。しかし、真に中国の将来を憂えばこそ、中国は崩壊するべきなのだ。

文明の進化神は、一歩も歩みを緩めずして、道に岩石や茨のあるときも、かまわず突破していくのだ。これは、中国が、岩石や茨を、あらかじめ取り除かずに、共産主義という逃げ込んでいたツケである。ツケは、いつか払わねばならない。これは、中江兆民の三酔人経綸問答に書いてある。

現代の陳勝、呉広は、現れるのだろうか。

三酔人経綸問答 中江兆民
街道をゆく (10) 司馬遼太郎

ソニー、ビヨンセの公式YouTubeチャンネルの動画を権利申立により削除する

Of Course! Beyonce's Record Company Puts a Ring On Her Yo... | Motherboard

アホくさいにもほどがある。

それから、Youtubeの埋込みリンクを禁止している動画、あれ、宣伝効果を下げるだけだと思うよ。

いや、もう自分なんぞは、現代の音楽なんて、聴かないから、どうでもいいんだけどね。

videoを利用したパズル

Open Video Sliding Puzzle

videoを利用した、古典的なパズル。

ただし、Firefoxでしか動かない。FirefoxのJavascript拡張機能を使っているのか、あるいは、単に文法エラーなのか。

Chromeでは、配列の範囲エラーになる。Safariでは、setIntervalで、型が違うというエラーがでるが、よく分からない。

これが、実際のライブカメラからの映像を使っていたら、もっと面白いかもしれない。

なぜC++0xの正規表現は、ECMAScript準拠なのか

Boostの正規表現ライブラリで使われている正規表現の文法は、Perl 5を参考としている。一方、C++0xに入る、正規表現の標準ライブラリは、ECMAScript準拠(プラスちいさな拡張機能)である。

オプションで、POSIXのbasic、またはexntended、それに加えて、grepの拡張機能に準拠した文法を使うこともできるが、POSIX規格は、常にLeftmost Longest ruleであり、Non greedy repeatsができないので、grepのようなツールならともかく、プログラミング言語の中で使う正規表現としては、貧弱である。

しかし、TR1は、Boostを参考に作られたはずである。なぜ、違うのか。

Perlの正規表現は、Javascriptプログラマから見ると、少々羨ましい機能がある。特に、independent sub-expressions, zero width look-behind assertions, and interpreted sub-expressionsだ。特に、recursive expressionは、垂涎モノである。

しかし、C++は、Perlのような、具体的な実装ではない。標準規格である。規格である以上、厳密に、正規表現を定義しなければならない。選択肢は、いくつかある。

  1. 正規表現の文法は、実装依存とする。
  2. C++の規格書で、正規表現の文法を、厳密に定義する。
  3. 他の正規表現の規格を、参照する。

1.は、明らかに問題がある。せっかく、正規表現ライブラリがあるというのに、ポータブルに使えないとあっては、だれも使いたがらない。2.は、悪くはない。しかし、正規表現を厳密に定義するのは、かなり時間と労力がかかる。それに、まったく新しい正規表現の文法を定義するというわけでもない。無駄である。

とすると、3.の、他の規格を参照するのが、最も現実的な選択である。では、どの規格を参照するのか。

といっても、実は、しっかりした正規表現の規格というのは、ふたつしかない。POSIXのbasicとextentedか、ECMAScriptである。

Perlはどうなのか。Perlは、厳密な規格というものが、存在しない。それに、Perlの正規表現は、言語機能として組み込まれていることを前提としている。ライブラリベースの実装である、C++には、不向きである。それに、Perl6では、正規表現がガラリと変わる。

そういうわけで、C++0xには、ECMAScript準拠の正規表現が、採用された。

n1429: A Proposal to add Regular Expressions to the Standard Library

Variadic Template Parameterの落とし穴

Variadic Template Parameterの型引数のことを、テンプレートパラメーターパック(Template Parameter Pack)という。

template < typename ... Types >
struct Foo { }

ここでは、Typesは、テンプレートパラメーターパックである。

テンプレートパラメーターパックを、関数の引数に取る場合、これを、パラメーターパックという。

template < typename ... Types >
void f( Types ... args ) { }

ここでは、argsは、パラメーターパックである。

クラステンプレートの場合、テンプレートパラメーターパックは、必ず、テンプレートパラメーターリストの最後に書かなければならない。

// well-formed
template < typename T, typename ... Types >
struct well_formed ;

// ill-formed
template < typename ... Types, typename T >
struct ill_formed ;

これは、テンプレート実引数を指定しても、曖昧になるからである。

関数テンプレートのテンプレートパラメーターリストの場合には、そのような制限はない。なぜならば、関数テンプレートは、引数をdeduceできるからである。ただし、パラメーターパックは、関数のパラメーターリストの最後でなければならない。

// well-formed.
template < typename ... Types, typename T >
void well_formed( T, Types ... ) ;

// ill-formed.
// パラメーターパック、Typesは、パラメーターリストの最後にしか書けない。
template < typename ... Types, typename T >
void ill_formed( Types ..., T ) ;

これができれば、実に、メタプログラミング的な意味で、便利なのだが、残念ながら、これはできない。

ちなみに、こういう事はできる。これは、パラメータリストの型ではなく、パラメーターの型の一部だからである。

template < typename ... Types1, typename ... Types2 >
void f( void (*p1)( Types1 ...), void (*p2)( Types2 ... ) )
{
    // それぞれ、引数の型のデフォルトの値で呼び出す。
    p1( Types1()... ) ;
    p2( Types2()... ) ;
}


void g( int, int, int ) { }
void h( float, float ) { }


int main()
{
    f( &g, &h ) ;
}
// 呼び出すためだけの関数。
template < typename ... Types >
void call( Types ... ) { }

// 任意の戻り値を持つ関数ポインタを、任意個引数にとる。
template < typename ... Types >
void f( Types (* ... t)( void )  )
{
// 関数の実引数の評価順序は、定義されていない。
// どの順番で、引数の関数が呼び出されるかは、実装依存である。
// ただし、すべての関数は、呼び出される。
    call( t()... ) ;
}

int g( void ) { std::cout << "g" << std::endl ; return 0 ; }
int h( void ) { std::cout << "h" << std::endl; return 0 ; }


int main()
{
    f( &g, &h, &g, &h, &g, &h ) ;
}

このcall()関数はネタであって、普通の場合は、以下のような関数を書いた方が良い。

template < typename T >
void call( T t )
{
    t() ;
}

template < typename T, typename ... Types >
void call( T t, Types ... args )
{
    t() ;
    call( args ... ) ;
}

template < typename ... Types >
void f( Types (* ... t)( void )  )
{
    call( t... ) ;
}

これを組み合わせると、

template < typename ... ReturnTypes, typename ... ParameterTypes >
void f( ReturnTypes (* ... t)( ParameterTypes... )  ) { }

int g( char, short, int, long, float, double ) { return 0 ; }


int main()
{
    f( &g, &g, &g, &g ) ;
}

もちろん、これは、ジェネリックではない。しかし、この記述は、引数にとるすべての関数ポインタが、同じシグネチャであることを保証できる。普通のプログラマは、こう書けば良い。

template < typename ... Functors >
void f( Functors ... functors ) { }

2010-03-26

マナーのあるリンクの貼り方

マナーのあるa elementの書き方

<a href="http://www.nikkeibp.co.jp/article/column/20100319/216823/" rel="nofollow">マナーのあるメールの書き方 | キャリワカ:コミュニケーション | nikkei BPnet 〈日経BPネット〉</a>様。

リンクは、様をつけましょう。また、目上のリンク先には、rel="nofollow"をつけるのが常識です。

その例

マナーのあるメールの書き方 | キャリワカ:コミュニケーション | nikkei BPnet 〈日経BPネット〉様。

サウスパーク:スコッティ・マクボーガボールのお話

The Tale of Scrotie McBoogerballs

今回の話は、解説の必要を感じたので、背景を説明しておく。

今回の話の根底にあるのは、The Catcher in the Rye(邦訳:ライ麦畑でつかまえて)という、有名な本である。おそらく、名前ぐらいは、誰でも聞いたことがあろうだろう。

「ライ麦畑でつかまえて」は、いわくつきの本である。というのも、この本に影響されて、殺人を犯したといわれている殺人事件が、複数あるからである。

1960年のこと、ある学校教師が、生徒に、この本を読ませたところ、生徒のひとりに、射殺された。

それだけではない。John Lennonを殺した、Mark David Chapmanや、Ronald Reaganを殺そうとした、John Hinckley, Jr.、はては、Rebecca Schaefferを殺したRobert John Bardoまでもが、この本に影響されたと、語られている。

そのような経緯によって、この、「ライ麦畑でつかまえて」という本は、アメリカの多くの図書館、学校で、禁書となっているのである。

今回のサウスパークでは、それを茶化している。つまり、本が、筆者の意図を離れて、拡大解釈されていくのである。心理学には詳しくないが、バーナム効果という概念も、あったりする。人は、曖昧で抽象的な言葉を、勝手に都合よく解釈してくれるのである。世の中に、詩人というものが流行るのは、このせいだろう。

しかし、真面目に考えれば、「ライ麦畑でつかまえて」という本が、殺人衝動を引き起こすはずがない。禁書というのは、えてして、このように馬鹿げたものになるのである。

実は、私は、「ライ麦畑でつかまえて」を読んだことがない。せっかくなので、時間があれば、原書を読んでみようかと思う。

キャッチャー・イン・ザ・ライ
ライ麦畑でつかまえて (白水Uブックス)
The Catcher in the Rye

2010-03-25

Photoshopの信じられない新機能

この動画は面白い。

ハァァァッ! マジで?

AdobeのCreative Suite 5は、これができるらしい。

GIMPのプラグインも、できるとか。

Photoshop's CAF (content-aware fill) - unbelievable? Not quite. - the real Uqbar

こういうアイディアもある。

どうも、この手のアルゴリズムは、結構研究されているらしい。私が知らなかっただけか。いや、それにしても十分に発達した科学は何とやらだ。

べつやくれいが真面目な絵を描いた!

@nifty:デイリーポータルZ:「花見過ぎ」をしよう

おお、べつやくれいが、真面目にデッサンした絵を、初めて見た。

Wikipediaが見れない

どうも、DNS関係だろうか。nslookupしても、ja.wikipedia.orgが解決できない。

P2Pと帯域とBitTorrent DNA

[お知らせ]4月1日よりBitTorrent DNAクライアントの利用を停止します。 zoomeインフォメーション - 動画共有サイトzoome

インターネットで、帯域というのは、頭の痛い問題である。近年、インターネットで動画を公開するのは、当たり前になっている。私は、音声や動画というものを、特別視してはいない。画像と同じくらい、自然に表示されるべきだと考えている。今日、誰も、Webサイトが画像を使っていると文句をいうものはいない。とすれば、動画だって、自然に使われてしかるべきだ。

しかし、現時点では、まだ、動画は、ディスク容量と帯域を、大幅に消費する。まだ、画像と同じぐらい、自然に使うことはできないのである。

日本は、世界でも有数の、bpsあたりの価格の安いネット回線が、提供されている国である。せっかくの広帯域を、使えぬとあっては、宝の持ち腐れである。

ここで、P2Pという仕組みが出てくる。エンドユーザー同士は、それなりの帯域を持っているのだから、それをお互いに使おうという考え方である。

zoome.jpは、動画をアップロード、公開できるサービスを提供しているWebサイトであるが、帯域を節約するため、Bittorrent DNAを用いていた。

BitTorrentは、数あるファイル共有用のP2Pプロトコルの中でも、一番問題のないプロトコルである。Winnyのプロトコルの何が問題かというと、自分の意図しないファイルを、送信可能にしてしまうことである。それは、Winnyのプロトコルの仕様である。ネットワーク上に、ひとりでもバカがいれば、全員とばっちりを食う、実によろしくないプロトコルになっている。

BitTorrentプロトコルには、そのような問題はない。それゆえ、Operaは、BitTorrentプロトコルをサポートしているし、一部のゲームは、BitTorrentプロトコルをつかって、アップデートパッチを配信している。多くのLinuxのディストリビューションのISOイメージは、BitTorrentで配布されている。

BitTorrentプロトコルは、結構、面白い仕組みになっている。ファイルというか、データというか、とにかく、ダウンロードする一塊のデータを、細かく区切る。そして、最も皆が持っていないピースを、優先的にダウンロードしようとする。

もちろん、実際の仕組みは、もっと複雑である。ここでは、BitTorrentは、単なるプログレッシブダウンロードではないということを、示したいのである。

ところで、BitTorrentは、別にトラフィックを有効的に使ったりはしていないのである。むしろ、その逆で、エンドユーザーがアップロードする分、全体的に見れば、トラフィックを余計に増やしているのである。

ところで、動画のストリーミング再生というのは、広帯域を必要とする。一サーバーとしては、負担を減らすために、BitTorrentの力を借りたいところである。ところが、動画のストリーミング再生というのは、プログレッシブダウンロードを必要とする。そうでなければ、ダウンロードしつつ再生ということができない。

BitTorrent DNAは、主に、こういったストリーミング用途に最適化したBitTorrentプロトコルの実装で、ブラウザのプラグインという形で、提供されている。

zoome.jpのBitTorrent DNAの使用は、なかなか興味深かったが、結局、廃止されたようだ。理由は、実装が不安定ということらしい。

帯域の問題は難しい。マイナーなWebサイトである、zoomeだからこそ、BitTorrent DNAを使用できるのである。もし、ニコニコ動画が、BitTorrent DNAを利用しようとすれば、日本のインターネットは、崩壊する。

これはどういう事かというと、ニコニコ動画の帯域使用量は、もはや、いくら金を積んでも、増やせないレベルになっている。いまは、ISPと相談して、今月は、このくらい帯域を使おうなどと取り決めているらしい。ニコニコ動画が、無分別に帯域を使い出すと、日本のインターネットが崩壊する。

したがって、ニコニコ動画が、無駄にトラフィックを増やす、BitTorrentプロトコルを使えるわけがないのである。

これを解決するにはどうすればいいのか。思うに、マルチキャストができればいいのではないかと思う。今は、サーバーは、データを要求するホストひとつひとつに、それぞれデータを送信しているわけだ。マルチキャストがあれば、サーバーが送信するデータは、ホストひとつ分でいい。ISPが、必要なホスト全部に、あたかも、サーバーが全員に送信したかのように、送信してくれる。

これは、実に理想的だ。マルチキャストさえあれば、トラフィックは減らせる。問題は、マルチキャストには、ISP側の協力が必要だ。全体的にトラフィックが減るとしても、ISPの負担は増える。どのISPも、そんな余計な負担をしたがらない。結果として、マルチキャストはサポートされず、我々は未だに、個別にユニキャストしているのである。

私は、マルチキャストがないからこそ、BitTorrentのようなプロトコルが流行っていると思うのだが、なかなか、うまくいかないものだ。

追記:あるいは、現在、数MBの画像ファイルを使うのが、全く問題なくなったように、将来的には、数百MBから数GBの、動画ファイルを使うのも、問題なくなるのかもしれない。

しかし、我々は、常に、「今使える技術」を欲しているのである。「来年使える技術」は、意味がない。今使えないのだから。

自主規制の不思議さ

アメリカで、Public Optionの法案が通った際、Joe Bidenという議員が、"This is a big f---ing deal!"と、ささやいたらしい。アメリカのテレビは、この失言に対して、BEEP音をかぶせて、自主規制した。議員が失言したことは伝えるのに、なぜ、肝心の言葉を、自主規制するひつようがあるのだろうか。

Fで始まるこの言葉は、単なる発音に過ぎない。日本では、単なる発音にBEEP音をかぶせて隠すということは、聞いたことがない。唯一聞いたことがあるのは、「さあ、CMの後で、後驚きのXXXが! チャンネルはそのまま」といった、演出でしか、BEEP音を聞いたことがない。

たとえば、国家機密の情報を報道統制するとか、そういう類ではなくて、このような、特定の単語を消すのは、どうも、日本人としては、理解できない。

もちろん、日本でも、テレビで使えない言葉というのはある。私が思うに、その多くは、別に使っても問題ない言葉であると思う。「かたわ」というのと、「身体障害者」というのと、「フィジカリー・チャレンジド(神から肉体的に試練を与えられた)」というのに、何の違いがあるというのか。最近では、障害者や便所という言葉すら、差別用語だと言われる始末である。これらは、法律にも使われている言葉だというのに、何が問題なのだろうか。

これによってこれを思うに、使い慣れた言葉は、差別であると感じるのであろう。つまり、「お前」とか、「貴様」というのが、本来は尊敬の意味を含む代名詞であったのに、あまりに頻繁に使われた結果、尊敬の意味がうすれてきて、「あなた」という、本来、人称代名詞ではない言葉を使うようになったのも、そのためであろう。

とするならば、今尊敬の意味を込めて使われる言葉も、後の世には、侮蔑の言葉と成り下がる恐れがある。我々は、一刻も早く、新たな代名詞を、どこかから借りてきて、人称代名詞にしなくてはならぬ。YOU早く新しいWORD見つけちゃいなYO。

それはさておき。

このニュースを聞いたものは、誰でも、Fから始まるこの言葉が何であるのか、すぐに分かるはずである。では、なぜ隠す必要があるのか。

日本のテレビでは、たとえ政治家が放送禁止用語を漏らしたとしても、それを報道する際に、このように露骨にBEEP音をかぶせてまで、消そうとはしないだろう。

例のごとく、この疑問を、IRCでアメリカ人にぶつけてみたところ、彼らは、次のように聞き返してきた。

我々は皆、チンポがどういう形をしているか知っている。なぜ日本は、自主規制するのだね。我々は特定の単語の音を自主規制し、片や日本は、チンポを自主規制する。同じではないのかね。

確かに、なぜ、日本では、局部にモザイクをかけなければならないのか、私には分からない。何となれば、我々が皆、必ず持っているモノではないか。

しかし、もはや、日本の自主規制は、意味が無くなっていると、私は思う。今や、日本のポルノ制作会社は、海外にダミー企業を設立し、サーバーも海外に設置して、グレーだが、日本に無修正のポルノを提供しているのである。こうなってしまっては、もはや、国内の法律は、あまり役に立たない。確かに、実質は日本人によって行われているので、国内では、摘発される恐れがある。しかし、これを摘発するのは、他国の警察や司法と、連携する必要がある。とても面倒なので、児童ポルノなどの、他国も同意してくれる、よほどの理由がなければ、現実的に、摘発できないのである。

今や、我々は、インターネットのおかげで、自国の自主規制から、逃れることができたのである。Thanks Internet!

ところで、ひとつ思うことがある。このような自主規制を強いるのは、制約である。我々は、このような制約から、出来る限り、解放されるべきである。しかし、思うに、この日本の、局部にモザイクをかけなければならないという制約、果たして、悪ばかりだと言えるだろうか。

実は、日本のポルノは、そのあまりにも馬鹿げた企画力により、海外から、高い評価を受けている。具体的なリンクを貼るのは、差し障りがあるので避けるが、我が日本国には、実に馬鹿げたポルノが、大量に出回っている。思うに、モザイクを掛けなければならないという制約が、このような、変な方向性を生み出したのではなかろうか。

エロゲもそうだ。エロゲは、単なる絵に過ぎない。絵であるのに、何で局部にモザイクが必要なのだろうか。表現の自由に対する、憂うべき制約である。しかし、仮に今、エロゲのモザイクがなくなったところで、より良いエロゲが生まれるとも思わない。

たとえば、かつて、学帽というものがあった。日本の学生は、皆、この安っぽいダサい帽子をかぶって、学校に通っていたのである。この、決まりきったダサい帽子をかぶらなければならないというのは、制約である。では、現実は、どうなっただろうか。

当然、日本の学生は、皆、この学帽という制約が気に入らなかった。それゆえ、皆、この学帽の改造に苦心したのである。

これは、現代の学校の制服にも、言えることである。日本の制服は、大して質も良くないのに、ボッタクリ価格である。よほど大きな利権があるのであろう。もし、日本の教師たちが、真に学生の服装の乱れを正したいとするならば、直ちに制服を廃止するべきである。馬鹿げた制約がなくなれば、馬鹿げた改造もなくなるというものだ。

この制約というものは、単に規制に限らない。たとえば、音楽は、近年、DTM機材の性能向上に伴ない、はるかに制約がなくなった。もはや我々は、鍵盤のような物理的な装置に頼って、音楽を演奏する必要はないのである。ゲームコンソールでも、ファミコンやスーファミのような、FM音源から、今や、PCM音源である。もはや、FM音源のような制約は、存在しないのである。歌もそうだ。最近は、音程をリアルタイムで自動的に調整する機械まであると聞く。

では、音楽は、昔に比べて、はるかに優れたものになったかというと、どうも、そうは思わない。

インターネット自体もそうだ。今や、ネコも杓子もブロードバンドである。何百MBものファイルサイズの動画をアップロードして、わずか数分で全世界に公開するのは、至極当然である。では、インターネットは、10年前と比べて、はるかに優れたものになっただろうか。

この、制約の中で生まれる芸術というのは、実に興味深い。誰か、詳しく研究していないものだろうか。

2010-03-24

奇妙な夢を見た

我々は、ある会議室で、C++について論じていた。とうとう、FDISが出たのである。ようやく制定された規格書は、何故か、複雑な状態遷移図のようなものが、びっしりと書き込まれていた。これを読みとくのは骨が折れる。

議論の後、我々は、呑みに行くことになった。私は、何か他の用事で、一体部屋を出た。用事を済ませて、部屋に戻ってくると、そこは、すでに会議室ではなかった。

部屋の中には、何故かフル武装した自衛隊員がいて、猛烈に訓練をしていた。これは一体どういう事か。さっきまで議論していた人たちは、どこへ行ったのか。

私は、部屋を間違えたのかもしれぬと考え、隣の部屋を覗いてみた。そこでも、やはり、よく鍛えられた自衛隊員が、訓練をしていた。どういうことだろう。

まあいい、とりあえず、駅に行けば、なんとかなるだろう。どうせ、彼らも駅前にいるに違いないと考えた。駅名は、何故か、ロシア駅であった。私は、ロシア駅という名前については、何の疑問も生じなかった。

さて、「ロシア駅」に着いたが、彼らは見つからなかった。私は、携帯電話を全く使わない主義なので、携帯のアドレス帳に、彼らの電番号やメールアドレスは、入っていない。途方にくれていると、ふと、ある地べたに座っている集団が目についた。見覚えのある顔だ。何と、彼らは、私の小学生時代の級友であった。

級友等とは、小学校以来、全く会っていないはずである。しかし、その顔は、見覚えのある顔であった。なぜここに座っているのだろう。我々は、しばらくの間、久闊を叙した。

さて、再び、駅前をうろついていると、とうとう、仲間と再開した。彼らは五、六人ぐらいいて、その中に、イケメンのアキラさんと、マッチョなメルポンさんもいた。

私が、「呑みに行く店は、もう決まっているのか」と訊ねても、彼らは、「決まってる、決まってる」というだけで、なんという店かは、答えてくれなかった。

我々は、ある建物の階段を上がっていった。その階段は、やたらにせまく、人がひとり通るだけで精一杯であった。しかも、なぜか、途中で何回も、左右に分岐していた。

私は、前の人を見失わないようについていった。階段は、分岐するたびに、左右の壁が、狭くなっていった。もはや、体をヨコにしなければ、通ることすらできない。果たして、マッチョなメルポンさんは、通り抜けることができるのだろうかと、心配した。

階段の左右の壁は、いよいよ狭くなってくる。もはや、肋骨がつかえて、進むことができぬ。いよいよ進めないと諦めかけたときに、ようやく、目的の店についた。

その店は、こぢんまりとした小さな部屋であった。床の間に、座布団を引いて、ひとりの婆が正座していた。

「いらっしゃい」

(いや、「いらっしゃい」どころではないだろう。何なのだこの階段の作りは)と思いながら、部屋を見回すと、こたつがひとつ、備え付けられていた。イケメンのアキラさんは、涼しげな顔をして、すでにこたつに入っていた。

私も、こたつに腰をおろした。狭い階段をくぐり抜けてきたせいか、やたらと暑い。私は、外套を脱ぎ、トレーナーを脱ぎ、さらに、セーターを脱いだ。こんなに狭い通路を通るのだと知っていれば、こんなに厚着してこなかったものを、と不満に思った。

マッチョなメルポンさんは、いつまでたっても、上がってこなかった。

みると、先程の、床の間の婆は、いつのまにか姿を消していた。こたつの上には、いつの間にか、土鍋と食材が置かれている。と思うと、いつの間にか、こたつに、婆と爺が座って、世間話をしていた。

爺「やれやれ、最近は、こんな変わった店じゃないと、客も来やしない」
婆「いや、これでもさっぱりだよ。やっぱりあれだね。儲けようと思ったら、こんな商売じゃなくて、楽器の教室の先生をするに限るね」
爺「どんな楽器だい」
婆「シンバルだよ」

果たして、シンバルの演奏法を専門に教える教室の需要はあるのだろうか。

と、ここで目が覚めた。

私は、トレーナーとジーンズを着込んだまま、布団にくるまって、壁際で寝ていた。枕元には、D&Eと、C++ Templatesと、柳田国男全集が、読みかけで開いたまま、置いてある。変な夢の原因は、これらだろう。

あれだけ長い夢を見たと思ったのに、時間は、22時である。なんと、たったの数時間しか、うたた寝していなかったと言うのか。一炊の夢とは、よく言ったものだ。

これ、本当なんだろうか

"Weird: The Al Yankovic Story" from Eric Appel, Aaron Paul, Olivia Wilde, Al Yankovic, Patton Oswalt, Paul Scheer, BRIAN HUSKEY, and christiansprenger - Video

パロディ歌手のパロディ映画か?

Weird Al Yankovicは、最高の歌手だ。

2010-03-23

東京都は『古事記』を有害図書に指定しよう!

東京都は『源氏物語』を有害図書に指定しよう!:日経ビジネスオンライン

有害図書である。なるほど、うまく考えたものである。かつて、我が日本国政府は、ヰタ・セクスアリスや、チャタレイ夫人の恋人を、発禁処分にしたところ、大きな批判を受けた。表現の自由、言論の自由に対する、大いなる違反であるとの批判である。

発禁処分はまずい。なにより、名前がよろしくない。では、有害図書という名前にしよう。これは一見、ゾーニングに見えるが、その実、現実的に、表だった流通には載せられないようにすることである。本当に、よく考えたものである。そのド低脳クサレ脳みそで、よくぞ思いついた。

よく、源氏物語は、ローティーンの紫の上を誘拐、監禁し、自分好みに調教した物語を含むので、まさしく有害図書であるという批判を耳にする。しかし、源氏物語の如きは、古事記に比べれば、全然、有害でもなんでもないのである。

イザナキ君とイザナミちゃんによる、国生みの次第は、非常にわいせつである。

まず、彼らは、オノゴロと呼ばれている島に、神の眷属である利権を利用して、天下るのである。私はデタラメを言っているのではない。ちゃんと、原文に書いてある。

其嶋天降坐而見立天之御柱見立八尋殿

しかも、天下るどころではない。天の御柱や、八尋殿といった、ハコモノを建造するのである。しかもこのハコモノは、自分たちだけで使うために、立てたのである。まったくもって、税金の無駄遣いである。

そして、その八尋殿という名前が示すように、広大な屋敷に入って、まず行ったことは、極めて猥雑なる行為である。

イザナキ「お前の体はどうなっているのだ」
イザナミ「穴がひとつあいている」
イザナキ「俺の体は、ひとつ余計なモノがついている。こいつをどう思う?」
イザナミ「すごく・・・大きいです・・・」
イザナキ「大きいのはいいからさ。こいつをお前の穴に差し入れて、やらないか?」
イザナミ「アーッ!」

このような次第を経て、我が日本国は生まれたのである。

これだけではない。古事記では、この後も、延々とヤリまくる記述が続く。ついには、ヤリ過ぎて、イザナミは死んでしまう。

イザナミ亡き後、イザナキはどうしたか。型の如く喪に服したか。否、彼は、宗教でいうところの、いわゆる黄泉国に行って、イザナミを生き返らせようと試みるのである。

これは、青少年の健全な育成に対して、非常なる害悪である。このような記述は、「人が死んでも、黄泉国に行けば、また会えるから問題ない」という思想を生む恐れがある。このような軽率な物語があるからこそ、命の大切さが分からない若者を増やすのである。

さて、イザナキは、黄泉国にいるイザナミに会いに行く。イザナキが黄泉国を訪問したとき、イザナミはちょうど、触手プレイと獣姦に勤しんでいたが、その現場を見られたために、イザナキを殺そうとする。イザナキは、ほうほうの体で、逃げ出す。なんとかおってから逃れられるが、その時にかわした会話は、残酷極まりないものである。

イザナミ「むしゃくしゃするから、これからは、一日に千人ぐらい、無差別に殺す」
イザナキ「じゃあ俺は一日に千五百人、妊娠させるから無問題」

これを読んでなお、命の尊厳を知る若者があるだろうか。

その他にも、アマテラスとスサノヲの近親相姦や、スサノヲが巫女のマンコを串刺しにして殺す話、アマテラスのヒキコモリ、アマテラスを部屋から出すために、売笑婦を雇って、裸踊りをさせたのだのと、猥雑かつ非倫理的な話は続くのである。

それが終われば、今度は、恐れ多くも、御門の祖先のお話になる。ここで、帝は、もったいなくも御顔にタトゥーを彫り、毎日のように、女をナンパ遊ばされるのである。女は、いずれも、掛けまくも忝なく、龍顔に咫尺して、甚だしきは、「もっと寝ろ」という意味の露骨な詩を歌うものまで現れる始末。

一体我々は、古事記のような有害図書を、野放しにしてよいものか。

ある者は言う、「古事記は難しいから、青少年は読まないだろう」と。これは、青少年の読解力を、過小評価しすぎである。

なぜならば、この私は、小学生の時に、古事記を読破していた。しかも、相当エロい話であると、当時から思っていたのである。私が、小学生の時に読んだ、他の小説、たとえば、足の爪を剥がしたことを利用して、女医の乳房を盗み見る、「赤頭巾ちゃん気をつけて」だとか、双子と3Pする、「1973年のピンボール」だとか、あるいは、ド田舎に隔離された挙句、砂まみれになって女と交わる、「砂の女」だとか、猫の鳴きまねをするよう調教された未成年と乳繰り合う、「密会」と比較しても、古事記の方が、断然エロかった。

自白するが、私はこれらの小説を、小学生の時に、すでに読んでいた。つまり、これらの本は、実際に、小学生が目にする恐れのある本である。

ところで、世の中には、障子を勃起した陰茎で破る、「太陽の季節」とかいう小説があるそうだが、これは、特に、有害図書にして、規制する必要はないと思う。というのも、私は小学生当時、そんな本の存在は知らなかった。たしか、太陽族という言葉は、物の本で読んだ覚えがあるが、すぐに消えた数あるバカバカしい流行のひとつに過ぎない。一方、私が小学生の頃に読んだ、上記の小説は、現在でも有名で、全国、どの書店でも売っているであろう、上記の小説に比べれば、「太陽の季節」なんて、どこで売っているのかすら分からないマイナーな本なので、あえて規制する必要もないだろう。事実、私はいまだに、「太陽の季節」は読んだことがない。

追記:小一時間ほどググッた結果、ようやくアマゾンで、「太陽の季節」の、中古品を見つけることができた。値段は、1円である。1円ぐらいの価値はあるらしい。1955年当時の1円だろうか。

太陽の季節 (新潮文庫)

古事記 (岩波文庫)
赤頭巾ちゃん気をつけて (中公文庫)
砂の女 (新潮文庫)
密会 (新潮文庫)