気づいたことは幻想
次に至るは妄想
バレエの元となるシナリオを書いている夢を見た。一通り書き終えた後ある作品を見て、書き直さなければという思いにかられた。そのことを話すと、「お前もか！ お前もあれに充てられのたか！」と責めるように言われた。結局和解できずにその夢は終わった。
[topic:ゲーム、まんが]
メルティ・ブラッド(と月箱収録のもの)を除き、月姫終了。ネタが被る部分はあるものの、影響を受けると言うほどではない。(ネタが被っているからかもしれませんが……) どうやら月姫の及ぼした影響の大きさから、創作上の影響も大きいだろうなと早合点していたみたいです。全体的な印象としては、ビジュアル・ノベルにおけるお手本的な手堅い秀作。作り上げた世界観の深みや可能性の広がりを見せる懐の深さなどもきっちり押さえてあるし。なるほど支持されるわけですね。plus-disk 、歌月十夜などにおいてとらハのように誰もが笑顔でいられる状態の存在をオフィシャルで認めているというのもあるかな？ 琥珀シナリオはプレイヤーの充足と引き換えに、本来翡翠や弓塚さつき(こちらに関しては確信は得られないけど。)のシナリオで語られるべきことを持ってきてしまったような感じがしますが……。当初ファンディスクを作る予定はなかったはずだろうから、エンターテイメントとしては間違ってないんでしょうけど……翡翠シナリオの完璧さを損なわせる蛇足となっているのも確か。
ところで、痕も雫もサウンド・ノベルもやっていない、そうした形式的な約束事を一切知らない人間に月姫がどう写ったのか気になります。
苺ましまろはいつもの癖を発揮して買うかどうか散々迷ったのですが、買ってみると気がつけば手に取って読んでいるそのぐらい馴染んでいます。
成績ついているだろうしそろそろ大丈夫だろうと思うので、7月に書いたレポートを掲載しておきます。……やりたい話のために書いているような感じです。カレル・ヴァン・ウォルフレンの本に関しては、レポートを書き終わった後に適切な論題が出てきた、というのもあるのですが……。
小説はここまで書けばようやくもう一つの話の続きが書けるんだけど……なんか気に入らない。うまく説明できないけど、何か気に入らない。前回のと合わせて書き直し候補としてマークしておこう。
[topic:企業、ライセンス]
企業の取るべき国際戦略は、情報や他の企業の分析をもとに、事業戦略にあった国を選んだり、あるいは進出先の国状況から事業戦略を組み立てたりして決められていく。
だが、国際戦略において発展途上の地域に目を向けるとき、私達は無意識に大量生産的な視点を取るっているのではないだろうか？
先進地域には技術があって、発展途上地域には技術がない。だから技術のないところに技術を持ってきて、安い賃金で働かせる。それは常識的な考え方だ。だが Lakoff が『認知意味論』において古典的カテゴリー論・客観主義という世の中に浸透した常識にメスを入れてとらえ直しを図ったように、またエントロピーについてきちんと考えずに都合のいい部分だけを持ちこんだ情報理論や経済学を批判する必要があるように、私達もあらためてこうした無意識と向き合う必要があるだろう。
安い労働力でたくさんものを作って売る。その考え方は正しいだろうか？ 大量生産方式の限界が叫ばれている昨今、どこもそれでやっていけるかどうかは疑問である。確かに好みがまだ多様化していない途上国に売ったり、規格が安定している部品などを売るときにはそのアプローチが妥当だろう。だが、日本や欧米市場向けの商品およびその材料を作るとき、果たして消費者のニーズに迅速に対応していけない大量の在庫を生み出すそのアプローチでいいのだろうか？ ユニクロのような安さを売りにするブランドであっても、「安物だからそれなり」というイメージを消費者に抱かせてしまって果たして良いのだろうか？
国には技術レベルがあるという考え方は妥当だろうか？ 頭ごなしに決め付けるのではなくても、労働者の多くが職業訓練校を経たもので構成されているようなところでない限り、基礎教育の問題を除けばどこの国でも一から労働を学ぶものに過ぎず、技術をもった場というものが重要なのだという事実に基づき、そこで迅速に他のところと遜色のない高い技術レベルの場を構築すると同時にあらかじめその国の人と接しておくことによって、起こるべき文化摩擦をある程度経験・予想できるという効果を狙って、最初の(進出先の国人の)メンバーのいくらかあるいは全員を鍛えてから進出し(この際、不法就労者をただ国に返すのではなく、その人が元いた国へと進出しようとしている企業との双方の同意に基づき、公正プログラムの一環として雇わせるというようなことはされているだろうか？)、定期的に研修を受けさせるという手法を使うものの、思うように効果があがらない時間のかかるものであるという過去の事実や、出稼ぎというスタイルのため雇用が安定せず技術の場が維持できないという問題から、やはりこれを肯定するという意見がでるかもしれない。しかし、本当にそれを実行してきたのだろうか？ ある程度形をなぞっただけで満足してきたのではないだろうか？ 『隠れた人材価値』を読んでみて、このことに疑問を抱かずにはいられない。
おまけに懸念事項の一つにあがっている労働の意欲に関しても、会社と言う組織の場が重要であることも指摘されている。こうした問題は日本的経営の良い部分と欠点をきちんと把握し損ねたのが原因だったのではないだろうか？ また、今日では情報技術の発達に伴い、コミュニケーションのレベルで技術獲得の速度が上がっていることも忘れてはいけない。
進出において知的財産権に懸念を持っていることにも疑問を感じる。もともと特許は誰も思いつかなかったようなアイデアに対して独占権を与える代わりに、公開させるというインセンティブを得るためのものであった。これが誰でも思いつくようなアイデアに対しても取得され(既に公になっているものに何とか理由をつけて取得されるケースも多い。そのため、ソフトウェア業界においては特許の情報を見ないという歪みも表れている。)、ロイヤリティを得るための手段や先進国においてはそれ以上の価値がある(10倍以上に達することもある)ことも多い「他者の特許へのアクセス」―クロスライセンスに用いられるような現在の状況は果たして望ましい運用といえるだろうか？
ここでは近年関心がますます強くなっている知的財産権について、一つのアイデアを提示してみることにしよう。
もともとの意味で用いるようなケースもあるだろうし、特許を廃止しろとは言わない。(産業革命が蒸気機関の特許切れによって起こったことを考えると、これは微妙な問題である。)代わりにノウハウを含め、ライセンスを主な目的とするもう一つのシステムを作ってしまえばいい。さらにこれは、知的財産権に関わるもう一つの疑問、こちらがライセンスすることばかりが前提となっていて、(ナレッジ・マネージメントの最近の流行であるコミュニティの研究に関するものを除いて)向こうで知が生まれていることをあまり意識しない……アイデアはどんなところからも生まれてくるし、適切な知識とインターネットなどを使った情報の共有さえできれば環境のハブ的な側面を乗り越えて最先端の情報や知に触れられていられるし、ネットワークのクラスター(集まり)の外側にいることがクラスターの内部の視野の狭さや盲目から解き放つというのにもかかわらず……や、特許の国際的な展開におけるわずらわしさ、近年話題になっている職能発明者にたいする「相応の対価」、といった問題に目を向けたものであるといいだろう。
つまり、各国政府の資金および企業、個人から寄付金を集め、それを1〜数年の企業活動に大いに貢献した発明やノウハウなどの貢献度に応じて(会社および個人に)配分するというシステムによって、一種のFLA(Free License Area)を仮想的に実現させてみてはどうだろうか？ (もちろん政府の負担を減らし各国の産業に貢献するという意味で、寄付金は減税の対象になるべきである。)
これはオープンアーキテクチャーへの誘惑でもある。複数企業で協力していても平等にロイヤリティーを受けることが保証される場合、わざわざ隠すことによって再発見・再発明のコストをかけロイヤリティーを逃すというリスクを侵すよりも、協働し、積極的に公開した文書によって自分達が発明者であることへの認知を得、特許化などに対する牽制をかけた方が得だろう。またこれは、実践コミュニティが企業の外側に広がったり、他の実践コミュニティや消費者のコミュニティなどの複数のコミュニティとの連携などをおこなう際に、抱えるべき企業秘密を最小限の重さにすることによって秘密を漏れにくくするという効果も持つだろう。
Jeffrey Pfeffer, Charles A. O’Relly III 著, 廣田里子,有賀祐子訳, 長谷川喜一郎監修, 隠れた人材価値株式会社翔泳社, 2002
原書:Hidden Value：How Great Companies Achieve Extraordinary Results with Ordinary People, Harvard Business School Press, 2000
Etienne Wenger, Richard McDermott, William M. Snyder 著, 櫻井祐子訳, 野村恭彦監修, コミュニティ・オブ・プラクティス, 株式会社翔泳社, 2002
原書:Cultivating Communities of Practice: A Guide to Managing Knowledge, Harvard Business School Press, 2002
[topic:産学連携、オープンソース]
中には物事を一面的にしか見ていない部分も見られるが、この本で述べられていることの多くは正しい。だからこそ、この本で述べられていることは真剣に考えなければいけない。
現在の大きな障壁は、解雇を万能薬と考え、解雇するから人が足りなくて残業する、残業するから効率が悪くなる、効率が悪いから採算が取りにくくて解雇するという負のサイクルに喘いでいるの企業の状況だろう。これを解決するために、忙しいならば解雇よりも一人あたりの労働時間を減らして、ワークシェアリングした方がいいということを真剣に考える時期が来ているのではないだろうか？ 労働時間が減って、給料は減少しつつもある程度の収入が保証されるのであれば、他の事に費やすための気力や余力を確保することができる。……とはいえ、ここではそういった一般的なワークシェアリングのモデルだけをそう呼びたくはない。私達は既にオープンソースというモデルを知っている。市民一人一人の行動が政治活動の仕事を共有(シェア)するように、いかなる形であれ仕事が共有されることを全てにワークシェアリングの定義を広げたい。
最近の経営学ではコミュニティやコミュニケーションが再評価されている。だったら、それをもう少し広げてやればいい。社内であれ、社外であれ誰もが会社の経営に口をだすことができ、有用な助言であれば些細なのも含めて謝礼を支払う(お金である必要はない。大事なのは広く意見を聞き、参考にしているという姿勢を見せることである。)ことによって、社内・社外を問わずアイデアを活用できるようにしたり、オープンソースにすることによってシステムの開発・チューニングを他社と共有しコストを減らすこともできるはずである。さらにオープンソースのやり方をソフトウェアだけでなく、様々なものの研究開発に広げてしまってもいい。研究開発の外部委託(アウトソーシング)や M&A によって研究成果を買い取るということがあることを考えれば、これは決して非現実的な方法ではない。
こういうアイデアを提示した時に持ち出される反論の一つは「ソフトウェアとは違って、誰もが研究開発に加われるわけではない」というものだろう。確かにソフトウェアの場合には、誰もがアイデアを試せるという強みがある。多くの人がコンピューターを手にしていて、(アーキテクチャーの違いはあるとはいえ)手元にコンピューターさえあれば作って実際に試すことのできる環境を既に手にしている、あるいはすぐに手に入れることができる、そういう他にはあまり見ることのできない強みがある。
あえて他にこうした例を挙げるとすれば、古典的なものとしては学問、最近のものとしてはインターネットや Web による情報やアイデアの伝播自体などであろう。ただし、blog やオープンソースジャーナリズムなどといってこれを喧伝する人々の言葉にはこの効果を過大評価し過ぎている面がある。例えば創発民主制[PDF]では blog のシステムを駆使することでいかに理想的にアイデアをうまく拾い集め活用することができるようになるかといったことを述べているが、学問の歴史を紐解いていけば分かるように、実際には優れたアイデアが長らく(時には何百年も)理解されず埋もれていることが多々あるし、遺伝子の話のように(科学者自身を含めて)世間的な誤解ばかりが広まってしまっているケースも少なくない。また、こうした話の中では排他的・硬直的性質、集団ヒステリーなどのコミュニティの陥る可能性のある様々な負の側面に対する見通しは甘いか、全然触れられていないことが多い。……とはいえ、ジャーナリズムの持つ一面的な見方からの意見形成から人々を解放し、意見を修正したり、様々な視点・アイデアに触れる可能性を広げる、という彼らの主張の核となる部分は認めることのできるものである。
それはさておき、オープンでハードウェアを作るなどの研究開発をおこなうことの難しさは、ソフトウェアと違って誰もが作って試せるわけではないという部分にある。だったら、それを変えてしまえばいい。例えば、研究開発のための知識、設備を扱うためのリテラシーを学ばせるための講座を開き、それを終えればスタッフの立会いの下自由に利用できるよう設備を解放して、研究開発に関わるソフトウェアを GPL に基づく自由なソフトウェアとして配布する(ソフトウェアの改造が自由でなければ、ソフトウェアで定められた範囲の外にある発想を生かすことができない)。こうした支援によって、誰もが作って試すことのできる状況を築いてしまえばいい。
加えて、講座を学生におこなわせて知識がしっかり身についているものかどうか確認するための場としての側面を持たせたり、学生の実習または研究内容が研究開発に関係のあることで興味がある場合に見学や意見交換ができるようにしたりするならば、本当の意味での産学連携を成すことができるだろう。現在良く言われている産学連携には特許の取得や企業活動を重視することで自由な研究を妨げたり、場合によっては学説までも曲げてしまうような産学癒着に陥りやすいという罠がある。また、学問上の研究はたとえ今役に立たなくても何十年以上も後に主流な産業を支える技術となることも少なくない。今の産業の発展を重視するようなやり方ではこうした芽をみすみす摘み取ってしまうことになる可能性が高い。(ドッグイヤーと呼ばれるソフトウェアにだって、価値が認められるまで長い時間がかかったものは少なくない。その代表例として、生まれてから数十年かけてその機能が評価され成果が少しづつ取り入れられている Lisp などの関数型言語が挙げられる。)だからそこに、どちらにも属さない個人による研究という別のものを噛ませる必要があるのだ。それに、やりたいと思うことに実際に関わることができてこそ生涯学習と言えるのではないだろうか？
こうしたせっかくできた時間を様々な開発に当ててしまうのは、市民活動に当てるべき時間を削ってしまっては望ましくないという意見もあるだろう。だが、昼間生活の糧を得るために働く人にとって、夜自分のためにおこなう仕事というのは精神的にも質的にも明らかに違うものである。これはオープンソースを仕事にしている人とて、その興味が今もそれ自身にあるのでなければ例外ではない。良い精神状態は高い生産性を生み、百人に匹敵するような高い能力を持つ人が会社に縛られることなく、自分の興味の向いたものに労力を注ぎ込む。そうしてできた成果物を、会社は特別な理由がない限り再発明せずに共有しあう。こうすることによって無駄な労働力を省き、より多くの人の労働時間を軽減するという結果を生むことができるだろう。
また、オープンソースのスタイルで人々がより技術に通じ周りのものに関わっていくということは、周りからブラックボックスをなくすということでもある。例えば、プライバシーと関わりの深い技術をオープンアーキテクチャー、オープンソースにすることで検証し、望ましくない機能を改善あるいは排除するよう働きかけていくことができる。(アーキテクチャーは必ずしも公開されているわけではなく、公開された資料や分かっている事実をもとにコメントしているだけに過ぎないが、高木浩光さんが日記に現在の技術とプライバシーの問題について取り上げているのはこのよい例であると言えるだろう。実際に企業が改善すると応えたケースもあった。)
以上かなり遠回りをしてきたが、私はこうしたワークシェアリングとオープンソースが望ましい市民活動への道を切り開く方法の一つであると信じている。
Ruth Hubbard, Elija Wald 著, 佐藤雅彦 訳, 遺伝子万能神話をぶっとばせ―科学者・医者・雇用主・保険会社・教育者および警察や検察は、遺伝がらみの情報をどのように生産し、操作しているか―, 東京書籍, 2000
原書:Exploding the Gene Myth: How Genetic Information Is Produced and Manipulated by Scientists,Physicians, Employers, Insurance Companies, Educators, and Law Enforcers, Houghton Mifflin, 1999
Tom DeMarco 著, 伊豆原 弓訳,ゆとりの法則, 日経BP社, 2001
原書:Slack, Broadway Books, Bantam Doubleday Dell Pub (T), 2001
Tom DeMarco, Timothy R. Lister 著, 山浦 恒央訳,ピープルウエア 第2版, 日経BP社, 2001 (Second)
原書:Peopleware, Dorset House, Dorset House, 1999 (2nd ed.)
[topic:創作、小説]
「そう？」もう一人の少女はきょとんとする。それから、総意にもとづいているはずなんだけど、と呟きながら首を傾げた。
「何が幸せかを決める事は傲慢だろうな。」男は平静を装って答える。
「……ある男がいた。その男の目的は相手を殺す事だった。だが、男はそのことで誰かを不幸にすることを…………」喉まで出かかった言葉を消して、首を振る。「……いや、何でもない。男は心残りを満たす時間を与えた。その時まで相手を護りぬいた。男はそれでいいと思っていた。男は次第に名探偵であるかのように扱われるようになり、矛盾は広がり、男の傲慢は火を見るよりも明らかなものとなった。」
馬鹿な男だ、と聞こえないくらいの声で呟く。
少女はただ黙っていた。
「もう一人知ってる？ その人は人に望む世界の望む役割を与えた。だけど結果には関心を持たなかった。だから、互いに干渉したり矛盾するものであっても関係なくそれを実現する―それだけの能力はあったけど、結果はその時によって違った。その人と同じ事をし得る能力を与える事にも無頓着だったし、それが集まる世界さえも肯定した。」と、もう一人の少女は告げる。
「……で、罪滅ぼしをしろと？ それとも……」男は少女の方をちらりと見て、「それとも、許せないのなら手伝えと？」
もう一人の少女は首を横に振る。
違う？
振る首が止まった時、男は見つめる相手が期待するような眼差しでこちらを見ていることに気づいた。
？ 何を期待しているのだろうか？
記憶を辿る。答えが何か分かっているような気がする。だが、あと一歩というところでうまく引き出せない。今はあれの印象が強すぎる。
男が思い出すのに苦心している間、相手はだんだんと期待するような眼差しから不安げな上目遣いに変わっていく。それでも思い出せない。
「それだけなら手伝って貰う必要はないの。無限の時間と失敗が許されているなら、どんな絡まった糸だって解きほぐす事ができるから……」と、補足する。少し手繰り寄せた。だが、まだ男の手は答えにはとどかない。
少女はだまって様子を見ている。もう一人の少女はもう泣きそうになっていた。
情を交わした覚えはないんだが……と思いかけて、ふと浮かんだ場違いな考えを追い払う。できの悪い配役だ。
配役？ 言葉が引っかかる。…………ああ、そうか。
組み合わさって一つの絵が浮かび上がる。ようやく手が届く。
「鍵は届けられた。」宣言する。
「……本当に演っていたわけだな？ 『時空の放浪者』を演っているやつがいるんだな？」男が確認すると、もう一人の少女はそれまでの泣きそうな顔が喜びに彩られる。
「そうなんだ。」少女は他人事のように言う。
「それで、どう呼べばいい？ 同じでもいいけど、二人を区別する方法が欲しい。」と、男。
もう一人の少女は少女を見て、「静かなあなたに対し、私は香るから
「逆で"るか"だと、ますます載せられているような感じで嫌でしょ？」男に向かって微笑む。
その様子に
10月11日（土）・12日（日）の国立音楽大学大学院オペラ 「秘密の結婚」の招待状2枚入手。二日とも行くのもいいかもしれないけど……「一緒に行きたい方いませんか？」って言ったら誰か来るかな？
[topic:まんが]
コトノハ[都築真紀]を入手しました。この同人誌には100質問に回答したとき教えてもらった NAKID MIND が収録されているということで楽しみにしていたのでした。
なるほど、そういう風に料理したんですか。例えシチュエーションから発展したものだったとしても……こういう話を描ける自信はないです……。
私が月姫に対してあっさりとただ秀作と語る一方でこの作品や苺ましまろなどを強く意識し羨ましく思うのは、民話に親しんだ時期が長かった、そしてその頃から既に物語を思い描いていたせいで、そういう話は得意だしプロットだけならいくらでも作れるけど、日常的な描写が弱く厚みができないという弱点を抱えていることを自覚しているせいだ。もちろん、知識としては知っているし、シチュエーションやシーンというものを考える事はできるのだけど、まだそれが他と同じようにあるべきところに自然に出てくるという状態ではないから、(描写が優れているとか劣っているとかとは関係なく、)そうした方向にチャンネルが開きやすくするために、無意識にこういうものの方にベクトルを向けているのだろう。ということを、添えてあった文章のことを考えていてふと思った気がついた。(そこに辿りつくまでの思考過程は恥ずかしくてとても書けたものではありません。)
変わっていけるだろうか？
昨夜眠ろうとしている時に布団の中で鬱になってしまいました。すぐ側に私のパソコンでオンラインゲームやっている(に人生を食われている)弟くんがいたんだけど……そんなんじゃ、いないも同然だし…………
原因は色々……やっぱり、自殺システムについて考えたのが悪かったのかな？ その時は、「それが普通になると自殺者がでることが当たり前になってしまって、どうやって出さないようにするかという視点が消えてしまうのが問題」という普通の結論をだしたんだけど、寝ている間に、もしたまたま死に損なってしまって、それ以外の死んでもおかしくないような状況でも無事だった状況と照らし合わせて、「私にはやらなければならない事があるから生かされたんだ」と考えた人が、それに縋って生きていくのだけど、そのやらなければならないことを周囲に反対されつづけて打ちのめされてしまったら、どう生きていけばいいのだろうと考えてしまって…………と書いているとまた鬱になりそう……
亜里亜でいられたら、幸せだったのに。千影でいたら、幸せだったのに。今はただ兄やが欲しい。
[topic:企業]
得尊さんところ経由で図書館に関する議論を見ていて、足りないなと思った論点を列挙。余裕がないので、フォローはできません。
双方の立場に溝があるのなら、それを埋めるよううまく立ちまわるのがビジネスだったと思いましたが……
同様に、農産物の輸出入の場合にも以下を押さえた議論が欲しいところ。
[topic:アニメ、感想]
E'S otherwise。分かってない！ 観たのは最初、最後の2つ前、最後とあと1話くらいですが、(戦闘シーンが適当なのはいいとしても)丸く収めて普通のアニメにし過ぎ。
終わっていない原作の代わりに読みきり版の Prelude to the Death 的なエピソードを持ってくるのは分かるんですけどね……いくつか役割が転換されたところで避けられるはずのないあの悲壮感は全然感じられないし、セブンス・サガで見せた帰還のシーンそしてラストのような物語を締め括る上での美意識も感じられない。そういった結賀さとるテイストがごっそり抜け落ちていて、かといってこれを超えて見せろと挑戦状を叩きつけるような気概も感じられない。そんな中途半端で適当な仕上がりにただ呆れるばかり。
一方、D・N・ANGEL は結構良かったみたいですね。(シリーズ構成の荒川稔久にファンがいるのは分かるけど、監督のファンサイトもあるんですか。)託された自己犠牲の否定の想いを日渡に受け渡すところとか、抱き合う二人と対照的に見つめ、目を逸らし、それでもお互いを見る二人とか、最後のキスまでの見つめあい躊躇いがちな動きと表情を変える様とか、そういうところが本当に良く描けていて幸せ。最近、自己犠牲の否定を託す「時の秒針」編を読んで、この話は抑えなきゃ、それ以降をどう描くのか見届けなきゃと数話観ただけなのを後悔しています。
[topic:C++]
参照の参照は別に Metaprogramming なんかやらなくても、library で参照を使っている時点で問題になるので、参照の参照ができないことが問題視されているんですよ。いちいち library 側で回避するのは面倒です。
参照の配列に対するアイデアを色々と思いつきました(配列を自作するとか)が、サイズを問題視しているようなので無理でしょうね。
[topic:C++]
難しく考え過ぎではないでしょうか？ 同じようなコードが何度も現われる状況は、その部分を関数化するという Refactoring をおこなう典型的なケースだと思います。
void pritEffi(char name, int StartNum, int EndNum, int StartTime, int EndTime) {
Effi = (EndNum - StartNum)/(EndTime - StartTime);
std::cout << name << ": " << Effi << "/msec" << std::endl;
}
printEffi('A', aStartNum, aEndNum, aStartTime, aEndTime);
printEffi('B', bStartNum, bEndNum, bStartTime, bEndTime);
printEffi('C', cStartNum, cEndNum, cStartTime, cEndTime);
本当に沢山あるのなら inline 化するという方策も使えますし、特にプリプロセッサを使う必要はなさそうですが。
それに関数化した方が boost::function を通して std::foreach を使うことができるので便利だと思います。
Wayne さんへのお返事を誤って 25 日分に書いてしまったので慌てて日付を 25-26 日に変えたのですが、あれから反応がないようなのでお返事が届いていたのかどうかが心配です。(こちらにミスがなければ、特に返事する必要がなかったんだなと納得できたのですが……)
光ファイバーにして2回線で同時接続できるようになったところ、今までとられていた時間が長かったため常時接続に慣れていない + このマシン非力なのでゲームを消化できないし、重くて Haskell をつつく気になれないため、ついつい Web を巡る方に流れてしまっています。堕落中。
[topic:C++]
多すぎる関数の引数を減らす となると、真っ先に思いつくのはこんなあたりでしょうか。
Curry 化する(C MAGAZINE 7月号に書いた boost::function と boost::bind の合わせ技)
boost::function<void (char, int, int, int)> func1 =
boost::bind(foo, _1, _2, _3, _4,
localvar1, localvar2, localvar3,
usevar1, usevar2);
プリミティブな関数を書いて合成する(boost::compose と boost::bind でもできますが、見た目重視でなんとなく Boost に統合予定の FC++)
using namespace fcpp;
int makeEffi(int StartNum, int EndNum, int StartTime, int EndTime) {
return (EndNum - StartNum)/(EndTime - StartTime);
}
void pritEffi(char name, int Effi) {
std::cout << name << ": " << Effi << "/msec" << std::endl;
}
/*
* 実際には関数ではなく、functoid を定義しなければいけません。残念です。
*
* struct MyFunctoid {
* // Sig information
* // operator(w,x,y,z) definition
* };
* Curryable4<MyFunctoid> makeEffi;
*
* namespace impl {
* struct XMyFunctoid {
* // Sig information
* // operator(x,y) definition
* };
* }
* typedef Full2<impl::XMyFunctoid> MyFunctoid;
* MyFunctoid printEffi;
*/
(pritEffi('A',_) ^of^ curry4(makeEffi, aStartNum, aEndNum, aStartTime, aEndTime));
欠点はコンパイル時間が長くなる事。もちろん、普通にラッパー関数を書いても構いません。
一方、
汎用性のない関数でグローバル空間もしくはメンバ空間を汚したくなかった
というのは、namespace (無名 namespace という手もあり)によって解決できますが、もしどうしても関数内関数が使いたいというのであれば以下のようなものもあります。
// FC++ のサンプルコードより
#define FCPP_ENABLE_LAMBDA
#include "prelude.h"
using namespace fcpp;
// 返し値の指定がすごい事になっていますが、コンパイルエラーを分かりやすくするための
// Type Signature です。
LEType<LAM<LETREC<BIND<1,LAM<LV<3>,IF1<CALL<Equal,LV<3>,int>,bool,
CALL<LV<2>,CALL<Minus,LV<3>,int> > > > >,BIND<2,LAM<LV<3>,IF2<
CALL<NotEqual,LV<3>,int>,CALL<LV<1>,CALL<Minus,LV<3>,int> >,bool>
> >,CALL<LV<1>,int> > > >::Type
whoa() {
LambdaVar<1> even;
LambdaVar<2> odd;
LambdaVar<3> X;
return lambda()[
letrec[ even==lambda(X)[ if1[equal[X,0],true,odd[minus[X,1]]] ],
odd ==lambda(X)[ if2[notEqual[X,0],even[minus[X,1]],false] ]
].in[ even[3] ] ];
}
もはや C++ のコードではありませんね。