newは、配列を確保できる。このとき、配列の要素数は、定数でなくても構わない。
void f( int n )
{
new int[n] ;
}
newは、配列の配列を確保できる。このとき、配列の最初の要素数は、定数でなくても構わない。最初以外の要素数は、定数でなければならない。
void f( int n )
{
new int[n][5] ; // OK
new int[n][5][5] ; // OK
new int[5][n] ; // ill-formed
new int[n][n] ; // ill-formed
}
今まで、配列の配列をnewで確保しようと思ったことがないので気がつかなかったが、何故だろう。
ユーザー定義リテラルに負数を渡す方法は存在しない。
void operator "" _x(unsigned long long value) { }
// call operator "" _x(100) ;
100_x ;
// call operator "" _x(100) ;
// then apply unary - operator to the result.
// since return type of operator "" _x is void
// it's ill-formed.
-100_x ;
なぜなら、+-という符号は、整数リテラルではなく、単項演算子だからだ。これは、浮動小数点数リテラルでも同じである。
では、どうしても負数を表現したい場合、どうすればいいか。文字列で渡すしかない。文字列ならば、いくらでも自分の好きな負数の表現方法を定義できる。
qi::repeat - Faith and Brave - C++で遊ぼうをみて、ユーザー定義リテラルを使えば、少しコードが読みやすくなるのではないかと思った。ただ、ユーザー定義リテラルは制限も厳しすぎるので、あまりたいしたことはできない。
例えば、n回リピートするというnという引数と、何をリピートするのかという引数を、同時に渡すことができない。もちろん、ユーザー定義文字列リテラルならば、どうとでも好きになるが、二つの引数を渡すのに文字列はそぐわない。
それに、ユーザー定義リテラルのは、コンパイル時に引数が決定していなければならないので、やはり、よほど限定的な上京でしか使えない。
たとえば、nはコンパイル時に決まるとして、operator "" _repeat_1から、operator "" _repeat_10あたりまでを定義して、別の関数によりnを表現して、引数として文字を取るなどすれば、コンパイル時にnと文字を決められる環境では、すこし便利になるかもしれない。
C++でのビット演算は、シフト演算子を除いては、実にあっけない定義のされ方をしている。~演算子は、オペランドの1の補数を返すとされているし（つまりはビット反転）、bitwise AND演算子は、オペランドのbitwise ANDを返すとされている。その他も、同様だ。
何も書かれていないということは、実装依存ということでいいのだろうか。たとえば、signedな整数型が2の補数であるかどうかは規定されていない。とすれば、ビット演算の結果がどうなるかなどは、具体的に定義できるわけがない。そういうことなのだろうか。
ICANNは、とうとう.xxxを認めるようだ。この問題は、非常に長く議論されてきた。ICNANNは、2000年に、.xxxドメインの認可を拒否している。
トップレベルドメインなど、最近はスポンサー付きで認められているものもたくさんある。アダルトコンテンツは、インターネット上のコンテンツのかなりの部分を占めていることは疑いがない。とすれば、別に認めてもいいのではないかという意見もあるだろう。しかし、実際の問題は、少し複雑なのである。
たとえば、アダルトサイト用に.sexとか.xxxなどというトップレベルドメインが認可されたとする。ここで問題なのは、政府や行政機関が、アダルトコンテンツは、専用のトップレベルドメインを使用しなければならないなどと強制するかもしれないということである。これは、非常に問題がある。
そもそも、ドメイン名は、コンテンツの種別を強く表すものではない。例えば、.orgは、非営利団体しか使えないということはない。
もうひとつの問題は、何がアダルトコンテンツとみなされるかは、非常に曖昧だということである。例えば、政府にとって都合の悪いコンテンツは、アダルトコンテンツとみなされる可能性もある。とすれば、.xxxは問題をややこしくするだけで、何の解決にもならない。
この辺の議論は、RFC3675 ".sex Considered Dangerous"に、よくまとめられている。
RFC 3675 .sex Considered Dangerous
差し当たっての俗人的な興味としては、誰がsex.xxxとかxxx.xxxなどというドメインを取得するかである。もっとも2ch.netとかyotube.comというWebサイトをみるにも、ドメインを直接打つより、ググッている私にとって、ドメインビジネスには、あまり興味がない。私がググる理由は、直接URLを打つと、常にtypoの可能性があるからである。Googleは、間違っているかもしれないということを、素晴らしい精度で指摘してくれる。
痛いニュース(ﾉ∀`) : 米ロ大統領、ハンバーガー店で昼食 オバマ氏が招待…ロシア大統領「ヘルシーではない」 - ライブドアブログ
世の中は平和になったものだ。たとえパフォーマンスにしても、二十年前は到底できなかった。
昔々、とはいってもたかが5, 6年ぐらい前まで、2ch.netでは、2ch語とよばれる、一種独特の言語が流行っていた。
藻前らみたいな香具師は半年ROMっても分からんだろうから、特別に教えてやると、2ch語というのは、こんな風にわざと誤字、脱字を多用した言語のことであると言ってみるテスト。
しかり、ほんの五年ほど前まで、2ch語の数の多いことは、今日の比ではなかった。多くの者は、無理やり使おうとしている感がする文章を書いていたが、結局、使っていたことは使っていたのである。それが、一体どうして、わずかにその名残をとどめるだけで、消え去ってしまったのか。
一方、時を同じくして、英語圏でも、当時はleetが流行っていたが、今は、殆ど死滅してしまった。これは一体どうしたことか。
誰か、この言語の流行り廃りが、何故起こるのかという研究している言語学者はいないものだろうか。インターネットでは、その流行り廃りの速度が著しく早く、また範囲も物理的な地理に制限されないということはあるが、基本的には、ネット以前の言語の流行り廃りと変わらないはずである。従って、ネットで使われている言語に当てはめられない法則は、単なる一学者の妄想であり、大いに間違っていると言わざるをえない。
私の意見としては、2chは大衆化しすぎたのではないかと思う。今の2chには、貴賎上下様々な人間が存在し、到底、共通の価値観を共有しあえない。とすると、共通の独自言語というのも、無理な話だ。
まあ少なくとも、資料だけは豊富だ。何しろ、一次資料である過去ログが、すべて残っている。しかし、残念ながら、いくら当時の一次資料であるとはいえ、過去ログを読んでも、理解できることは少ない。なぜなら、当時の社会情勢や話題の出来事などといった事が、言語に反映されているので、現代の我々には、到底理解不可能である。
思うに、これは俳諧と似ている。本来、俳諧とは、その時の社会情勢や心持ちを五七五と七七で、だらだらと続けていくものであった。別に、後の世に理解してもらおうなどとは、思ってもいなかった。その面白みが理解出来ないために、後の世になると、俳諧はクソだ。新に優れたのは俳句だなどと、ヘタレな自称俳人が言い始めたのである。
柳田國男は、その著作の中で、「たかが三百年前の文章に注釈を要するとは変な話である」と書いている。しかし、ほんの五六年前まで、2chでは、2ch語が普通に使われていた。それを考えると、たかが五六年前の・・・・・・いやよそう、こんなことを書き残しておくと、後の世に笑われることになる。
「おい見ろよ、昔は、五年前の大昔の文章が分からないと悩んでいたらしいぜ。無理に決まってるじゃん五年前なんて。今の時代では、三時間前の文章すら、注釈があっても理解できないんだから」
「炊く」という言葉を聞いたとき、まず思い浮かぶのは、米を水と共に加熱して、食味を増す調理法である。あるいは、「煙を炊く」という言葉もある。これによって、発炎筒も「炊く」ものである
ところが、この炊くという言葉には、現代では、色々と不思議な文脈で使われているのである。
例えば、「カメラのフラッシュを炊く」という言葉がある。意味は、カメラのフラッシュを光らせることである。なぜ炊くというのか。どうやらこれは、昔のカメラのフラッシュというのは、マグネシウムを燃やして、文字通り炊いていたらしいのである。フラッシュが電化された現代においても、この言葉は、慣習的に生き残った。
ところで、今流行の「自炊」という言葉がある。本来の意味は、自分で料理をすることである。しかし最近は、自分で本をスキャナにかけて電子化することをも指す。しかし、何故「自炊」というのか。
この言葉は、昔、WinMXやWinnyが全盛期だった頃、雑誌などを、自分でスキャンしてアップロードすることを、「自炊」と呼んでいた歴史があるから、今でも定着して使われているのである。しかし、なぜ自炊というのか。自力とか自弁などという言葉でもいいではないか。調べた結果、どうも二つの説があるようだ。
ひとつの説。慣習的に、ホームレスにその場で調理した食事を与えることを、「炊き出し」という。炊き出しという言葉は、別にホームレスに食事を与えることだけを意味しないのだが、やはりそのイメージは強い。この言葉を借りてきて、本をスキャンしてアップロードすることをも、「炊き出し」と呼んだ。炊き出しを受ける者は、ただダウンロードするだけのネット乞食である。而して、このスキャンすることを、「炊く」といい、自分でスキャンすることを、「自炊」と呼ぶようになった。
もうひとつの説。WinMX以前の太古より、ゲームのカートリッジのROMイメージをダンプすることを、「吸出し」と呼んでいた。これを自分で行うことを、省略して、「自吸」と書き表していたが、そのような言葉はない。IMEの変換候補に現れるのは、「自炊」であった。そこで、自炊という表記が定着した。そこから、本をスキャンすることを、炊くと呼ぶようになった。
どちらが正しいのか、よく分からない。まず一つ目の説だが、もしこれが正しいとすると、あらゆる著作物の違法なアップロードは、「炊き出し」と呼ばれてしかるべきである。なぜ本のスキャンだけが炊くと呼ばれるのか。手間がかかるから、特別に炊き出しという言葉を用いたのか。
二つ目の説、ROMイメージをダンプすることを、吸出しと呼んでいたことは、相当古い歴史がある。しかし、なぜその言葉を、本のスキャンに用いようとしたのか。ROMイメージのダンプを吸出しと呼ぶことは、感覚として理解できる。しかしなぜ、ROMイメージのダンプ以外にも、自炊という言葉を使おうとしたのか、よく分からない。あるいは、スキャナーは強い光を出して紙をスキャンするわけだから、カメラのフラッシュを炊くという言葉が存在した関係上、炊くという言葉に、あまり違和感がなかったのだろうか。
それにしても、自炊という言葉が現れたのは、この十年のことである。たとえば、五年ぐらい前に、2chのDownload板にでも、「やい、藻前ら、漏れに自炊の語源を説明汁」とでも書き込めば、多くの、「半年ROMってろ」というレスとともに、答えも得られたはずである。しかも、多くの者はその語源をすら忘れている。最近の言語の進化の速度は、驚くべき速さであるという他ない。そういえば、2chでは、もはや極端なleet speakは見られない。これも、自然言語を考える上では、興味深い。
10 things we still print that should be digital by now | Printing Choice
小切手
そもそも、今時誰が小切手なんて使ってるんだよ、マジで。
紙幣
紙多すぎだろ、常識的に考えて。こいつをデジタル化して、コスト削減しようぜ、いい加減に。
飛行機のチケット
ここ数年で、飛行機会社はバカバカしい厚紙で作られたチケットはやめたみたいだ。でも、いまだに家でチケットを印刷するか、飛行場のキオスクで印刷した奴を提示しなきゃならん。一体、何の意味があるんだよ。飛行機会社は、当乗客全員分の個人情報をデジタルデータで持っているし、たとえチケットを持っていたとしても、何度も身分証明証の提示を求める。だったら、最初から、紙のチケットなんていらねぇじゃねぇか。
運転免許証
なんで身分証明書をカードに印刷しなきゃなんねーんだよ。指紋認証技術とやらが実用化されてから、もう何十年もたってるじゃねーか。マイノリティ・リポートを観たか？ 未来の奴らは網膜認証してるぜ。そもそも、ほとんどの奴はモバイル機器をもち歩いているじゃねーか。携帯やスマートフォンに免許証を統合するのは当然の流れだろ。もちろん、色々と解決しなきゃならないセキュリティ上の問題はあるにせよだ。より便利になるに決まっている。だろ？
パスポート
パスポートだって同じだ。政府と飛行機会社が提携すれば、手書きの書類より便利になるはずだろうがよ。デジタル化すれば、くだらないヒューマンエラーを防げるし、紙の書類業務より、素早く旅行できるだろうが。まったく。
名刺
お前なぁ、この21世紀に名前とメアドを書いたゴミを持ち歩くぐらい馬鹿げた事はないだろ。名刺に書ける程度の情報なんて、あとでメールで送りゃぁいいじゃねぇか。「よぉ、先日はまいどおおきに。これワシの連絡先やねん。今後ともよろしゅう」ってな感じだ。Bump for the iPhoneみたいなアプリを使えば、一瞬で情報を交換できるじゃねぇか。名刺を持ち歩かなくて済むようになると、ポケットの中も軽くなるしな。
レシート
この前、店で買い物したらよ、レシート印刷する代わりに、メールで送るかって聞かれたよ。こいつぁスゲーぜ。何たって、紙を机の引き出しにしまっておくより、メールボックスの中に入れといたほうが便利だぜ。だいたい、俺らは常にケータイを携帯してるんだ。将来、その場ですぐにレジからケータイに送信するぐらいできてしかるべきだろ。
駐車違反の請求書
そんな馬鹿げたもんを車に貼り付けるなよ。どうせ取れてどこかに行っちまうに決まってんだろ。税金の無駄だ。警察は、車のナンバーから所有者のメアドに、罰金の通知メールを送れてしかるべきだ。警官は、メールに画像とか動画を添付して、明らかな証拠を見せることだってできる。世の中はもっと公平になるし、警察の透明度も上がるって寸法だ。あと紙とインクの節約にもなるな。
紙の新聞
もうそろそろ皆同意してくれると思うが、紙の新聞の時代は終わった。紙の新聞は廃止して。ネットに完全移行すべきだ。
もちろん、印刷を完全に廃止することなんて無理だ。紙の本をありがたがる人種は、常にいるからな。そういう奴には、そういう市場があってもいい。でもな、いい加減にデジタル化すべき不必要な印刷物が多すぎるだろ、常識的に考えて。
class member accessのvalue categoryは、解説すべきだろうか。解説するとして、どこまで解説すべきだろうか。全部だろうか。というのも、この辺のルールは、規格ではわずかに半ページとはいえ、かなり複雑なのだ。それに、詳細なルールを知っていても、普通のプログラミングの上で、あまり役に立つことはない。このルールを暗記するのは、全演算子の優先順位を暗記するぐらい馬鹿げている。
ふときがつくと、noexcept operatorなるものが追加されていた。これは、オペランドの式が、例外を投げそうな式を含む場合、falseを返す演算子である。結果はもちろん、定数だ。つまり、メタプログラミングに使える。オペランドの式は、評価されない。
void f() noexcept;
void g() ;
noexcept( f() ) ; // true
noexcept( g() ) ; // false
noexcept( throw 0 ) ; // false
// ポリモーフィック型
struct Base { virtual void f() {} } ;
struct Derived : Base { } ;
Base base ;
noexcept( dynamic_cast<Derived &>(base) ) ; // false
noexcept( typeid(base) ) ; // false
たとえ、式を評価した結果、絶対に例外を投げることがなかったとしても、例外を投げる可能性のある式を含む場合、falseになる。たとえ、暗黙的にであれ、falseとなる。
// new式は例外を投げる可能性のある関数を呼ぶ。 noexcept( new int ) ; // false // 例外を投げることはないが、throwを「含む」のでfalse noexcept( true ? 0 : throw 0 ) ; // false
基本的には、exception specificationで、noexceptかnoexcept(true)が指定されているような、明示的な関数呼び出しの式ぐらいしか、trueにならない。実用上も、メタプログラミングで、ある関数が（演算子のオーバーロードも含めて）noexcept指定されているかどうか調べるのに使うことを想定しているのだろう。
漫画には、引き伸ばしという手法がある。これは一般に、より多くの話数を稼ぐ手法である。理由は単純で、経済的な利益のためだ。人気漫画が、すぐに完結してしまっては、全然稼げない。それ故、人気であればあるほど、露骨な引き伸ばしが行われることになる。
また、漫画家としての寿命を延ばす働きもある。およそ一個の人間というものは、その生涯に、そう何作もアタリを出すことはできない。長く活動している漫画家というのは、大抵、ひとつの大いにあたった作品を続けているか、あるいは、そのアタリ作の外伝を描くなど、その周辺で活動しているのである。まったく違う作品を描いて、どれも大ヒットというわけにはいかない。
さて、この引き伸ばし手法だが、私が思うに、時代によって変遷がある。そこでひとつ、これをまとめてみようと思う。
まず、昔の引き伸ばし手法だ。昔の引き伸ばし手法は、同じようなキャラクター、同じような大筋で、細部だけを変えるというものである。これは、例えば手塚治虫や藤子不二雄といった漫画家が、よく用いた手法である。
手塚治虫のキャラクターは、実によく記号化されている。作品ごとに話は違うが、出てくるキャラの外見や性格は、実によく似ている。話のネタは、大抵、古典などから引っ張ってくる。
藤子不二雄（ミドルネームがややこしいが省略）のキャラクターも、これまた同じように記号化されている。これも作品ごとに細かい事情は違うが、結局、皆似たような結果になる。
つまり、手塚治虫や藤子不二雄は、似たようなキャラクターと代替の筋書きを、微妙に異なる設定の作品で使いまわしているのである。彼らの作品は多いが、話の大筋は、大抵同じである。
実際のところ、これらの漫画を、単に漫画家個人の著作とするのには、私はどうも違和感を感ずる。というのも、彼らの作品というのは、実際のところ、手塚プロや藤子・F・不二雄プロと名乗る団体作品である。ピカソの作品が何万点もあるというのと、全く違いはない。ピカソの作品にしても、ピカソという名義を使っているだけで、本人がすべてを制作したわけではない。
言わば、同じネタの使い回しである。これについて、ほかならぬ藤子・F・不二雄の名言が残っている。おぼっちゃまくんで有名な小林よしのりは藤子・F・不二雄から、「おぼっちゃまくんは8年もつづいているのだから、もうあとは何年でも続けられる」ということを言われたという。おぼっちゃまくんは、当時、コロコロコミックで連載されていた。コロコロコミックの読者というのは、基本的に小学生である。また、おぼっちゃまくんは確かに面白いが、万人受けする漫画ではない。あの漫画を真に楽しむには、幼い子供であることを要する。つまり、8年もたてば、最初の読者は、もうおぼっちゃまくんを楽しめない年齢になってしまっている。とすれば、昔の同じネタを使いまわしても、読者は苦情を出さないのである。
さて、時代は移って、近代の引き伸ばし手法だ。これは、ひとつの作品に、新たなネタを供給し続けて、終わらせずに続けるという手法である。
これは、例えばドラゴンボールが有名だろうか。ピッコロ大魔王とマジュニアあたりまでなら、まだ最初の構想の延長という形で理解できた。そこから引き伸ばす必要がでてきて、サイヤ人やらフリーザやらをだした。ここまでは、まだよかった。そこからさらに、セルやら魔人ブウなどをだして、もうパワーインフレしすぎて破綻してしまった。とはいえ、ドラゴンボールは疑う余地なく、大人気の一流漫画である。
この手法に優れてるのは、週刊ジャンプの連載作である。普通、ひとつの作品では、そう長くネタは持たない。結局、終わらせなければならない時がやってくる。週刊ジャンプは、この問題に対して、すばらしい解決方法を編み出した。トーナメント制の格闘に移行させるのである。
格闘ならば、とりあえずいくらかの話数は稼げる。修業をするだけで数話稼ぐこともできるし、技の解説をするだけで丸々一話費やすこともできる。しかし、さらに優れているのは、トーナメント制の勝ち抜き格闘という手法である。これなら、とりあえずキャラを数十人用意しておくだけで、容易に話を展開させることができる。さらに、キャラごとに背景事情の解説などを始めると、さらに話数が稼げておいしい。
このため、週刊ジャンプでは、人気が出てしまって、経済的な理由でどうしても続けたいギャグマンガは、例外なくトーナメント制の勝ち抜き格闘に移行することになる。
さて、最新の引き伸ばし手法だ。手塚治虫のように、同じネタを使いまわすというのは、もうさんざん行われたので、今となっては、なかなかやりにくい。また、後からネタを付け足すのは、話に矛盾が生じてしまい、また力のインフレも激しく、これまた難しい。では、今の流行の引き伸ばし手法は何か。ひとつのネタを、できるだけ長く続けることである。
たとえば、以前なら、たったの数コマで終わらせていたものを、それだけで一話稼ぐ。これには、キャラの複雑で詳細な心理描写をしたり、回想シーンを挿入したり、「一方その頃、別の場所では」などという別視点の話を入れたりして、できるだけネタを温存して大切に使う。そのため、話は一話で起承転結をなさない。
そんなに引き伸ばしてばかりしていては、途中から読む読者が、話についていけず、結局、読者離れを招くだけなのではないかと思うのだが、よく分からないものだ。
この手法に最も優れているのは、福本伸行であろう。存在自体が天の外伝であるアカギで、もう十年以上も、たった一晩の麻雀勝負を描き続けている。惚れ惚れするまでの引き伸ばしである。
これらの引き伸ばし手法は、漫画に限った話ではなく、小説やアニメやゲームや映画などでも、存分に活用されている。最近、この露骨な引き伸ばしが嫌で、近代の作品を楽しめなくなってしまった。小説などを読んでいても、明らかに字数を稼ぐための、仕方がなくひねり出して書いたような質の悪い文章が目につき、作品の内容より、執筆中の作者の心理状況が察せられ、素直に作品を楽しめなくなってしまう。結局、原稿用紙何百枚相当の小説などというくだらない制限があるために、あるいは無駄な描写をいれ、あるいは必要な描写をそぎ落として、残りの絞りカスのすかしっ屁みたいな作品に成り下がってしまうのであろう。残念なことだ。
本来、作品に、そんなに長さは必要ないはずなのだ。状況説明とか、心理描写などは、無駄に長く書く必要はないのだ。ましてや、商業の小説は、規定の長さを満たさなければならないなどというのは、制限でしかない。
たとえば、悪者が正義の味方に銃を向けた場合、その銃がどのような機構で動作するとか、装填されている弾丸はホーローポイントなのでかくかくしかじかの理由により殺傷力が高いだとか、悪者と正義の味方の複雑な心理描写だとかは、必要ないはずだ。近代的な銃が非常に強力なことは、全読者が了解していることであろうし、その理解のために銃や弾丸の仕組みを説明する必要もないはずだ。銃を向けた者、向けられた者の心境も、さして長ったらしい詳細な描写を必要としないはずである。
銃がそうであるとすると、魔法とか超能力であっても、事情は同じであるはずだ。悪い魔法使いが魔法の杖を振り上げたとき、その魔法がどのような力を持つかなどは、わざわざ説明しなくてもいいはずなのだが、どうも現実の、いわゆる「剣と魔法の小説」の作者は、必ず説明を入れなければ、読者が承知しないと思っているようである。
作品の品質が、ある一定の長さを満たすかどうかをもって評価されている現状は、真の芸術のために、実に残念である。
Googleリーダーで部分配信しかしていないフィードでも全文取得する『Google Reader Full Feed』 | Macの手書き説明書
Google Reader Full Feed - Google Chrome extension gallery
「こんなのがほしかったー」
他にも、Firefox、Opera、Safari用のユーザースクリプトや拡張もある。
クラスメンバーアクセスの演算子を、どのように解説するか悩んでいる。問題は、どこまで詳細に解説するかだ。
また、value categoryをどこまで解説するかという問題もある。これは演算子のところで解説するよりも、value categoryを解説するところで解説したほうがいいのではないか。
まあ、あんなことだろうとは思っていた。それより、この件で、警告も何もなしで、いきなり逮捕令状がでて、しかも二十日間も、外部から隔離して反論させずに勾留できる現行の法律は、危険だと言わざるをえない。
Appleマクロの恐怖 - Faith and Brave - C++で遊ぼう
Appleのクソヘッダーがcheckとかrequireとかverifyなどといった、あまりにも一般的すぎる単語をプリプロセッサーマクロで定義している問題。MSも、あの悪名高いminやmaxマクロを定義している。
最良の解決策は、そんなクソマクロを定義したヘッダーを使わないこと。
ところで、#2115 (Avoid bad Apple macros) – Boost C++ Librariesをみると、BOOST_PREVENT_MACRO_SUBSTITUTIONというものがあり、これを使えば、この問題を解決できるらしい。何と、そんな便利なものがあるのか。早く言ってよね。しかし、なぜか、"Perhaps sadly, I have to agree."と言われている。何故そんなに落ち込んでいるのだろうか。気になる。さっそく、実装を見てみた。
// boost\config\suffix.hpp // 実装 #define BOOST_PREVENT_MACRO_SUBSTITUTION
なんじゃこりゃ。ドキュメントが見つからないが、とりあえず、使い方は分かった。そして、絶望した。以下のようなコードがあったとする。
// クソなマクロ
#define check(x) (x)
int check(int x ) { return x ; }
int main()
{
check(0) ;
}
このままでは、checkというクソなマクロのせいで、コンパイルエラーになってしまう。そこで、BOOST_PREVENT_MACRO_SUBSTITUTIONの登場だ。
// 以下のマクロの為、#include
// #define BOOST_PREVENT_MACRO_SUBSTITUTION
#include <boost/config.hpp>
// クソなマクロ
#define check(x) (x)
int check BOOST_PREVENT_MACRO_SUBSTITUTION (int x ) { return x ; }
int main()
{
check BOOST_PREVENT_MACRO_SUBSTITUTION (0) ;
}
ようは、function-like macroというのは、名前(引数)の形で使うのだから、名前と左括弧の間に、なにか別のobject-like macroをいれてやれば、マクロの適用を阻害できるのだ。
なるほど、それで、"Perhaps sadly, I have to agree."なわけか。
昔、震旦の河東という所に、欲深い尼が住んでいた。何かといえば法華経を持ち出し、現当二世安楽を説いては、布施物を得ることを生業としていた。世の人の評判では、この尼は、「懇に行い、その身清浄にして、常に法華経を読誦す」との事であった。しかし、その実態は、わずかに妙法蓮華経という題目を知るだけであり、常に読誦する法華経というのも、「南無妙法蓮華経」とか無量義経の偈の文句でしかなかった。
さて、この尼の人となりは、所詮この程度であったので、密かに間男がいたとしても、読者はそう驚くまい。ある日、尼はその男と、いかにすれば、もっと多くの布施物を得られるだろうかと話していた。
尼「やはりよ、おれが思うによ、法華経を書写するのがいいと思うわけよ。法華経を書写し奉るによって勧進す。一銭半紙奉財の輩は云々とな」
男「書写するったぁてオメェ、ホンモノの法華経はおろか、明盲でなにするってぇんだ」
尼「いや確かによ、おらぁ明盲だよ。だけどよオメェ、考えてもみやがれ。日頃おれらに布施物くれるカモだって明盲だぜ。分かりゃぁしねぇさ」
男「ホンモノの坊主が来りゃどうする」
尼「何ぃ、ホンモノの坊主だぁ。ここらへんには、ホンモノの坊主といやぁ、あの龍門寺しかないじゃねぇかよ。しかも、龍門寺の大衆も、法華経は持ってねぇと聞く。分かるもんかい」
男「字はどうする」
尼「それにもおれに考えがある」
男「や、あの足音はなんだ」
その時、尼の住む破れ寺に、また一人のカモ、もとい信者がやってきた。尼は男を急ぎ隠して、常のごとく、いかにも清浄の体にもてなし、お題目を唱え、布施物を得るのであった。
ともかく、尼と男は、法華経を書写すると偽って、布施物を得るために、さっそく行動した。まず、これまでに集めた布施物によって、いかにも小綺麗な小屋を建てた。そして人を集めた。
「さあさ、これなるは法華経を書写するがための清浄なる小屋にてござい。あれなるは、能く書を書く人なり」
その時、破れ寺から、例の男が極めて不満そうな顔をして出てきた。
「言うまでもなく、オレは能く書を書く者である。ここの尼は金を持っとらん。これっぱかしのはした金では、書写などはできんな」
というなり、男は懐から、かなりずっしりと金の入っていそうな袋を取り出して、地面に放り投げた。そして、驚く尼と信者を前に、足早のその場を過ぎ去ろうとした。尼は慌てたふりをしてこれを呼び止めて曰く、
「まあま、そう言いなさるな。ほれ、ここに倍するだけの金がある。有り金全部だ。これでどうか書いてくれ」
と、倍する大きさの袋を、懐から取り出して男に与えた。男はこれをみて、まだ不満そうな顔をしていたが、道を引き返して、小屋の前に来た。
男は小屋に入る前に、まず沐浴し、香を焚いて身をいぶし、しかる後に小屋に入っていった。書写するところを見ようと、続けて中に入ろうとする信者は、尼が遮って罵った。「不浄の身で法華経を書写し奉る神聖なる家に入るべからず」と。
小屋の壁には、なぜか一本の竹筒が通してあり、そこから、盛んに空気が漏れていた。尼はこれを解説して、
「ありがたい法華経に不浄の息をかけるを憚るが故に、かくはするぞ」
と言った。信者たちは、これを見て感心し、争って布施物を喜捨した。
さて、そうして多くの布施物を得た上で、法華経の書写は「完了」した。書き上げた法華経は、いかにもありがたそうな箱の中に入っているので、信者たちは、実際に写経された法華経を見ることはなかった。その後も、布施物は多く集まり、尼と男は、儲かって儲かって笑いが止まらなかったという。
さて、この事を聞いた龍門寺では、是非ともこの法華経を借りて、大衆のために講釈を開きたいと考えた。そこで、尼のもとへ使いを出して、法華経を借り受けようとした。
もとより法華経のあるはずがない。尼の方では、なんとか理由をつけて断ろうとしたが、とうとう断り切れず、貸すことになってしまった。しかし、ずる賢い尼は、ここでも一計を案じた。
尼は、法華経を借りようとする使いを先に返し、自分で法華経を持っていく事にさせた。尼から箱に入った法華経を受け取った龍門寺の僧は、さっそく開いて読もうとした。ところが何としたことか、箱の中には、黄ばんだ紙があるばかりで、どこにも文字が見当たらない。不思議に思って尼に告げたところ、尼は、
「わりゃ大事な法華経をどうした。だからこそ貸し申さずというたであろうに」
と嘆くことしきり。ついに、龍門寺の僧は信心が足りぬということで、評判はガタ落ちとなった。
ちなみに、尼はその後、食を断ち、経文に香を焚いて祈ったところ、見事に経文の文字が復活したという宣伝して、さらに布施物を得たそうな。
今昔物語、巻第七、震旦河東尼、讀誦法花経改持経文語第十八を読んで、心に浮かんだことを書いてみた。
const_castで消しされないconstが存在する。関数へのポインターにおける関数の型や、メンバー関数へのポインターにおけるメンバー関数の型だ。
void f(int const *) {}
struct C
{
void f() const {}
} ;
int main()
{
// これが普通
void (*ok_1)(int const *) = &f ;
// ill-formed.
// 関数の仮引数のconstを消そうとしている
void (*error_1)(int *) = const_cast<void (*)(int *)>(&f) ;
// これが普通
void (C::*ok_2)() const = &C::f ;
// ill-formd.
// メンバー関数のconstを消そうとしている
void (C::*ok_2)() = const_cast<void (C::*ok_2)()>(&C::f) ;
}
こんなconstが消せてたまるか。
「zipでくれ」で有名な、一条三位についてググッたところ、ニコニコ動画の動画を発見した。ニコニコ動画か。久しく観ていない。久しぶりにログインして、さっそく観ようとしたところ、再生が始まる前に、全く関係の無いワケの分からないキモいキンキン声が流れてきた。あまりにも聞くに絶えぬキモい声だったので、すぐさまタブを閉じた。広告ではなかったようだが、一体何であんなものがあるのだろう。せっかく動画が見たかったのに、残念だ。
たしか以前、「ニコニコ動画を観ようとしたら、あまりにもごちゃごちゃしていて怖かったのでタブを閉じた」などという文章を、どこかのブログで読んだ気がする。「ユーザーをしてタブを閉じさせるような怖いページは、何かが根本的に間違ってるだろ」という疑問を投げて結んでいたが、なるほど、確かにこれはタブを閉じて当たり前だ。あまりにもひどすぎる。
どうも最近の日本のWebには、心ひかれるものがない。
今昔物語、震旦の巻を読み進めているが、なかなか面白い。
今昔物語は、独自の創作がほとんど見られない文章である。そのため、内容は、原典の影響を強く受ける。
まず、震旦の話には、布施による功徳という話がない。天竺には、米のとぎ汁の腐ったのを羅漢に施しただけで、将来二十劫にわたって三悪道に落ちるということなく、天上、人間に生まれて苦を受けずなどという話が、実に多い。ところが、震旦には、そういう話がない。これはつまり、中国には喜捨の文化が伝わらなかったということだろうか。
では、震旦でご利益があるのはなにかというと、主に写経である。それも、漢訳せられた経典の写経である。時には、写経しようという願を起こしただけで、利益を得ている。その利益というのも、やたらに現世の利益である。大抵は、ある者が突然死んだが、写経の功徳によって、生き返って命を延べたというものである。いかにも付け足したように、渡来は忉利天に生まれて云々ということが、最後の方に述べられることもあるが、やはり、生き返ったという話が非常に多い。
今昔物語の特徴に、笑えるような間違いが多いということがある。いくつもあるが、一番傑作だったのは、巻第六、第卅八である。
この話の元ネタは、三宝感応要略録巻中20らしいのだが、原典には、「会稽山陰縣有一書生」とある。今昔物語は、「会稽山の陰縣に一人の書生有りけり」としている。あの会稽の恥とか臥薪嘗胆という言葉で有名な会稽山の話だろうか。実は、これは間違いである。会稽山のあたりに、陰縣などという場所はない。実はこれは、会稽群の山陰縣の話であり、今の江蘇省の蘇州市市轄区の呉中区と相城区あたりを指す地名である。ここは、つい先日まで呉県という名前だったのだが、2000年12月に区画が変更されて、変わってしまったらしい。
ちなみに、会稽山とは、浙江省紹興市にある山である。
このように、非常に人間臭い、笑える間違いが多い。まあ、会稽山陰縣などと書かれていたら、ついうっかり間違えてしまいそうだが。
兼好法師が、「家の作りようは夏を旨とすべし」と書きたるもさることぞかし。京都の夏はひどすぎる。
何がひどいかと言って、湿気だ。まるでサウナだ。もはや、湿度というより、湯気といってもいいレベルだ。しかも、今住んでいる家がマンションの真ん中の部屋で上下左右に部屋があるので、風の通り道がない。冬は温かいが、夏は最悪だ。
京都が東京より優れている点はいくつかある。まず、アホみたいに複雑な路線図ではない。電車はすし詰めにならない。
なんだか、京都に引っ越してきてから、毎年同じことを書いているような気がする。とにかく、京都の夏は地獄だ。
5.2.4 Pseudo destructor call [expr.pseudo] paragraph 2
The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar type is the object type.
ハァ？ 何度読み返しても文章の意味が分からない。仕方がないので調べたところ、Active Issue 555が見つかった。
C++ Standard Core Language Active Issues 555
なるほど、おそらく、shallは、「でなければならない」ではなく、「である場合」程度の意味なのだろう。ということは、この文面は、こんな意味ではなかろうか
「operator .の左辺がscalar typeである場合、operator ->の左辺がscalar typeである場合、そのscalar typeをobject typeとする。」
どういう意味かというと、以下のようなコードで、
template < typename T >
void f()
{
T x ;
x.~T() ;
}
もし、template parameter Tがscalar typeだった場合（例えばint型とか）でも、擬似デストラクター呼び出しができるということを規定しているのだろう。
恐ろしく分かりにくい。また、Avtive issueでは、さらにひどい問題を提起している。しかし、こんなのはFCD前に直しておくべきことだと思うのだが。
追記：どうも、shallには、plan to, intend to, or expect toという意味があるようだ。それを考えると、仮定として使うのも、ありえるのか。のか？
本気を出してC++を書こうとすると、必ずVCやgccのバグにぶち当たる。どうにかならないものか。
オレに
ださせてくれよ
…本気を「ドラゴンボール、其之五百五、挑発するベジット」より
プログラミング言語の教育ではよくあること - マイペースなプログラミング日記
悲惨な現実だ。
本の虫: VS2010 RCが恐ろしく単純なコードでクラッシュする件
今ふと思い出して試したら、このバグが治っていなかった。よくソフトウェア巨人は、こんなバグだらけの製品を出荷できたものだ。
以下のコードはill-formedである。
struct C { } ;
int main( )
{
struct C() ; // ill-formed.
C() ; // OK
}
なぜならば、Explicit type conversion (functional notation)には、simple-type-specifierかtypename-specifierしか許可されていないからだ。普通のキャストのように、type-idを使うことは出来ない。
しかるに、VC10では、このコードをコンパイルできる。こういう些細なバグのひとつひとつが、移植できないコードを増やすというのに。
とはいえ、このコードは、コンパイルできてもいいのではないかとも思う。まあ、typedefするとか、static_castした方が、分かりやすいのだが。
Chromium Blog: Bringing improved PDF support to Google Chrome
最新Dev版に搭載されている。デフォルトでは無効にされているので、chrome://plugins/から有効にしなければならない。
非常に簡易なので、ブックマークやリンクなどが動かない。ただし、動作は非常に軽い。
これは、新しいプラグイン用APIの利用もかねているそうだ。
C++ Templatesの、最も優れているのは、Chapter 9、Names in Templatesである。C++におけるnameを、余す所無く解説している。何しろ、コア言語のDavid vandevoordeと、ライブラリのNicolai Josuttis共著なのだ。
何度読み返しても、これは勝てない。
ここ数年は、英語は感覚に頼って理解している。とはいえ、やはり感覚だけではまだまだ不十分だ。今週、意味を調べた英単語がふたつある。
Ph.D.は、博士号を意味する。意味は分かっていたが、今まで、何の略なのか考えたことがなかった。
これは、Doctor of Philosophyの略である。しかし、なぜ哲学なのか。英語圏で昔、学位といえば、神学、法学、医学、哲学しかなかった。そして、神学、法学、医学に属しない学問は、すべて哲学に分類されていた。そのため、数学とか物理学などの博士号は、今でも慣習的に、哲学博士と呼ばれているらしい。
ふとした理由で、castの過去分詞を使った英文を書く必要があった。はて、私の感覚では、castedなどという活用は、違和感を覚える。これは畢竟、そのような活用を見聞きしたことがないからに違いない。ということは、castは不規則動詞であるはずだ。しかし、どうも過去形や過去分詞形が思い出せない。
仕方がないので調べたところ、castは、変化しない不規則動詞であった。しかし、調べると、変化しない不規則動詞は、結構ある。しかも、日常会話で絶対に欠かすことのできない動詞ばかりである。よくもまあ、今まで知らずにおれたものだ。あるいは、あまりにも一般的すぎる動詞なので、逆に気がつかなかったのか。
真面目に英文法を学んでいないとこうなる。がしかし、私はどうも、文法で自然言語を学ぶのは苦手だ。
void f() {}
typedef void (&&rref_type)(void) ;
// error C2440
rref_type rref = static_cast<rref_type>(f) ;
これは、VC10がstatic_castのオペランドに、function-to-pointer conversionを適用しているためである。なぜかというと、VC10はこの場合に、5.2.9 Static cast [expr.static.cast] paragraph 8を適用しているためである。
しかし、実際には、この場合、5.2.9 Static cast [expr.static.cast] paragraph 3が適用されるべきである。
規格より、「関数型のrvalue referenceを返す関数の結果は、lvalueである」
そうか。では早速作ってみよう。
void f() {}
using rref_type = void (&&)( void ) ;
rref_type return_rvalue_reference_to_function( void )
{
return static_cast<rref_type>(f) ;
}
たぶん、これが関数型へのrvalue referenceを返す関数である。まてよ、「関数型のrvalue referenceを返す関数の結果は、lvalueである」とすると、std::moveすら、lvalueを返すことになるのだろうか。つまりそれは、
int main()
{
rref_type ref1 = return_rvalue_reference_to_function() ; // ill-formed.
rref_type ref2 = std::move(f) ; // ill-formed.
rref_type ref3 = static_cast<rref_type>(f) ; // OK
}
んー？ なぜこんな制限があるのだろう。もう少し考えてみなければ。
追記：見事に解釈が間違っていた。原文は、"A function call is an lvalue if..."となっている。関数呼び出しがlvalueなのであって、関数の結果ではない
これは、通常の関数呼び出しが、関数型へのlvalueか、関数ポインターしか受け付けないということへの対処である。関数型へのrvalueリファレンスであっても、lvalueとして解釈されるということだ。
Togetter - まとめ「はやぶさを巡る報道とJAXAの広報に対して笹本祐一さんがコメント」
当時の総理大臣が新聞記者に「はやぶさのイトカワ着陸について」質問されたら「え？なんの話」なんてことがあって、責任追及を恐れた補佐官が情報は先に内閣府に上げてから広報、なんて指示出しをしたそうな。的川先生「ＸＸ補佐官の方針で広報出来ませんって言うことになります」ってやったって。
その昔、堀江青年の太平洋単独ヨット横断を、日本の報道は正式な出国許可をとっていないことを理由に非難した。到着先のサンフランシスコ市長から名誉市民に迎えられてから手のひら返して称賛したって前歴がある。つまり、マスコミは今も昔も成し遂げられた偉業の価値を自分では判断出来ない。
それを日本の技術の変態力って持ち上げて喜んでるのも今の風潮。@ yshimoyama @sasamotoU1 必死の思いでどうにかすると「やればできるじゃん、次はもっと安くな」ってなるんだよね。
夜寝る前に読んでいた今昔物語、ようやく、巻第一から巻第五まで読み終わった。この部分は、天竺の仏教に関する説話集である。
今昔物語は、色々と興味深い。説話は、ほとんどすべて、「今は昔・・・」ではじまり、「・・・となむ語り伝えられたるとや」で終わる。天竺部分では、一箇所だけ、とという形に持っていくことが出来ず、「かくなむ語り伝えられたるとや」という形で終わっている部分があるが、些細な違いである。
成立は、まあ1120年以降、源平のことは書かれていないので、まあ、まだ源平のことを昔とは呼べなかった時代であろう。作者は、まあ、複数の坊主だろう。柳田國男などは、当時の琵琶法師や歌比丘尼のネタ帳として作られたのではあるまいかなどと書き残している。
今昔物語の文章は、驚くほど簡単である。なるほど、芥川龍之介が今昔物語に凝ったわけも分かる。というより、芥川龍之介の文章は、かなり今昔物語の影響を受けている。面白いのは、どうも不思議な言葉、この今昔物語にしか見つからないような言葉も、結構目に付くということだ。補注には、文章上の記録は残っていないが、日本語の音声の変化を考えると、変化の途中にこのような言葉があったのではないかなどと、考察している。
しかし思うのは、漢字かな混じりの文学は、平安末期に一度だけ起こり、その後、明治になるまで停滞していた感がある。なぜだろうか。平安末期に、漢字かな混じり文学が一気に現れたのは、まあ、漢字という外来の文字を取り入れて、自分のものにするまで、五百年はかかったのではないかという意見を、どこかの物の本で読んだことがある。武士の世になって、ただでさえ怪しくなっていた変体漢文が、さらに奇妙なことになってきた。しかしどういうわけか、漢文もどきを捨てなかった。なぜそこで、漢字かな混じりの文章に移行しなかったのか。
まず始めに明言しておくと、lambda式でデータメンバーはキャプチャーできない。lambda式は、ローカル変数しかキャプチャできない。従って、このブログのタイトルは、すでに間違っている。ではなぜこんなタイトルなのか。それは。lambda式では、データメンバーを使うことが出来るからだ。これは、誤解されやすい。
struct C
{
int x ;
void f()
{
[=]{ return x ; } ;
}
} ;
これは、完璧にwell-formedなC++0xのコードである。ご覧のように、データメンバーが使える。「ほれ見ろ使えるじゃねぇか。するてぇと、データメンバーもキャプチャーできるに違ぇねぇ」と思われるかもしれない。しかし、データメンバーは、キャプチャーできない。
では、このlambda式は、何をキャプチャーしているのか。thisである。上の例は、以下のように書くこともできる。
struct C
{
int x ;
void f()
{
[this]{ return this->x ; } ;
}
} ;
thisは、必ずコピーキャプチャーしなければならない。最も、thisはポインターなので、参照キャプチャーしたとしても、あまり使い道はない。ともかく、デフォルトキャプチャーを指定したlambda式の中で、非staticなデータメンバーを使うと、自動的にthisがキャプチャーされる。これは、[&]でも、同様である。thisを介してのアクセスなので、データメンバーは、参照される。コピーはされない。thisは、必ずコピーキャプチャーされる。しかし、ご存知のように、thisはポインターなので、データメンバーは、リファレンスキャプチャーしたように振舞う。
これは、非常に危険である。皆、[=]は、コピーキャプチャーであり、クロージャーオブジェクトを保持しても安全だと考えている。確かに、コピーされる。何がコピーされるかというと、thisである。
struct C
{
int x ;
std::function< int (void) > f()
{
return [=]{ return x ; } ;
}
} ;
int main()
{
std::function< int (void) > f ;
{
C c ;
f = f.f() ;
}// cの寿命終了のお知らせ
f() ;// 実行時エラー、オブジェクトはすでに死んでいる
}
このコードは、cの寿命が尽きた後に、クロージャーオブジェクトを呼び出しているので、実行時エラーになる。
これは、例外の少ない一番シンプルな設計である。この設計に嘘はない。lambda式は、基本的に、ローカル変数しかキャプチャーできない。データメンバーはキャプチャーできない。ただし、thisは特別にキャプチャーできる。したがって、データメンバーは、常に参照でアクセスされる。
では、thisではなく、どうしてもデータメンバー自体をキャプチャーしたい場合はどうするのか。これは、明示的にローカル変数を作ってやるしかない。
struct C
{
int x ;
void f()
{
auto x = this->x ;
[=]{ x ; } ;
}
} ;
もちろん、紛らわしければ、別の名前にしてもいい。
冷戦時代、米ソは盛んに宇宙開発を競争しあった。その目的には、国威高揚的なものがだいぶあったとされている。私は、常々これに疑問であった。果たして、宇宙開発が国威高揚になり得るだろうか。
私はアポロ11号が、人類史上初の月面着陸を成功させた時には、まだ生まれてすらいなかった。そのため、当時の様子は分からない。
しかし、スターダストがヴィルト第2彗星の塵を持ち帰ったとき、別に感動はしなかった。日本のかぐやが月面を無意味に高画質な可視光で撮影したときも、まったくもって感動しなかった。
しかし、2007年にはやぶさがイトカワに接近したときは興奮したし、今回も、リアルタイムでUstreamやその他の情報を確認していた。なるほど、確かに国威高揚の効果はあるらしい。
昔、日本の愛国心教育をどうするかなどという話があったが、第二の幼学綱要を作るよりは、宇宙開発に金を出したほうがいいのではないかと思う。
とはいえ、国威高揚の著しい例は、今回のはやぶさや、アポロ13号のように、アクシデントだらけの中、なんとかやり遂げたというものばかりである。あまり、研究上の利点はない。
第一、最も優れた国威高揚手段は、戦争なのだから。
ちなみに、幼学綱要というのは、当時のコピペ学者である元田永孚によって編纂された、うさん臭い小説である。
以下のコードが通らない。
int main()
{
int x = 0 ;
[x] {
x ;
[x]{
x ;
} ;
} ;
}
でも、以下のコードは通る。
int main()
{
int x ;
[x] {
x ;
[=]{
x ;
} ;
} ;
}
訳がわからない。VC10はこんな不完全な形でlambdaを実装したまま、製品を出荷すべきではなかった。
宇宙作家クラブ ニュース掲示板
はやぶさ中継 on USTREAM: はやぶさ帰還に際して、管制室からのライブ中継. Science
Hayabusa back to the earth (approx. 22:30JST) on USTREAM: 2010/6/13に地球に帰還する小惑星探査機「はやぶさ」をオーストラリアから生中継します。
投稿日 2010年6月13日(日)19時53分 投稿者 柴田孔明
管制室に拍手が起こりました。恐らく分離したものと思われます。
信号は確認済み！投稿日 2010年6月13日(日)20時22分 投稿者 柴田孔明
カプセルの分離を機体の姿勢とドップラーで確認！投稿日 2010年6月13日(日)21時54分 投稿者 柴田孔明
はやぶさは大きく姿勢を変えて、底面にあるカメラで地球を撮ろうとしている。
カメラを地球に向ける必要があるが、まだ姿勢制御が終わっていない。
残り１時間で出来るか不明。
補足：リアクションホイールとキセノンのジェットで姿勢制御をしている。投稿日 2010年6月13日(日)22時28分 投稿者 柴田孔明
はやぶさは地球に近づいている。
地球の影に入ると電力発生ができない。
こうなると何も出来なくなる。
それが２２時４５分。
尚、２２時３５分までは内之浦で通信。
そのあとはＤＳＮを使う。投稿日 2010年6月13日(日)22時30分 投稿者 柴田孔明
管制室で拍手。はやぶさのデータを最後まで受信し終わりました。投稿日 2010年6月13日(日)22時40分 投稿者 柴田孔明
22時28分30秒にはやぶさの電波受信完了。投稿日 2010年6月13日(日)22時52分 投稿者 柴田孔明
撮れなかったと発表されていた写真撮影が１枚成功していたと訂正発表がありました。途中で通信が切れたそうです。地球が写っているそうです。
2230に管制室に拍手が起こって人が集まってきた。写真が取れたのだろうか。
それにしても、この中継がリアルタイムで見られないとは、テレビは貧弱なものだ。
361 名前：名無しさん＠十周年[sage] 投稿日：2010/06/13(日) 22:31:11.05 ID:rk5wR6AP0 [1/2]
ニコ生 見る価値ないぞ。
擬人化コスプレ女が出てきてはやぶさ擬人化萌えグッズ紹介とかやってて吐き気する。
管制室の中継見てたほうがいい。
まあ、ニコニコ動画もクソだが。なぜ日本人が作ると、ああなってしまうのだろうか。
カプセルからのビーコンを受信したそうだ。
最後の地球撮影
地上に投下したカプセルを発見。
lambda式の全機能を網羅するのが大変だ。lambdaのある箇所を解説するためには、他のあらゆる詳細を知っていなければならない。
結局、lambda式の解説は、基本編と、その穴を埋める詳細編に分けることにした。
ところで、lambda式だが、当初、「lambda式」という表記でいくはずだったのだが、ラムダの方が良いという意見が出てきた。ラムダ計算といえば非常に有名で、ラムダという単語は、一般的である。英語表記は分かりにくいということであった。やはりそういうものか。
また、lambda式を、今の形からさらに変えようという動きもでている始末。もうFCDが出たので、これ以降は、間違いの修正だけで、大幅な変更はないと期待していたのに。どうなることやら。
我々はだいぶ前に、プログラミング雑誌を創刊すると発表した。その後、なかなか音沙汰がない。一体どうなっているのか。まだ色々と確定していないこともあるのだが、少しばかり内情をリークしておく。私は直接にロングゲート社には関わっていないので、本人からきいた話なのだが。
実は、我々はまだ色々と作業をしている。記事の間違いや誤字脱字の修正などだ。
雑誌は、上記のサイトから、購入できるようになる予定である。値段は、書いてあるように、物理的な書籍が1500円（プラス送料）、PDF版が1000円になる予定である。この価格は、まず変わらないだろうと思う。物理的な書籍は、あらかじめ予約を受け付けてから印刷、発送となるので、予約から発送して、手元に届くまでまで、だいぶ時間がかかると思われる。
では、いつ購入できるのか。これは、まだ何とも言いがたい。アキラさんの言によれば、最低でも6月末にはなるのではないかという話だ。このサイトは、DigitalGhostさんが構築した。話によると、もうサイト自体の構築は、ほぼ終わっているらしい。ただし、まだ雑誌自体に、色々と作業が必要なので、販売はもう少し時間がかかるそうだ。
私は、創刊号に、記事を二つ書いている。Bjarne Stroustrupへのインタビューと、C++の歴史だ。
Bjarne Stroustrupへのインタビューは、おそらく、この雑誌最高の記事であるはずだ。実は、雑誌第二号では、これまたC++界で非常に重要な、確実にC++史に名を残すであろう有名人へのインタビューを予定している。
C++の歴史は、D&E以降の歴史的経緯について記述した。テンプレートの実装方法の変遷、exportにまつわる話、STLが規格に採用されるまでのドラマチックな出来事、EC++という黒歴史。
ちなみに、今私が執筆中のC++0x本は、ようやくExpressionまで進んだ。ただし、Basic Conceptsは、今後もドラフトが変わる可能性があるので、半分ぐらい書いて寝かせている。NBコメント後のドラフトがでたら、内容を検証しなければならない。そろそろレビューのMLに流したいところだが・・・
いよいよlambda式だ。
DPI(Dot per inch)といい、PPI(Pixel per inch)といい、同じ意味である。本来、DPIは印刷に対して用いられ、PPIは、ディスプレイに対して用いられるのだが、本質的に意味するところは同じである。
印刷やディスプレイの表示は、細かな点をもって表している。この点が細ければ細かいほど、人間の目には、自然に見える。しかし、あまりに細かすぎるのは、コストがかかるし、また現代の技術では難しいということもある。
今日、日本において、紙への印刷は、最低でも数百DPIはある。漢字を表現するには、ある程度の細かさが必要なのだ。
ところが、ディスプレイは、いまだに、紙の質に達していない。デスクトップに使われるディスプレイは、通常96PPI、高くても、120PPI程度が関の山である。携帯電話などの小さいディスプレイは、200から300PPIのディスプレイを備えるものもある。しかし、これは、ディスプレイが小さいから実現できるのである。デスクトップに使われる大きさのディスプレイで、200PPIなどというものは、現状では、一般に普及してはいない。コストと技術の両方の問題があるのだろう。
ディスプレイが高PPIになるのは、望ましいことである。しかし、ここに互換性という問題が立ちはだかる。
今、ほとんどのソフトウェアは、ディスプレイのPPIが、それほど高くないことを前提に書かれている。現代の多くのソフトウェアは、何らかの図画を描画する必要がある。最もよく描画される図画とは、文字である。
アウトラインフォントがどうの。それを実際のピクセルに落とす処理がどうのということは、省略する。それは、この問題に、あまり重要ではない。
文字を描画する際には、どのくらいの大きさで、その文字を描画するかということが、問題になってくる。大きさを指定するには、単位が必要である。現在、最も用いられている単位は何か。ピクセルである。
たとえば、この文字列は、20ピクセルの大きさで描画されている。これは、現代の多くの環境で、普通に読める大きさであると思われる。
しかし、この文字列は、10ピクセルの大きさで描画されている。視力とディスプレイなどの環境にも夜が、一般に言って、日本語の文字を、たったの10ピクセルで描画するのは、あまり読みにくいとは言えない。
この文字列は、たったの8ピクセルの大きさである。これは、多くの環境で、読みづらい文字であろう。
一体、何が問題だというのか。今、私は、96PPIのディスプレイを使って、この文章を書いている。ということは、この文字列の大きさの感覚、つまり読みやすい読みづらいというのは、96PPIにとっての、感覚である。今もし、PPIが10倍のディスプレイを使ったとして、ブラウザが、愚直に指定されたピクセル数の大きさで、文字を描画した場合、どうなるであろうか。
文字の物理的な大きさは、十分の一になってしまう。もちろん、ピクセル数は変わらないので、「細かさ」は同じだが、おそらく、相当に読みづらい極小文字になってしまうだろう。
クライアントのアプリケーションにとって、この問題は、Webサイト以上に深刻である。たとえば、MSのWindowsはどうなっているだろうか。
WindowsのGDIでは、DPI（MSは公式にDPIという用語を用いているので、この言葉を使う）の対応は、プログラマ側に任されていた。プログラマは、MSDN LibraryのCreateFontの説明にあるように、自前でDPIにあわせてスケールするよう期待されていた。しかし、そんな面倒なことは、誰もやろうとしなかった。それ故、MSは、Vista以降で、特別なはからいを提供した。もし、システムのDPIが、標準（96DPI）以外に設定されていた場合、Windowsは、あたかも96DPIであるかのように描画して、描画結果を、スケールして表示する。高DPIに対応していて、この「粋なはからい」をしてほしくないアプリにためには、この挙動を止めるためのAPIが存在する。
DirectGraphicは、96DPI固定である。これは、OSの実装の方で、実際のDPIにあわせてスケールされる。
では、Webの場合はどうなるのか。ブラウザがどう実装するのか。厳格に考えれば、CSSなどで、文字のサイズをピクセル数で指定している場合は、その大きさで描画すべきである。そもそも、ピクセル数を指定しているのだから、DPIがどうなどということは、関係がない・・・はずである。
とはいえ、現状で、多くのサイトは、96PPIないしは、百数十程度の低PPIのディスプレイで表示されることを、アテにしている。愚直にピクセル数の指定を守ると、現状のほとんどのサイトが、悲惨なことになる。
ちなみに、プリンターは、一足早く、この問題に直面している。今のPC用のプリンターは、どんなに安い製品でも、600DPIとか1000DPIなどといった、相当な高DPIでの印刷ができる。これは、Webページを印刷する際、非常に問題となる。
確か、W3CのCSSの規格では、この現状を踏まえて、印刷の際のレイアウトは、96DPIを前提にするような推奨の文面が存在したはずだ。
言うまでもなく、私は未来の技術の進歩を信じている。私が生きている間に、600PPIとか1000PPIで24インチぐらいあるPC用ディスプレイが、安価で発売されるであろうことを信じている。そのような未来において、既存のWebサイトはどうなるのだろうか。
しかし、どうも最近、コンピューターの性能の進歩に、勢いがないように思う。CPUの周波数は、何か画期的な技術が発明されない限り、もはや頭打ちである。マルチコアといっても、通常のアプリケーション処理は、何十にも分割して並列実行するのが難しい。SDRAMの速度向上というのも、あまり実感できない。GPUは、電子レンジ並の消費電力になろうとしている。唯一、HDDだけが、SSDの登場によって、一気に別物になった。
Blogger Template Designer - Blogger Help
Blogger Template Designer is a new way for you to easily customize the look of your blog. You can select a variety of templates, images, colors, and column layouts to make your blog an expression of you.
選択肢は非常に少なく、バラエティなどというものを感じ取ることはできなかった。
だいたい、なぜ今時、レイアウトの幅をピクセル数決め打ちなんだ。アホか。私は、96PPIのディスプレイを使っている。もし将来、960PPIのディスプレイが実用化されたとすると、ピクセル数指定のレイアウトは、皆、現在の十分の一の大きさで表示されることだろう。相当見づらいに違いない。
いやしくもWebの未来を信ずる者であれば、レイアウトをピクセル数で指定してはいけない。ブラウザの表示幅に対する%で指定すべきである。もちろん、無駄な余白を設けるべきではない。画面をめいっぱい使うべきである。だいたい、最大で横幅を1000ピクセルしか指定できないというのは、どういう事だ。私のディスプレイの横幅は、1920ピクセルであり、Bloggerの自動デザインでは、920ピクセルあまる。つまり、左右に460ピクセルづつ、マヌケな余白が表示されることになる。アホか。そのスペースは無駄だ。
あまりに長い横幅は、テキストが読みづらいという意見もあるかもしれない。しかし、その場合、閲覧者はいつでも、自分のブラウザのウインドウのサイズを調整できるではないか。
Bloggerの新しいテンプレデザイナーはクソだ。
さて、さしあたりどうするか。このブログは、だいぶやっつけ仕事でテンプレートをいじっており、コードがだいぶ汚い。いずれ、スクラッチからデザインし直さなければならないだろう。しかし、それには数日を要するので、今は気乗りがしない。
C++のlocaleについて、本気を出して規格を読んだ。これはクソだ。
暗号のような名前、無意味に多いクラスとメンバー。規格の文面も非常に読みにくい。当時、これを設計した人間は、文字に対する理解の乏しい、テンプレートの理解出来ない、オブジェクト指向（笑）脳の権化に違いない。
そして、結局こんな膨大で複雑なクラス群で何が出来るかというと、22.3.3 Convenience interfaces [locale.convenience]に記述されている、「便利なインターフェース」だけしかできぬのである。
すなわち、isspace, isprint, iscntrl, isupper, islower, isalpha, isdigit, ispunct, isxdigit, isalnum, isgraphの分類と、文字コードの変換である。
私の見たところでは、文字コードの変換は、設計がまずいので、まともに使うことは出来ない。連中は、文字型は、charのみであるという前提で設計している。テンプレートを使いながら、ジェネリックではない。charこそが正義であり、正統な文字型たる資格を有する。wchar_tその他の実装依存の型、あるいはユーザー定義の型は、根本的に邪道であり、異質であり、野蛮で未開な土人の文字のために仕方がなく用意されている異教徒の型であるという思想がありありと見える。これでは何のために、charTというテンプレートパラメーターがあるのかわからない。
ここまでひどいとは思わなかった。結局、当時はcharとwchar_tしかなく、今以て多くの南蛮人のC++プログラマは、wchar_tはマイクロソフトの独自拡張だと思っているフシがあるので、しかたがないのだろう。
理想的には、localeは設計しなおすべきである。
LLVM Project Blog: New "lldb" Debugger
まあ、当然だ。いくらコンパイラが優れていても、今時デバッガなしでは、使いものにならない。
C++0xのPODの定義をまとめてみた。ただし、C++0xでは、memcpyでコピーして、各データメンバーの状態が保証されるためには、、trivially copyable classであればいい。
PODは、trivial classかつstandard-layout classであること。
さらに、非PODな非staticデータメンバーを持たないこと。
trivially copyable class
ユーザー定義のコピー、ムーブのコンストラクタと代入演算子がないこと。
デストラクタがtrivialであること。
trivial class
trivially copyable classに加えて、コンストラクタもtrivialであること。
trivialであるということは、ユーザー定義ではないことと、delete化（C++0xの新しい機能）されていないこと。
コピー、ムーブコンストラクタがtrivialであるためには、仮想関数や仮想基本クラスを持たないという条件も必要になる。
standard-layout class
standard-layout classではない非staticなデータメンバーを持たないこと。
仮想関数、仮想基本クラスがないこと。
非staticなデータメンバーは、同じアクセス指定であること。
standard-layout classではないクラスを継承していないこと。
継承をしている場合、一番上の派生クラスは非staticなデータメンバーを持たず、基本クラスのどれかひとつだけが、非staticなデータメンバーを持つこと。
非staticなデータメンバーを持つ同じクラスを、複数継承しないこと。
最後の継承に関する例。
struct Base { int x ; } ;
struct POD : Base {} ;
struct NonPOD : Base { int x ; } ;
PODとなるためには、一番上の派生クラスは、非staticなデータメンバーを持っていてはならない。
実際、これまでPODに拘る理由というのは、memcpyなどで単純なバイト列のコピー出来るかどうかである。これは、C++0xでは、trivially copyable classであれば保証される。
つまり、memcpyでコピー出来るクラスの制限は、だいぶ緩和される。まず、コンストラクタがあってもいいし、継承していてもいい。standard-layout classである必要はない。派生クラスと基本クラスが、共に非staticなデータメンバーをもっていても構わない。アクセス指定もできる。
たまに、Monty Pythonを観返したくなる。さて、Monty Pythonのスケッチに、Famous deaths（有名な死に様）というものがある。
John Cleeseの扮する、世界で最も似ていないであろうモーツアルトの次のスケッチだ。
なぜか、エドワード七世だけ、異様に得点が低い。それがオチとなっているのだが、なぜエドワード七世なのだろうか。単なる王室ジョークであり、帝位についた故人ならば、誰でも良かったのだろうか。
Youtubeのコメントでは、エドワード七世はトイレの中で死んだので、このジョークがあるというコメントがある。果たしてそうだろうか。エドワード七世がトイレの中で死んだかどうか、確認できない。
そもそも、このスケッチでの高得点の死に様とは、皆、突発的な死である。では、エドワード七世はどうか。
Wikipediaのエドワード七世の項目によると、エドワード七世はヘビースモーカーであり、一日に20本のタバコと、12本の葉巻を吸っていたそうである。そのため、常に気管支炎を患っていたそうだ。つまり、エドワード七世は、何年もかかってじわじわと体調を悪くしていったと言える。だから得点が低いのだろうか。
私は、C++0xのすべてに賛同しているわけではない。むしろ逆に、不満は多い。オレの欲しかったこの機能がないという不満ではない。こんな機能いらないだろという不満である。
ユーザー定義リテラル
ユーザー定義リテラルは、無駄である。識別子はかならずアンダースコアから始まらなければならない。これは、とても危険だ。なぜ、予約語の制限を無視できるかというと、ユーザー定義リテラルの識別子は、エンティティではない。すなわち、名前ではないからだ。名前ではないゆえに、予約語の制限にはあてはまらない。
ましてや、ユーザー定義リテラルを、名前空間の中に入れることができないというのは、致命的だ。もちろん、名前空間の中でも定義できるが、おそらく、実用にならないだろう。
それに、ユーザー定義リテラルでなければできないことというものがない。では、単なるシンタックスシュガーか。
// ユーザー定義リテラル
auto x = "hogehoge"_hoge ;
// 関数
auto y = hoge("hogehoge") ;
// クラスへのキャスト
auto z = hoge("hogehoge") ;
この砂糖は、果たして既存のクラスやキャストより甘いのであろうか。関数やキャストで十分ではないか。
これに対して、「おいおい江添、バカだなぁ。お前まだ、テンプレートメタプログラミングを知らないのか。ユーザー定義リテラルを使えば、整数の引数が、テンプレート実引数になるじゃないか」という意見がある。それは、承知している。連中の言い分はこうだ。
template < char ... args >
struct placeholder {} ;
template < char ... args >
placeholder< args... > operator "" _ (){ return placeholder< args... >() ; }
int main()
{
1_ ;// placeholder<'1'>
2_ ;// placeholder<'2'>
123_ ;// placeholder<'1', '2', '3'>
}
ご覧のように、リテラル演算子テンプレート（literal operator template）の場合、実引数ではなく、テンプレート実引数に、リテラルの文字列が、一文字づつ渡される。これをつかえば、std::bindに使われる、std::placeholders::_1のような、汚い実装は必要ないではないかということである。
しかし、本当にこんなコードを書きたいだろうか。私は御免だ。このコードを書くには、Variadic Templatesとユーザー定義リテラルに、相当精通していなければならない。そもそもこれは、ユーザー定義リテラル本来の用途ではない。たまたま、こういう事にも使えるというだけだ。メタプログラミングに使いたいのならば、最初からメタプログラミング目的の機能を設計すべきだ。
long long int
long long intは、C99から輸入したものである。C畑の連中の考えることは、たいていクソである。これも例外ではない。long long intは、明確に規定していないものの、limit.hの定義を考えれば、少なくとも64bit以上の整数である。
じゃあ、将来、128bit以上を保証する整数が欲しくなったらどうするのか。long long long intを付け加えるのだろうか。では256bitは如何。子供の考えた必殺技じゃあるまいし、バカバカしい。
初期化リスト
これまで、構造体や配列は、特別な初期化の文法を使うことが出来た。
int x[3] = {1, 2, 3} ;
初期化リストは、これを、ユーザー定義のクラスにも、使えるようにしたものだ。
std::vector<int> x = {1, 2, 3} ;
なるほど、確かに教科書の例文を書く際には、分かりやすい。多分、初心者受けもいいだろう。これは、一見して、良い機能に見える。
しかし、ソースコードにデータを直接記述して初期化するような決め打ちの泥臭い処理が、そんなに頻繁に使われるだろうか。配列や構造体は、コンパイル時に初期化の方法を伝えられるという利点がある。現実のCのコードでも、テーブルの構築などにも使われている。しかし、ユーザー定義のクラスは、そのような簡単な、ビットワイズな初期化をすることはできない。
もちろん、シンタックスシュガーは重要だ。しかし、現実には、ファイルを読み込むだとか入力を受け付けるなどしなければ、初期化ができない場合がある。これは、結局、実行時まで、初期化ができないことを意味する。
もちろん、初期化リストに使えるのは、リテラルだけではない。
void f( int x, int y, int z )
{
std::vector<int> x = {x, y, z} ;
}
しかし、要素数も、実行時に得られる情報に依存しているならば、結局、初期化リストを使うことはできない。
std::vector<int> v ;
while( int value = get_runtime_input_somehow() )
{
v.push_back(value) ;
}
とはいっても、初期化リストは、まだそれなりに使い道はあるだろう。それほど便利ではないというだけの話だ。結局、C++の思想である、組み込み型とユーザー定義型を、完全に同じ文法で扱えるべきだという思いが、影響しているものと思われる。
std::bind
不要。lambdaを使うべき。
前回、ネタが分からないという指摘を受けたので、仕方なくネタを封印する。
ともかく、DPI(Deep packet inspection)の広告利用の是非について、専門用語を使わずに説明する。
日本には、多くの、行政による規制が存在する。例えば、殺人や窃盗は、規制されている。道徳とか一般常識などという、時代や国や人によって変わるものは、あまり信用できない。なぜ、日本で殺人や窃盗が犯罪になるかというと、結局、法律で規制されているからである。
公道で車を運転したり、危険な物質を取り扱ったりするには、特別な許可が必要である。この許可を得るためには、行政の試験を通過しなければならない。
日本では、実に多くの事が、法律で規制されている。我々が犯罪と呼ぶところのものは、この規制を破る行為のことである。
では、なぜ規制されているのか。それは、規制があったほうが、都合がいいと、法律制定当時、皆が考えたからである。当時、人が勝手に他人を殺すのは不利益だと考えたから規制した。他人の所有物を盗むのは不利益だと考えたから規制した。十分な技量を持たぬ者が公道を運転しては不利益だと考えたから規制した。
しかし、時代が進んでいくと、当時思いもしなかった事情がでてくる。公職選挙法の文面が書かれた時代、我々は、候補者が使えるビラの枚数を制限した。これは、今のように、インターネット上のビラ、つまりはWebサイトやメールなどが、ほとんどコストを掛けず、何回でも閲覧できるような時代ではなかったからである。当時、そんなことは、まったくの夢物語であった。
新しい技術や事情、道徳、一般常識がでてくると、それに対応して、規制を緩めたり、廃止したり、あるいは新たに規制を作る必要がある。つまりは、法の改正である。
日本の規制の中に、通信の秘密というものがある。
たとえば、手紙を送る途中で、郵便事業者が、その中身を盗み見たとしたら、どうであろうか。あるいは、電話をしている途中で、電話事業者が、会話内容を盗聴したとしたら、どうであろうか。
通信の秘密は、この盗み見る、検閲行為を規制する法律である。通常、プロバイダとかISPと呼ばれるインターネット事業者は、通信の内容を盗み見てはならない。
この通信の秘密という規制は、ほとんどの日本人の道徳と一般常識に照らし合わせると、当然この規制があるべきだという答えが返ってくるだろう。
今回問題になっている、DPIの広告利用とは、この、盗み見る、検閲行為を、広告利用に限り、許可しようというものだ。
Googleを始めとした、多くの企業がやっている事とは、何が違うのか。ある私企業の名前で説明するのは差し障りがあるかもしれないが、結局、Googleは分かりやすいので、Googleで説明する。たとえば、Googleで検索する場合、Googleは、検索ワードやその他の情報を、保存しているではないか、と指摘する人がいるかもしれない。Googleは、通信を中継する者ではない。Googleは、手紙の差出人であり、電話に出る人である。
今、Googleに手紙を送ったり、電話をかけたりした場合、Googleがその手紙を保管したり、電話の内容を録音するのは、規制されていない。通信の秘密とは、これを中継する郵便と電話の事業者が、途中で盗み見るのを禁止しているのである。
だから、Googleとの通信内容を、Yahooが知ることはないし、その逆もない。
では、DPIの広告利用が許可された場合、どうなるか。
今、Googleで猫の画像や動画を検索したとする。Googleは、猫の画像や動画を検索したことを覚えておいて、次回、Googleにアクセスしたとき、まだ何も検索しないうちから、猫の画像や動画をおすすめしてくるかもしれない。これは、問題ない。なぜなら、Googleは、「猫を検索してくれ」と書いた手紙の差出人であるからだ。このことは、他の検索サイト、例えばYahooやBingは知らない。
しかし、DPIの広告利用が許されているので、インターネット事業者は、この一連の通信を、盗み見ている。いや、盗み見ているというと、語弊がある。なぜなら、DPIは規制されていないので、犯罪ではない。堂々と見ていると言った方がいい。
この後、YahooやBingにアクセスすると、「あなたは、以前Googleで猫の画像と動画を検索して、これとこれとあれを閲覧しましたね。実は、我社でも、猫の検索にかけては非常に優れています。チーズバーガーはお好きですか？ Googleよりもおすすめですよ」などと表示されるかもしれない。これはなぜか。インターネット事業者が、通信内容を見ていて、YahooやBingに、Googleで猫について検索したという情報を、売り飛ばしているからである。いや、売り飛ばすというと、語弊がある。なぜなら、このことは規制されていないのだから、犯罪ではない。堂々と販売しているのである。
これを是とするか否とするかは、その人の道徳や価値観、一般常識などといった、あまりアテにならない判断基準に基づいて決定される。しかし、一般に、通信内容が、第三者に知られるのは、好ましいとは言えない。通信内容を売り飛ばすインターネット事業者などと、契約したくはないと考える人が多いであろう。とすると、規制がなくても、顧客を失うことになるので、事業者は容易にDPIはできない。一体、なぜこの規制を緩めることが重要なのか。
我々の世界は、広告に溢れている。テレビを見ればCMが流れ、外に出れば看板だらけ。インターネットも、広告で溢れている。広告は、非常に重要なのである。Googleが、無料で検索やメール等のサービスを提供できるのも、主に広告で利益を上げているからである。
たとえば、DPIをするかわりに、月々のインターネットの接続料金が大幅に下がる。あるいは、無料になるとしたら、どうであろうか。DPIをする代わりに、携帯電話の料金が安くなったり、無料になったとしたら、どうであろうか。電話をかけ放題、使い放題、ダウンロードし放題、しかも無料となれば、DPIがあってもいいと考える消費者は、多いのではないか。
あるいは、インターネットや携帯電話の事業者は、広告の利益を利用して、大幅に設備投資をすることもできる。日本中、どこでも携帯電話がつながる。しかも速度が速い。これらは、技術力の向上によって改良することもできるが、やはり、金の力も大きい。結局のところ、基地局を建て、光ファイバーを電柱に取り付け、あるいは地中に埋め、通信を中継する機器を増設する。それらの設備を保守するための、人員も増やさなければならない。カネさえあればということも、世の中には実に多いのである。
しかし、通信の秘密という規制がある以上、たとえ消費者が望んでいたとしても、DPIを提供することはできない。ここで、DPIの広告利用を許可するかどうかという議論になっているのである。
もちろん、問題がないわけでもない。特に言うまでもなく、プライバシーの問題がある。例えば、
何年何月何日何時何分何秒から、3時間ほど、Googleでエロ動画を検索した。
などという情報が知られても構わないという人は、おそらく、そう多くはいないだろう。もちろん、公開しても構わないという人はいる。しかし、全員がそうとは限らない。あるいは、秘密にしておきたかった情報が、漏れてしまう恐れもある。
以上が、DPIの解説である。私の意見では、DPIをしてもよいという明示的な意思表示があって、初めてDPIを許可するべきだと思う。また、事業者としても、DPIによる相当な利点を提供しなければ、消費者の心を掴むことはできないだろう。
DPIの広告利用が許可された未来の世界を予想してみる。
携帯電話には、DPI許可ボタンが搭載されている。このボタンを押すと、DPIの許可、不許可が変更される。DPIが許可されている間は、通信料が極端に安くなるか、無料になる。
この仕組みでは、DPIされても構わない通信と、秘密にしておきたい通信を、簡単に使い分けることができる。現実的には、このようなハイブリッド型の運用になるのではないかと思う。
もちろん、最初から全ての通信をDPIする。変更方法は存在しないということを、契約時に明言しておいて、そのかわり、それに見合った何らかの利点を提供する事業者が現れることもありえる。それはそれで、お互いが納得して契約するのならば、いいのではないかと思う。
いずれにせよ、これらの話は、規制が緩められてからの話である。現時点では、日本においてはDPIの広告利用は許可されていない。
近頃、DPI(Deep packet inspection)の広告目的の利用の是非についてもめている。しかし思うに、物事の本質を理解していない人が多いのではないか。この問題は、技術とは全く関係の無い話である。OSIのレイヤーがどうのとか、TCPの仕組みとか、ましてやHTTPプロトコルの仕様などとは、何の関係もない話である。
そこで、ここでは、できるだけ簡単に、DPIについて開設しようと思う。
問題なのは、通信の秘密である。我々がよく言う、道徳だとか、一般常識などということを、ひとまず忘れてみよう。そうすると、通信の秘密というのは、別に守らなくてもよいのではないのか。なぜ守らなければならないのか。法律があるからである。
今、甲が乙に手紙を出すとしよう。甲は、乙にあるモノを借りており、そのお礼の為に、手紙を出すのである。
拝啓、先日、貴君より借り居りし艶本、喜能会之故真通を、ついに堪能致し畢。これ、世に並び無き逸品にて、平生貴君の主張せし、「葛飾北斎の絵は萌え」も、宜なる哉。聞説、世に初めて「萌え」なる言葉を使いしは、かの藤原道長なるべしと云々。その故は、御堂関白記に、「一条天皇萌え給ふ」と記されたるに由りてなむ、かくは云いつる。これまことに畏れ多い事乍ら、関白殿の自筆の文書残る上は、疑いは無之候。喜能会之故真通にも、就中、蛸と海女は、随一の傑作にて候。
一見してすぐ分かるように、この文章は、あまり人に見られたくない。そのため、甲はこの手紙を封筒に入れて、郵便で送る。
通信の秘密という、法律上の制限があるために、郵便事業者は、この封筒を開けて、中身を覗き見ることはできない。
DPIを広告目的で認めるということは、この法律を緩めるということである。では、この場合、何が起こるか。
例えば、甲乙の家に、以下のようなダイレクトメールが送られてくるかもしれない。
拝啓、先日、貴殿は葛飾北斎の蛸と海女を言及なされ候。弊社はこれ日本霊異記を出版する会社にて候。ご存知のごとく、日本霊異記の中巻、第四十一には、「女人大蛇所婚頼藥力得全命縁 」と題する話の有之候。これ、女人の蛇に二度までも婚はれる話にて候。興味のある上は、是非とも弊社の製品を買うてくださるべく、ひとえに願いたてまつり候。
これは、言うまでもなく悲惨である。いくら、封筒の中身はからくり人形が読むので、プライバシーの問題はないと言われたとしても、納得出来る話ではない。とはいえ、もし、広告を許可すれば、郵便料金が極端に安くなるか、無料だったとしたら、どうだろう。悩ましいところだ。
以上が、DIPの説明である。
しかし、通信の秘密が守られたとしても、結局乙がこの手紙を読むことにはかわりない。そもそも、この郵便事業者とは何を言うのか。OSIのモデルなど無視すれば、ISPもWebサイトも、郵便事業者に変わりないではないか。現在、メールの内容を読んで、広告を表示するWebサイトは存在する。GMailなどがいい例だ。ISPがやれば、単なるWebサイトやメールプロトコルを超えた情報が得られる。しかし、情報の多い少ないはあるとはいえ、結局、やっていることは変わらないではないか。ならば、緩めてもいいのではないか。
しかし、ただ広告を許可するだけでは、誰もそんなISPを使いたがらないだろう。一体、どうなれば、消費者は喜んでDIPを気にせず使うようになるのか。
たとえば、DIPを広告利用するかわりに、ISPや携帯電話の料金が無料になれば、どうであろうか。
これは、別に夢物語ではないと思う。NHK以外のテレビ局は、広告で利益を得ている。Googleも、広告で利益を得ている。うまく設計すれば、無料の携帯電話サービスを提供することも、可能になるかもしれない。
実際のところ、無料にでもならない限り、私はISPのDIP広告利用を許可したくはない。
例の話、40年前の大卒の給料が4万いくらと言われている。ただ、40年前の大卒といえば、いまよりだいぶ恵まれている存在といえよう。もうちょっと下というか底辺をみてみる。当時の自衛隊の一ヶ月あたりの給料は、2万ちょっとだったと聞いている。ちょうど、今の子ども手当（2万6千円）ぐらいだったはずだ。
だから、当時の円の価値は、今の10倍はあったのではないのか。それを考えれば、1500万というのも、まあ、感覚的には、そんなものだろう。
とまあ、雲の上人の話はともかく、C++0x本のStandard conversionsだ。
柳田國男は、「木綿以前の事」、「何を着て居たか」、「昔風と當世風」、「働く人の着物」において、やたらと木綿が汗を吸い、また乾きにくいことをもって、日本の風土に合わないことを嘆いている。
どうもこれが、今日の私には実感できない。よく、汗のために、シャツを着たほうがいいというではないか。あの言葉は間違っているというのか。
ふとあるきっかけで、柳田國男の文章を実感した。確かに、木綿は日本の風土に合わない。
この前、某検索巨人のロゴの入ったシャツを手に入れた。一二回袖を通した後、すっかり忘れていたのだが、昨日、ふと着てみようという気になった。着てみると、なんだか非常に蒸し暑い。着替えるのが面倒だったので、そのままジョギングに行ったところ、汗水になってしまった。これはどうしたことだとシャツをタグを見ると、100% COTTONと書いてある。なるほど、木綿か。
私は普段、どんなシャツを着ているかというと、ポリエステル70% 木綿30%のシャツを着ている。さらに私は、運動をするときのために、すばらしいシャツを持っている。このシャツは、ポリエステル100%で、しかも生地がメッシュ状になっており、非常に乾きやすい。それ故、真夏の炎天下の中、ジョギングをしても、汗でべっとりとすることがない。
ポリエステルが開発されたのが、ググッた結果のあるソースによると、1958年である。もとより高級な布ではないが、実用化されて、ユニクロで買えるようになったのは、さらに時代が下り、実に最近の話である。
なんということだ。現代に生きる私は、ポリエステル以前の事すら、分からなくなりつつある。
Blogger Buzz: Help Us Improve Blogger
どうやら、Bloggerがらみで、なにかやるらしい。非常に興味深い。なにか、最新のプロダクトかサービスかのテストらしい。Betaに流さずに、NDAを結んでのクローズドなユーザビリティのテスト。しかも、そのテスト自体を大々的に公開はする。ということは、近い将来、確実に広く一般に提供する予定の何かであろう。
ちなみに、techcrunch.comは、Bloggerのデスクトップクライアントだと予想している。
しかし、いまごろBloggerの専ブラを作ったところで、何か意味があるのだろうか。それよりは、GMailの専ブラでも作ったほうが、よほど注目を集めると思うのだが。
募集要項をみて推測してみよう。
「18歳以上であること」
これは、75ドルのアメリカン・エクスプレスのギフトカードがもらえるから、その関係であろう。
「NDAを結ぶこと」
これは痛い。Bloggerの最新のプロダクトについての情報は知りたいが、折角早く知ったとしても、知らせることができなければ、意味がないではないか。応募はやめておこう。
「動画や音声の記録に同意すること」
音声は電話の記録にしろ、動画はどうなのだろう。募集要項に、Webカメラを所有していることという条件はない。やはり、デスクトップクライアントか何かで、操作を記録するようなものなのだろうか。
「Windows 7/Vista/XP/2000の動くコンピューターを所有していること」
わざわざWindowsに限定ということは、やはりデスクトップクライアントか？
「ブロードバンド回線を所有していること」
音声や動画を、やり取りするのだろうか。
「テスト中に使える電話。スピーカーやヘッドセットが望ましい」
操作の指示や使っているその場の感想の聞き取りなどだろう。
時間指定をみると、テストにかかる時間は、一時間であろう。
やはり、デスクトップクライアントというのは、結構いいセン行っているのかもしれない。しかし、今頃Bloggerのデスクトップクライアントが現れたところで、あまり驚きはしないのだが。
These web standards are open...
これらのWeb標準規格はオープンで、
But soon other modern browsers will take advantage of these same web standards — and the amazing things they enable web designers to do.
すぐに、他の最新ブラウザも、同じWeb標準規格をサポートするだろう。Webデザイナーは、すばらしい恩恵を受けることになる。
ほほう、それはすばらしいことだ。では、早速、デモをみよう。
You’ll need to download Safari to view this demo. This demo was designed with the latest web standards supported by Safari. If you’d like to experience this demo, simply download Safari.
このデモを見るには、Safariをダウンロードしなければならない。このデモは、Safariがサポートしている最新のWeb標準規格を用いている。このデモを体感するには、Safariをダウンロードせよ。
えーと、オープンとか、他の最新ブラウザも、同じWeb標準規格をサポートとかいう理念はどこへ行ったのだろうか。
さらにひどいことに、このデモは、-webkit-ベンダープレフィクスを始めとした、Safariの独自拡張を使っている。オープンねぇ、オープンか。オープン・・・・・・。
まあ、これはAppleである。期待するだけ無駄である。
レゴで作ったプリンター。解像度は約75DPI、PPM（Pages per minute）は、1以下。
ひとつ、普通のプリンターより優れているところがあるとすれば、インク代が安いことだろう。フェルトペン一本で済む。
ここしばらく、夜寝る前に日本霊異記をちびちびと読んでいたが、今日、ふと思い立って、全部読み通してみた。
霊異記は、常に価値のある文章である。第一に、相当古い。西暦800年頃に書かれたと考えられている。
その内容も、単に経典から引用したのではなく、世俗の話が書かれている。
興味深いことに、非常に似通った説話が、いくつもある。説話にはお約束があり、そのお約束からあまりに逸脱すると、不自然で興冷めしてしまうのだろう。
肝心の文章は、変体漢文で書かれている。意味を取ることぐらいなら、一応は出来るのだが、霊異記の筆者は、当然訓読みで読まれることを想定したはずで、その訓は、当時の言葉でなければならない。この当時の言葉で訓をするというのは、非常に難しい。後に加えられた訓点や、当時の複数の訓読み辞書、時には、他の文章の訓点を参考にしながら、然るべき訓を決定していく、地味な作業である。これは、真面目に行うと、何十年もかかる。
その他、「経に曰く・・・・・・」という文章が出てきた場合、実際に経典を調べて、本当にそんな文章があるのかどうか調べるといった作業もある。霊異記にも、いくつか、教に曰くと言いながら、そんな話はどの経典にも載っていなかったりすることがある。また、大般若経に曰くと言いながら、大般若経には載っていないこともある。また、何経に曰くと言いながら、その名前の経文は、存在しないこともある。こういう研究は、人生を潰せるぐらい、地味で時間のかかる作業である。
幸いにして、すでに先人達が相当に地味で時間のかかる面倒な研究で人生を潰してくれたおかげで、私は、気楽に霊異記を読めるのである。ありがたい話だ。
さて、いろいろ重複している話の中で、なかなか面白い共通点がある。
例えば牛だ。多くの話で共通しているのは、牛は、その前世某という者、人や寺の物を断りなく使い、その宿業によって、今牛となってこき使われているというものだ。なぜ物言わぬ牛に、そんな因縁があるとわかったかというと、人の夢枕にたったり、託宣があったりして、明らかになったのである。
あるいは、あの世に行く話だ。死んであの世に行った者が、写経や放生の善行によって、救われる話であるとか、それでも悪業が多くて刑罰を受ける話がある。この話が、当時の死生観も垣間見れて、なかなか面白い。
また、女の怪力の話もある。なぜか、怪力の話は、すべて女である。それも、いかにも筋骨隆々とした無骨な女ではなく、至って普通の、時には、周りからばかにされるぐらいの女である。神威は意外な者の上に現れてこそ、印象深いのだろうか。
下ネタに走ると、当時、男性器と女性器を、書物の上で、どのように記述していたのかという興味深いこともある。女性器に関しては、古事記では、陰という文字が使われていた記憶があるが、男性器の方は、たしか、古事記では、明確に書き表していなかった覚えがある。
ちなみに、霊異記や今昔物語では、男性器に対しては、マラという訓を当てている。では、女性器はどうか。これには、当時の訓読辞書によれば、クボ、ツビ、シナタリなどという候補があるらしい。岩波の霊異記では、どのように訓ずるかという問題を、脚注と補注で、大真面目に取り上げている。
国内初の３Ｄアダルト登場、対応テレビ普及の起爆剤なるか(Update1) - Bloomberg.co.jp
世間では、3Dが流行りである。ここでいう3Dというのは、秒間120フーレム表示できる液晶ディスプレイを使い、二つの微妙に異なるフレームを交互に表示して、さらに特殊なメガネをかけることにより、秒間60フーレムの動画に、立体感を持たせようというものだ。
私はすでに、3Dがどのように見えるかを体験した。しかし、映画やゲームを、3Dで観たいとは思わなかった。
ある人曰く、「やっぱエロやで。世の中はエロを求めているんや。エロさえあれば売れるで」と。
VHSがBetamaxに買った理由として、ポルノコンテンツが豊富であったという、冗談のような話をよく聞く。それは知っているが、しかし、どうだろう。もちろん、コンテンツとしてポルノは、人気があることは認めるが、はたして。
メールに統合したのは、失敗であった。Micro bloggingは、それ自体で別に作るべきだった。
Google BUZZは、まともに読む気にならない。GMailは、それまで、メールであった。今まで、皆メールとして使っていた。メールは、相当の歴史ある機能であり、おいそれとは変わらない。いきなりMicro blogging機能が付加されたとして、誰が使うというのか。
BUZZがあまりにも邪魔なので、とうとう削除した。一応、今は、BUZZを表示しないという設定にしているが、完全に削除するという選択も考えている。GoogleのBUZZは、BUZZにすらなれなかった。
そもそも、Micro bloggingは、Webのあるべき未来の姿ではないと信ずる。
思うに、これまでのWebの進化は、皆、情報弱者にも、参加の道を設ける方向に進んできた。自分でサーバーをたてるのが面倒なので、レンタルする。Webサイト構築が面倒なので、あらかじめ作られたテンプレートに沿って、Webサイトを生成するようにする。これらは、技術的な負担を軽くするための進化であった。
ここで、どうも方向が怪しくなってきた。自分で自由なことを書けば、当然、反対者からは批判される。この批判から守るためか、どうも、変わったサービスが流行るようになった。Social Networking ServiceとMicro bloggingだ。
SNSは、非常に親しい人間同士でのコミュニケーションである。自分の日記などは、あらかじめ許可した「友人」しか見ることができない。この友人との関係は、なかなか切ることができない。それ故、積極的な批判は抑制される。なぜならば、その友人とは、今後も付き合っていかねばならないからだ。批判とは、攻撃である。攻撃していては、関係は保てない。お互いにできるだけ批判をせず、有効的にやっていこうとする。
Micro bloggingは、また別の方法で、批判を避けているサービスである。これは、「つぶやき」である。ちゃんとした文章ではない。「私は今ここにいる」、「私は今これを食べている」、等々、どうでもいい日常の雑事や、とりとめのない思いつきを書く。もとより、何かを強く主張するものではなく、批判の対象に上りにくい事象である。
このような、批判を防ぐための進化は、正しいWebの未来ではない。これでは、議論の結果、より高い結論に達するという、人間の持つ高度な機能が、失われてしまう。
どうも、技術の進化と、我々人類の改良は、一致しない。有意義な議論という点で考えれば、IRCや2ch.netの方が、いまだに優れている。
もうすぐ、予約受付が始まる。今回の雑誌には、私の記事が、何と二つも載っている。「Bjarne Stroustrupへのインタビュー」と、「C++の歴史」だ。
C++の歴史では、D&Eに載っていない、いくつかの事柄の歴史について、書いた。たとえば、テンプレートのInclusion modelとSeparation modelにまつわる話。これは、なぜexportが、当時採用されたのかという問題の本質を解説するものである。また、STLが規格入りするまでの経緯の解説もある。STLが規格入りするまでには、相当な紆余曲折があり、だいぶドラマチックな話もある。EC++に関する話もある。EC++は、もはや死んだ規格なので、今更資料を集めるのが難しかったが、よく考えれば、C++WG JPに、当時を知る人がいるはずである。実際に当時のEC++規格のプロジェクト・リーダーを務めた人から、色々と興味深い歴史的な話を聞くことが出来た。
今回、一般の書籍の流通には出さなかった。これをアキラさんに訊ねたところ、「一般の流通に卸すには、それだけで結構な金がかかる。ある程度の売上を見込めないと、一般の流通には出すことはできない」とのことであった。我々の当初の目的は、赤字を出さないことである。赤字さえ出さなければ、とにもかくにも、続けていくことができる。もし、今回の雑誌の試みが、大いに成功すれば、将来的には、一般の流通に卸すことができるかもしれない。
ともかく、販売形態としては、物理的な印刷物としての通信販売と、PDFでの販売がある。