Monty Pythonの元メンバー、Chapmanの映画を作るために再結成

BBC News - Monty Python members reunite for Graham Chapman film

そうめんと豆腐

この数日、そうめんと豆腐とネギで生きている。あまりにも暑くて食欲がわかないのだ。腹は減っているのに物が食べられない。

multiple_lock_guardとか欲しいよね

複数のmutexに対するlock_guardが欲しいと思ったので書いてみた。動くかどうかテストしていない。

template < int I >
struct unlock
{
    template < typename T >
    void apply( T & t )
    {
        unlock< I - 1 >::apply( t ) ;
        std::get<I>(t)->unlock() ;
    }
} ;

template <>
struct unlock<0>
{
    template < typename T >
    void apply( T & t )
    {
        std::get<0>(t)->unlock() ;
    }    
} ;

template < typename ... Types >
class multiple_lock_guard
{
public :
    typedef std::tuple< Types *... > type ;
    
    multiple_lock_guard( Types & ... args )
        : m( &args... )
    {
        std::lock( args... ) ;
    }

    ~multiple_lock_guard()
    {
        unlock< sizeof...(Types) - 1 >::apply( m ) ;
    }

    multiple_lock_guard( multiple_lock_guard const & ) = delete ;
    multiple_lock_guard & operator = ( multiple_lock_guard const & ) = delete ;

private :
    type m ;
} ;

こういうふうに使う。

std::mutex m1, m2, m3 ;

int main()
{
    multiple_lock_guard< std::mutex, std::mutex, std::mutex >
        guard( m1, m2, m3 ) ;
} 

追記、コピーコンストラクタ―と代入演算子のdeleteを忘れていた。

C++0xのマルチスレッドとデータ競合が非常に難しい

「バリアー！」
「デュクシ！」
「ちょっ、お前、オレ、バリアー張ってんだから攻撃するなよなー」
「うるせー、オレのはバリアー貫通できる攻撃だっつーの」
「貫通できないバリアー！」
「貫通できないバリアーを貫通できる攻撃！」
「絶対貫通できないバリアー！」
「絶対貫通できる攻撃！」
「そんな攻撃ねーよ」
「そんなバリアーこそねーよ」
「お前、矛盾って言葉、知ってるか？」
「ああ、昔の中国人はオレの矛を持ってなかったんだな」
「ちげーし。オレのバリアーを持ってなかったんだぜ」
「真似すんなよ」
「マネスンナヨー」
「あ、きったね」
「ア、キッタネ」
「飽きたね・・・」
「そうだね・・・」

フェンスといい、メモリバリアーともいう。名前はかっこいいが、やっていることは、あるスレッドにおけるあるメモリ場所に対する変更操作を、他のスレッドから見えるようにしたり、あるいは逆に、他のスレッドでの変更操作を、このスレッドから見えるようにすることである。

これは、多くのコンパイラーで、独自にサポートされている。基本的にWindowsでプログラミングを学んできた私としては、メモリバリアーという名称の方がしっくりくるのだが、C++の規格としては、フェンスという名称になっている。

C++0xの規格を眺めていたところ、どうもC++0x規格には、非アトミック操作に対するフェンスというものが、存在しないようである。

しかし、mutexはどうなるのだろう。例えば、以下のコードが、意図通りに動くことが、規格でどのように保証されているのだろうか。

std::mutex m ;
int x ; 

void thread()
{
    std::lock_guard<std::mutex> guard(m) ;
    ++x ; // 非アトミック操作
}

int main()
{
    x = 0 ; // 初期値0

    std::thread A( thread ) ;
    std::thread B( thread ) ;

    A.join() ; B.join() ;

    std::cout << x << std::endl ; // 2であるべき
}

色々と考えたあげく、以下のように考えた。

AとBのインクリメントは、1.10 [intro.multithread] p4に書かれているように、conflictする。
AとBで行われる非アトミック操作であるインクリメントは、mutexで囲まれており、同時には起こらないし、どちらかが先に起こることは確実である。とすれば、1.10 [intro.multithread] p13に書かれている通り、先に起こった方の操作は、後続の操作に対して、visible side effectである。
AとBのインクリメントはconflictするものの、どちらかが先に起こることが保証できるため、1.10 [intro.multithread] p21のdata raceの条件には引っかからない。

LISTER: Hey, it hasn't happened, has it? It has "will have going to have happened" happened, but it hasn't actually "happened" happened yet, actually.
RIMMER: Poppycock! It will be happened; it shall be going to be happening; it will be was an event that could will have been taken place in the future. Simple as that. Your bucket's been kicked, baby.

YouTube - Red Dwarf I - Future Echoes - Part 3 of 3

復活

体調が戻ってきた。まだ少々下痢気味だが、とりあえず起きていても体が極端に疲れたりはしない。

風邪をひいたらしい

どうも体が疲れる。熱がある気がする。恐らく、明日あたり、本格的に体調を崩してしまうはずだ。

どうも昔から、季節の変わり目には、風邪をひきやすい。いつもきまって、何の予兆もなく、いきなり疲労感を感じ、数時間後に熱。仕方が無いのでそのまま寝るも、翌朝、さらに体調が悪くなっているのだ。

明日はさぞ、薄いおかゆが美味しく感じられることだろう。思うに、一番うまい食べ物は、風邪を引いた時に食べる薄い粥であると思う。

LinuxのARMサポートがカオス

Linux ARM support: A hot mess, an ugly clean-up | ITworld

LinuxのARMコードは、各メーカーが、手っ取り早く安く上げるために、やっつけ仕事で場当たり的に対応させるため、悲惨なことになっているとのこと。Linusが最近、ようやく様子をみて、「こんな調子だったら、もうこれ以上pullしねーよ」と突っぱねた。

まるで日本の携帯業界のようだ。

偽音5つ

Humans Invent | Innovation, Craftsmanship & Design

車のドアを閉めた時に発生するバタンとかガチャンという音、電気自動車の走行音、スタジアムの歓声、Skypeのボイスチャットで、無音時のかすかなノイズ、ATMがお札を出すときの音。これらは皆、偽音である。

ユーザーが車のドアを閉めた時、期待するような音がならないと、本当に閉まったのかどうか疑念が生ずる。そのため、車メーカー各社は、ドアがありそうな音を発するように、精密な設計をしている。ドアが閉まった時の音を鳴らす機構の特許も多数あるそうだ。

電気自動車は静かすぎるので逆に危険であるという観点から、それらしい走行音を発するよう義務付ける法整備が進められている。

スタジアムの歓声というのは、もちろん実際の歓声も含まれているが、実はスピーカーから流しているらしい。スピーカーから流すことによって、実際の見物客にも、歓声を出しやすくしているのだとか。

スカイプなどのボイスチャットでは、ノイズリダクションの技術を活用しているが、この技術は優れすぎていて、何も喋らない時は、完全に無音になってしまう。すると、ユーザーは、実は切断してしまったのではないかと疑念を抱く。そこで、まだつながっていることを示すために、かすかなノイズを流している。

最後は色々と議論があるようだが、ATMがお札を出すときの音は、実は偽物であるらしい。技術的に、ATMは紙幣を一瞬で出すことができるが、あたかも中でお札を動かしているような偽音をだすことによって、ユーザーをして、ATMがちゃんと仕事をしているのだという錯覚を生ぜしめるのだとか。

ナナオが4Kディスプレイを発売するそうだ

DuraVision FDH3601 | EIZO 株式会社ナナオ

大きさは36.4型で、解像度は4096x2160。画素サイズから計算すると、PPIは127、dpcmなら50ぐらいだと思われる。ちなみに肝心のお値段は288万円。とてもではないが手が出せる値段ではない。

ナナオはあの悪名高いS2411Wの定点ドット欠けを仕様だと言いはった企業だから、もう全く信用していないが、4Kパネルの製品が出てきたのは興味深い。しかし、4kとなると、120PPI程度ではもうディスプレイが巨大すぎて、一般用途にはつらい。

生きているうちに、24インチで600PPI程度のディスプレイが安く手に入るようになるといいのだが。

C++0x仕様のfriend

C++0xでは、friendに細かい変更があった。gcc 4.7では、このC++0x仕様のfriendに対応したらしい。早速確かめてみたところ、仕様通りだった。

typename-specifierが使えるようになったり、名前探索のチェックの省略のルールが変わったりしている。

詳しくは、n1791を参照。

最近の漫画

久々に、いくつかの漫画を読んでみたので、その感想を書く。

「角刈りすずめ」の連載が終わってしまったようだ。角刈りすずめとは、近代麻雀で連載されていた漫画である。毎回毎回、麻雀に死地を求める孤独な角刈り男が、期せずしてエクストリームな麻雀に出くわしてしまうギャグマンガである。

しかし、麻雀漫画がこれほど多いのは解せない。「ムダヅモ無き改革」だとか、「咲-Saki-」だとか、はては、「ひぐらしのなく頃に」から派生した、「ひぐらしの哭く頃に 雀」まである。麻雀を題材にしたギャグマンガはいくつかあれど、麻雀漫画のほとんどは、かなり真面目に麻雀を打っている作品である。登場人物が全員、テレパシーを疑うほどの通しと待ち読み能力を持っているということを除けば、至って普通のシリアスな話である。

麻雀専門の漫画雑誌があり、単行本も出版されている以上、麻雀漫画には一定の需要があるのだろう。

麻雀を考えるに、技能と運とイカサマとハッタリがモノを言うゲームである。登場人物が試行錯誤する心理描写を延々と続けていても構わないし、ド素人が名人に天和で勝ちましたという話も、ありうる話である。とすれば、お話の題材としては、悪くないのかもしれない。

しかし、最近の若者は、麻雀のルールなど知らない。実際、私も麻雀のルールは覚えられなかった。

さて、麻雀以外の漫画では、魔法陣グルグルを読んだ。この漫画は、理不尽なRPGをネタにした漫画である。連載当時はバラバラに読んでいて、通して読んだことはなかった。それも、終わりの方は全く読んでいなかった。果たして、今読んでも楽しめるものだろうかと疑問だったが、これがどうして、実に面白い。

グルグルは、キタキタおやじとかギップルを登場させたのが優れていると思う。これによって、話がシリアスにならないし、またクサくもならない。

ついでに、ドラクエ4コママンガ劇場が懐かしくなり、ブックオフで探してみたが、一冊もなかった。残念。あの伝説の、「ふんどし　お前が一番混乱しとるわ」を読みたかったのに。

古本屋の未来

C++の参考書を延々と執筆していて、ここのところ、古本屋巡回もしていなかった。ふと、一年ぶりに古本屋でもめぐろうと思い立ったので、今日は久しぶりに古本屋に行ってみた。

が、またひとつ、古本屋が潰れていた。早いもので、京都に来てからもう7年になるが、知っている古本屋が、すでに二軒も潰れている。もう、ブックオフ以外の古本屋に未来はないのだろうか。

それはともかく、8月11日から、下鴨納涼古本まつりがある。古事談や古今著聞集などが安く売っていたら購入を考えよう。

CPUの未来

ここ数カ月のBulldozer関連のニュースを読んでいて、やはり将来的に、CPUとGPUは、物理的にひとつのチップ上に実装されるのが当然になるのだろうと考えた。PC用のビデオカードというものは、今のサウンドカード程度の位置にまで落ちるだろう。つまり、確かに、組み込みのものと比べて高品質な部分もあるが、大多数のユーザーは、違いを気にしないのだ。

また、私はかつてから、GPUの使うメモリーは、CPUの使うメモリーと統一されるべきであると考えていた。そこまでいかなくても、GPU側から通常のメモリーにアクセスでき、また、仮想メモリという形で双方から同様にアクセスできるのであれば、それで十分なのかもしれない。

いずれにしても、C++の未来は明るい。

【後藤弘茂のWeekly海外ニュース】 AMDが革新的な次世代GPUアーキテクチャの概要を発表
【後藤弘茂のWeekly海外ニュース】 GPUをCPUのように扱えるFusion System ArchitectureをAMDが発表
Introducing C++ Accelerated Massive Parallelism (C++ AMP) - Visual C++ Team Blog - Site Home - MSDN Blogs

John Carmack、E3で語る

E3 2011: John Carmack talks Wii U, PlayStation Vita, and next-gen Rage - News

• Rageは正直いって開発期間が長すぎた。
• 一年前に発売日を発表したのは、納期を明確にして追い込むため。
• コンソールは十分にパワフルなので、特に制限を感じなかった。
• むしろPCは、コンソールよりはるかにスペックが高いにもかかわらず、60FPSを保証するのが難しかった。色々とオーバーヘッドが高い。IntelやnVidiaに相談したけど、フラストレーションたまるわ
• Wii Uは、ハード性能が他のプラットフォームに追いついてきたので、まあ、よさそうだね。
• Vitaはダメだろ。現時点ではスペック高いかもしれんが、発売される頃には、ひょっとしたらスマートフォンとかタブレットとかにスペックが抜かれてるかもしれんし、発売後一年や二年もたてば、やはり見劣りしてしまう。よほど移植を簡単にできるようにしないと、成功しないだろうね。

The Old New Thing: PEリソースは4バイトアラインにせよ。まあ、守らない奴もいるけど

PE resources must be 4-byte aligned, but that doesn't stop people from trying other alignments - The Old New Thing - Site Home - MSDN Blogs

PEヘッダー内のリソースは4の倍数のオフセットに格納されていなければならない。これは、アライメントに厳しい環境のためである。

まあ、どうせ守らない奴は守らないのだがね。第一、気を付けていれば、一応は動くしね。つまり、まあそりゃ、誰かx86じゃないWindows使ってる奴がリソース読み込んだら、クラッシュするだろうよ。でも、x86じゃないWindowsなんて誰が使ってんのさ？　だろ？

Windows Vista SP1では、セキュリティ上の理由のため、リソースをパースするコードに、いくつかのチェックが加えられた。ここで重要なのは、リソースにアクセスする前に、正しくアラインされているかどうかを確かめるようになったのだ。これにより、アラインの正しくないリソースを読み込んだ場合のクラッシュを防げるようになった。プログラムが任意のバージョン情報のリソースを読み込むというのは、よくあることだ。例えば、エクスプローラーはファイルプロパティを見るときや、バージョン情報のコラムを有効にした時に、バージョン情報を読み込む。したがって、正しいリソースのアライメントを保証することは、リモートDoSアタックを防ぐことになるのだ。

そしたら、バグリポートがやってきた。「プログラムXYZがインストールできなくなった」。何故ならば、そのプログラムは自分自身のバージョン情報のリソースを読み込もうとして、失敗しているからだ。その理由は、プログラムをビルドするのに使ったツールが、4の倍数ではないオフセットにリソースを配置しているからである。「おいおい、マジかよ。よしてくれよ。そんな事すりゃ、3バイト無駄になっちまうだろうがよ。以前は、リソースアライメントしなくても動いたじゃん。だからそのまま出荷したんだよ」

別の例としては、あるゲームの追加パックがインストールできなくなった。何故ならば、ゲームのバージョン情報リソースを読み込むコードが動かなくなったからだ。

いくつかのプログラムが、「アプリ名は有効なWin32アプリケーションではありません」というエラーメッセージを表示して、実行をやめるようになった。これは、初期化の途中で、自分自身のバージョン情報リソースを読み込もうとして、ERROR_BAD_EXE_FORMATで失敗しているからだ。このエラーに対応するエラーメッセージをユーザーに表示しているのである。

修正としては、アライメントのチェックを以前と同じように緩くした。厳しいチェックは、アライメント要求が厳しいアーキテクチャのみで行うようにしたのだ。これは、あるマシンではリソースが読み込めるが、他のマシンでは読み込めないというプログラムの存在を許してしまう。しかし、アライメントが正しくないデータでも問題なく読み込めるという前提で書かれたプログラムをぶち壊すよりマシだ。

珍走団と遭遇

先日、絶滅危惧種の珍走団と遭遇したので、そのことでも書こうと思う。

あの日、私は予備自衛官の射撃訓練を終えて、射場から駐屯地へ帰る途中であった。我々は、迷彩服を着用し、あの数ある自衛隊車両のうちでも有名な、三トン半のトラックの荷台の簡易なベンチに座って、ガタガタと揺られながら、道路を走っていた。

その時突然、特徴的な騒音が聞こえてきた。荷台の後ろから外を見やると、5,6台ぐらいのバイクの集団がいた。そのバイクは非常に特徴的で、エアロダイナミクスのよく効きそうな外装、無駄にでかい背もたれのようなもの、非常に変わった形のくねくねと曲がったマフラーなどを装着していた。

人も変わっていて、サングラスやマスクなどを着用していた。しかし、どう見ても年齢が若くない。中には、少なくとも四十代ではないかと思われるような人物もいた。皆、小刻みに右手を動かし、一定のリズムで騒音を発生させるという、非常に燃費によろしくない運転をしていた。

もうこんな人間は絶滅したかと思っていた。彼らは40年前からタイムスリップしてきたのだろうか。

我々は言葉を失いつつ珍走団を眺めた。珍走団の方も、我々を凝視しながら、トラックの両脇をすり抜けていった。確かに、我々は迷彩服を着用して、自衛隊車両の荷台に乗っているのだ。まあ、人目をひく姿ではある。

珍走団が過ぎ去った後で、ある曰く、「アイツら、ワシらのこと珍しそうにガン見しとったけどな。ハッキリいって、お前らの方がよっぽど珍しいやろ」

真理である。

なお、一部ノーヘルがいたものの、信号はちゃんと守っているようであった。

帰還

予備自の訓練から帰還した。

今回は、初めてⅠ型のレーションを食べた。缶に入っているものだ。感想としては、あまり食べたくない代物である。聞けば、東北に派遣されている自衛官も、当初は自衛官まで普通の食事が回らず、この缶飯ばかり食べていたらしい。ただ、数カ月そのままの体制を続けていたら、口内炎になったので、急遽、自衛官の分まで食事が回る体制を整えたらしい。我が国の、兵站をおろそかにするところは、いつまでたっても変わらないのだな。

聞説、自衛隊の災害派遣が報道されたことにより、この缶飯の知名度が上がっているそうだ。ただ、缶の見た目はともかく、中身はあまりよろしくない。

ちなみに、Ⅱ型の方は、まだ多少はおいしい。食べたければ、業務用スーパーで、もち米を使った味付け飯のレトルト品でも探すといいだろう。中身は同じだ。ただパッケージがOD色になっているだけである。

もちろん、普通に炊いた飯のほうが美味いのは、言うまでもない。

留守

5日間留守にします。

Bulldozerの情報

【後藤弘茂のWeekly海外ニュース】 AMDがBulldozerベースの次期メインストリームCPU「Trinity」を公開

Trinityでは、Bulldozerのモジュールを2個、4CPUコアに相当するコアを搭載していると見られる。それにRadeon HD 6970(Cayman)世代のGPUコアを統合したものがTrinityだと推定される。

本当に2012年にリリースされるTrinityの内蔵GPUは、Radeon HD 6970相当のパフォーマンスを持つのだろうか。そうなったら、もうGPUはvideophile（画質ヲタ）とでもなづくべき一部のヲタしか使わないマニア向けの商品に成り下がるだろう。そのような世界では、画質を上げると称して、様々な怪しげな商品が蔓延することだろう。例えば、画質を上げるDisplayPortケーブルだとか。

まあ、それは冗談にしても、GPU統合APUとビデオカードとの違いが、アンチエイリアスやテクスチャーフィルタリングの質程度のものであれば、PC用のビデオカードというものは斜陽になっていくだろう。

深刻な誤表記

ふと、本の虫: C++0xの新機能、finalとoverrideを読み返してみたところ、深刻な誤表記が多数存在することを発見した。

派生というべきところで継承といっていたり、オーバーライドというべきところをオーバーロードといっていたり、その他色々と誤変換も多い。困ったものだ。今書いている本にも、どれほど誤表記が混じっているものやら。

gccのiostreamのクラッシュ

ここ数年ほど、まともにデバッガを使ったことがない。そもそも、プログラムらしいプログラムを実行したこともない。というのも、今必要な能力が、規格を理解して説明することだからだ。プログラムの実行というのも、コンパイラーのpartial orderingやオーバーロード解決が正しく行われているかどうかの確認の意味合いぐらいでしか、やっていない。

C++0xの実装では、gccが他のコンパイラーより進んでいる。

gccは、週間スナップショットをのビルドを、ここから手に入れて使っている。自前でビルドするのが面倒なのだ。

ところが、このバイナリの問題なのか、あるいはgccのiostream自体の問題なのか、なぜかiostreamを使おうとするとクラッシュする。とりあえず問題になるのは、以下のようなコードだ。

std::cout << 0 ;
std::cout << std::endl ;

どうも、数値やらendlやらを食わせると、クラッシュしてしまう。理由がわからない。

どうやら、いいかげんにgcc環境でのデバッガを触ってみたほうが良さそうだ。そこで、GDBを使ってみた。

ステップ実行していくと、最終的に、 __gnu_cxx::__default_lock_policy()という関数の中で、以下のようなエラーがでる。

Cannot access memory at address 0x0

 ∧＿∧
（　´∀｀）＜ ぬるぽ

うむ、さっぱり分からん。しかし、こんなコードでクラッシュするのならば、もっと問題になっても良さそうなのだが、さっぱり話題になっていない。なにか私の環境がおかしいのだろうか。まあ、iostreamなど、日本語には何の役にも立たないから、どうでもいいのだが。

C++0xの新機能、finalとoverride

gcc 4.7は、finalとoverrideを実装している。

finalとは、クラスの派生と、virtual関数のオーバーライドを禁止するための機能である。

struct B final { } ;
struct D : B { } ; // エラー

struct C { virtual void f() final { } } ;
struct D : C
{
    void f() { } // エラー、C::fはオーバーライドできない
} ;

これ以上説明する必要がないくらいに分かりやすい機能だ。現実的には、最底辺の基本クラスのvirtual関数のオーバーライドを禁止にするということはない。なぜならば、それは普通の関数とほぼかわりないからだ。あえて言えば、派生クラスで、同じシグネチャの関数を定義できなくする程度の意味しかない。大方、以下のような目的に使われるだろう。

struct A { virtual void f() = 0 ; } ;
struct B : A
{
    // 最終的な実装
    virtual void f() final
    { /* 実装 */}
} ;

// Bからは、まだ派生できるが、オーバーライドはさせない。
struct C : B { } ;

overrideは、「俺はオーバーライドするぞジョジョッ！」と明示的に叫ぶための機能である。overrideを指定しておきながら、実際にオーバーライドをしていないvirtual関数はエラーとなる。

struct Base { virtual void hoge() { } } ;

struct Fail : Base
{
    void hage() override { } // エラー、オーバーライドしていない
} ;

よくみると、Failのメンバー関数の名前は、hogeではなくhageになっている。そのため、hageは関数をオーバーライドしない。よってエラーとなる。

ご存知のように、virtual関数をオーバーライドするさいには、virtualキーワードは必要ない。しかし問題は、名前を間違えたり、仮引数や戻り値の型を間違えたりすると、別の関数になってしまう。

struct Base { virtual void func(int) { } } ;

struct Fail : Base
{
    // Base::hoge()をオーバーライドしたい
    void fucn(int) ; // 名前間違い
    void hoge(long) ; // 仮引数の型間違い
} ;

コンパイラーは喜んでこのコードを受け取り、別の関数として解釈してしまう。コンパイルエラーにならないのはもちろんのこと、警告を発するのも難しいのだ。たとえvirtualキーワードを使っていても、問題は変わらない。普通の関数ではなく、新しいvirtual関数を導入するだけだからだ。

間違いを防ぐためには、オーバーライドするということを明示的に示さなければならない。overrideはそのためのキーワードである。

完全を期すために付け加えると、finalとoverrideを組み合わせることもできる。

struct B { virtual void f() = 0 ; } ;
struct D : B
{
    void f() final override { }
} ;

意味はもちろん、finalとoverrideの両方である。

この新機能は、純粋にコンパイル時の些細なエラーを見つけやすくするための機能である。

この便利な機能がここ至るまでには、かなりの紆余曲折を経ている。そもそも、この機能はもともと、attributeを使って実現されるはずだったのだ。

// C++0xでは却下された機能
struct B { virtual void f() = 0 ; } ;
class C [[final]]
{
    [[final, override]] void f() { }
} ;

しかし、色々と議論した挙句、標準機能は独自のキーワードを与えられてしかるべきだというコンセンサスが得られた。しかし、一体どんなキーワードを使えばいいというのか。キーワードの追加は、互換性の敵である。既存のコードで使われていない識別子を選ぶ必要があるが、あまりに変な名前では、意味が分からない。finalというのは、他の言語の同等機能に与えられているキーワードである。しかし、さすがにfinalなどというキーワードを今更C++に付け加えることはできない。既存のコードを破壊してしまうからである。

苦渋の末、標準化委員会は、Contextual Keywordを使う決断をした。これは、ある特定の文脈で現れた時のみ、意味をなすキーワードである。

たとえば、C++の文法上、クラス指定子のクラス名の後に識別子が来ることはない。

class Name /*ここに識別子は使えない*/ : Base { } ;

とすれば、その場所だけで有効なキーワードを作ることができる。これは文法全体には影響しないので、finalという識別子は、他の場所では問題なく使える。

struct final final { } final ;
struct X final { } ;

本来、この機能にはもう一つ、hidingというキーワードが加わるはずだった。これは、attributeからcontextual keywordに移行するときに、newを再利用することになった。そして、最後の最後になって、ドラフトから削られた。

このhidingは、名前を隠すということを明示的に主張する機能である。

struct A
{
    int value ;
    void f( int ) ;
} ;
struct B : A
{
    int value ; // A::valueを隠す
    void f( double ) { } // A::fを隠す
} ;

int main()
{
    B b ;
    b.value = 0 ; // b.B::balue
    b.f( 0 ) ; // b.B::f
}

この、派生クラスのスコープが基本クラスのスコープ内の名前を隠すという挙動は、時として不思議な結果を招くことがある。また、うっかりして基本クラスのメンバーを隠してしまわないとも限らない。そのため、隠すということを明示的に主張するための、hidingが、finalやoverrideと同時に提案された。hidingが指定された名前が、実際には何も隠していない場合は、エラーとなる。

// C++0xでは却下された機能
struct A { int value ; }
struct B : A
{
    int vlaue new ; // エラー
} ;

B::vlaueは、typoである。単純な間違いだが、現実に起こりうる間違いである。しかもコンパイラーは警告を発することができない。hidingは、overrideと同じように、明示的な隠す主張を行えるようにした。

また、このoverrideとhidingを明示的に使わなければエラーとなる、explicitも提案された。

// C++0xでは却下された機能
struct A
{
    int value ;
    virtual void f() = 0 ;
} ;

struct B explicit : A
{
    int value ; // エラー、newが指定されていない
    void f() { } // エラー、overrideが指定されていない
} ;

何が問題だったかというと、hidingは、文法上、かなり広範な範囲で起こるのだが、既存の文法を虱潰しに対応させるだけの余裕がなかったのである。たとえば、using宣言が関係する場合はどうなるのか。

struct A { void f(int) ; } ;

struct B : A
{
    using A::f ;
    void f(double) ;
} ;

この場合、名前は隠されていない。しかし、using宣言で名前を隠すこともできる。

struct A { void f(int) ; } ;
struct B { void f(double) ; } ;

struct C : A, B
{
    using A::f ; // B::fを隠す
}

この機能が提案されたのは、規格がほぼ固まった後であり、到底対応する時間はなかった。また、hidingのために、newキーワードを再利用するというのは、あまり賛同を得られなかった。結局、色々と議論した挙句、今、早急にhidingを言語仕様に取り入れるのは、将来のためによろしくないと結論した。そこで、hidingが取り除かれ、それに関連して、explicitも取り除かれた。なぜなら、hidingなしでexplicitだけあっても、片手落ちであるし、将来hidingを取り入れた時に、深刻な互換性の問題を引き起こすからである。

色々あって、本来の機能の半分以上がそがれてしまい、finalとoverrideだけが残ったのである。

ユタ州とキリスト教は終わってるな

A gay teen describes her experience at a Utah brainwashing facility : troubledteens

モルモン？　同じキリスト教である。創価学会と仏教が同じようなものだ。信長は正しいことをした。

技術を理解しないものによって法律が書かれる悲劇

BBC Site Uses Cookies To Inform Visitors of Anti-Cookie Law - Slashdot

EUは、俗称アンチクッキー法と呼ばれる、クッキーの利用を制限する法律を、5月25日から施行した。

イギリスのテレビ会社、BBCのウェブサイト、Radio Timesでは、これを受けて、26日より法律に対応した。最初にサイトを訪問した際、クッキーを使用していいかどうかを尋ねるのだ。

ここでクッキーの使用を拒否すると、クッキーは使用されない。ただし、二度目以降にサイトを訪問した場合、たとえクッキー使用を拒否しようと、このメッセージは表示されない。何故か。クッキー使用に同意したか拒否したかを、クッキーを使って記録しているからだ。

これは、技術を理解しない者の手によって法律が書かれたために起こる悲劇である。

そもそも、クッキーとは、クライアント側のソフトウェアが提供している機能である。クッキーの使用が嫌ならば、ブラウザーのクッキーの機能を無効にすればいい。ほとんどのブラウザーは、クッキーを無効にするためのオプションを提供している。

日本のアンチウイルス法も、同じ道をたどるのだろうか。

追記：slashdotのコメントによると、EUのアンチクッキー法は、トラッキングクッキーのみを禁止しているのであって、セッションクッキーや、ウェブサイトの利用に必要なクッキーの利用まで制限しているわけではないという。しかし、クッキーはあくまでクッキーであって、技術的には何も違いはないのだ。トラッキングクッキーと、ウェブサイトの利用に必要なクッキーとの技術的な違いは何もないのだ。EU圏の考え方は分からん。

ルーミスの著作権は一部存続しているはず

効率よく絵が上達する方法　人体の構造を理解することは萌え絵上達への近道 ｜ お絵かき速報！萌え絵上達法

上記スレを読んでいて、以下のレスが気にかかった。

ルーミス pdfでぐぐれ、違法サイトでもなんでもない

ルーミスは50年以上前に死去した人物なので
著作権関係が失効しているんだよ

アンドリュー・ルーミスは1959年になくなった。したがって、日本国内では、原書の著作権は2010年に失効しているといいたいのだろう。

しかし、おそらく違うはずだ。日本国内では、まだ一部の著作物の著作権が存続しているはずである。彼の著作は6冊ある。

1. Fun with a Pencil (1939)
2. Figure Drawing for All It's Worth (1943)
3. Creative Illustration (1947)
4. Successful Drawing (1951)
5. Drawing the Head and Hands (1956)
6. The Eye of the Painter (1961)

このうちの、最初の3冊の著作権は、日本国内ではまだ存続しているはずだ。何故ならば、戦時加算があるからだ。ルーミスはアメリカ人であり、著作物はアメリカ合衆国で公開されている。一部の著作物は、終戦前に公開されている。これは戦時加算の対象になる。ということは、

1939年に公開されたFun with a Pencilの著作権は、2020年5月22日（3794日)まで、
1943年1月1日に公開されたFigure Drawing for All It's Worthの著作権は、2019年4月29日（3405日）まで、
1947年（日付不明、仮に1月1日で計算）に公開されたCreative Illustrationの著作権は、2015年の4月29日（1944日）まで、
著作権が存続しているはずである。

後の3冊は著作権が切れている。Successful Drawingは戦時加算が483日しかないので、2011年4月29日に著作権が切れているはずだ。あれ、つい先月なのか？

戦時加算に暦年主義が適用されないというのが、また計算しづらい。

終戦前に公開されて、作者が終戦後に死んだ著作物の著作権の保護期間は、不平等な戦時加算という仕組みのせいで、実に違和感がある。我が国は未だに敗戦国のなのだ。

プログラミング認可制の日は近い

高木浩光＠自宅の日記 - ウイルス罪法案、バグ放置が提供罪に該当する事態は「ある」と法務省見解

政府は、バグ放置が罪せらるとの見解を発表した。また一歩、日本が後退した瞬間である。

そもそも、放置とは何を言うのか。大部分のソフトウェアのバグフィクス、特にセキュリティに関するバグというのは、バグ発見者の善意によってなりたっている。バグを発見したものが、ソフトウェアに対して責任をもつ会社または個人に、秘密のうちに連絡をとり、バグの内容を伝える。責任者は、秘密裏のうちにバグを直し、アップデートパッチを公開する。バグの具体的な内容が公開されるのは、パッチ公開後である。この過程を経ずしていきなりバグが公になることを、ゼロデイという。ゼロデイは、マルウェアが未知のバグを利用していたり、またバグ発見者が、何らかの理由によって（たいていは、無責任な責任者にあきれて）、いきなり公開したりすることで起こる。

バグの修正には、時間がかかる。バグ自体を治すのは、数行のコードの修正で済むかもしれない。しかし、修正が正しく動くかのテストや、パッチをユーザーに適用させるまでには、相当な時間がかかる。そのため、常にはそういう風にバグフィクスが行われるのだ。

このパッチを準備している間は、バグの具体的な内容について言及しないので、はたからみれば放置に見える。しかし、果たして放置なのだろうか。アップデートを用意する前に、バグの内容を公開するのは危険なのだ。

おそらく、この判断の根底にあるのは、まことに日本の公務員的発想なのだろう。つまり、「ソフトウェアは、いかにマヌケなユーザーによって操作されたとしても、決してユーザーの意図に反する挙動をしてはならない」という幻想を持っているのだ。これには先例がある。日本の警察はこの信念を持って両刃の刃物を禁止した。それ、プログラミングは魔法か。

このような人種が、パスワードを失念したために、暗号化ソフトウェアによって暗号化されたファイルを復号化できないと文句をつけるのである。

ことここに至れば、プログラミングが認可制になるのは、そう遠い話ではないだろう。プログラマーは国家試験を通って国家資格を手に入れなければ、プログラミングできなくなるのだ。また、ソフトウェアは、公開される前にかならず国の認可を必要とする。

国家試験の出題範囲は、CASLとCOBOLになるだろう。ソフトウェアの認可にあたっては、極めてリテラシーの低い公務員に対して、いかに我がソフトウェアは安全かということを、お題目のように唱え続けなければならない。時には、袖の下を通したり、公務員OBを雇用したりなどの便宜をはかることが必須となるだろう。

そのような未来において、我々プログラマーはお互いを同志と呼び合い、プログラミング作業はすべてテレスクリーンで監視され、二分間憎悪で偉大なる伝説のプログラマーを褒め称え、テレスクリーンは我が国のソフトウェアのバグ率が0%であることを誇らしげに報道するだろう。

およそ公務員のリテラシーは低い。私はかつて、公務員を目指すものが多く集まっているところで、「プログラミングとは何ぞや」という質問を受けた。私は、「MS WindowsやMS Office、あるいはゲームや携帯電話の画面に表示されているものに至るまで、すべてはソフトウェアによって制御されている。プログラミングとは、ソフトウェアを作るための作業である」と説明した。しかし、彼らは依然として、首を傾げるのである。

今や、車やバイクですらソフトウェアによって制御されているのに、何故彼らはプログラミングとは何かという根本的な概念すら理解できないのか。

文書をメールで送るために、Excelを方眼紙替わりに使い、ケータイのデジカメで画面の写真をとり、画像をメールに添付して送るは、それ公務員なり。

initializer_listのコピー

Bug 49122 – [C++0x] initializer_list is broken

なかなか興味深い。

initializer_listには、明示的なコンストラクターがない。initializer_listのコピーは、内部的な要素をコピーしないと明言されている。

initizalizer_listの実装というのは、ポインターが想定されている。例えば以下のようなコードに対しては、

std::initializer_list<int> list = { 1, 2, 3 } ;

以下のような実装になる。

int a[3] = { 1, 2, 3 } ;
// 実装依存の方法で、配列aの要素へのポインターを保持するinitializer_listを生成

とすれば、以下のコードが動かないのも、当然と言える。

std::initializer_list<int> f()
{
    std::initializer_list<int> list = { 1, 2, 3 } ;
    return list ;
}

何故ならば、関数が返したinitializer_listの内部的なポインターは、もはや妥当なメモリを指し示していないからだ。

というわけで、関数の戻り値の型として使いたければ、std::arrayやstd::vectorなどのコンテナーを使うべきだろう。

高橋名人、ハドソンを退社す

退社報告 | 高橋名人公式ブログ 16連射のつぶやき | 高橋名人 OFFICIAL SITE 16SHOT

まあ、ハドソンは最近落ち目だったし、ゲームと言っても、桃鉄ぐらいしか売れるものがなかった。あとは、ケータイ用の粗悪なゲームばかり。結局、コナミに買収されてしまった。第一、コナミからして、粗悪なキャラゲーばかり乱発している会社ではないか。本物のゲームを作った試しがない会社である。

結局これも、ひとつの時代が終わったということだろう。当時の貧弱なハードで、なんとかゲーム性をだそうとすると、ひたすら手動で、総当りをさせたり連打させたりするようなゲームになるのも、当然と言える。また、まだアーケードゲームの影響が濃かった自体で、家庭用ゲームでも、クレジットという概念があった時代だ。残機というのも、金を投入する都合上、設けられたものだ。

それを考えると、現代のゲームは、人に優しくなった。死ぬと最初からやり直しということもなくなり、ライフは自動回復するようになった。ただし、また変な方向に進んでしまったと思う。

ひとつはキャラゲーだ。とりあえず有名な漫画やアニメ、はては芸人やスポーツ選手などの名前を買ってきて、それで愚にもつかぬゲームを乱発するようになったのだ。無論、当時とて、そういう傾向がなかったわけではないが、近年ますますひどくなるばかりだ。

もうひとつは、ゲームと映画を勘違いしているということだ。いつの頃からか、ゲームは動画を多用するようになった。ここでいう「動画」の定義とは、プリレンダリングにしろ、リアルタイムレンダリングにしろ、ユーザーの入力を受け付けず、ただ決められた映像を流すだけのことをいう。本物のゲームとは、ユーザーの入力に応じて出力の変化が起こる装置である。動画を垂れ流すだけの装置を、私は本物のゲームとは認めない。

最近、本物のゲームが少なくなった。今年発売される予定のゲームで期待しているのは、BethesdaのThe Elder Scroll: Skyrimと、Bethesdaに買収されたid SoftwareのRageだが、果たして期待通りのゲームなのかどうか分からない。E3が楽しみだ。その前に、新しいPC（せめて、新しいGPU）を買わなければ、このゲームが動かせないのだが。

あなたも量子コンピューターを買える。今ならたったの一千万ドル

Buy Your Own Quantum Computer for $10 Milion

Crysisは動かせないけどね。

なるほど、日本語を学びたいんだね

かなり古いネタだが、面白かった。

So You Want To learn Japanese...