前回からちょっと間が空いてしまいましたが、ADPの1周年記念記事のPart4です。
関数呼び出しのスタックの使われ方
前回の記事の終わりにスタックという言葉が出てきましたが、スタックとはプロセス（正確にはスレッド）毎に用意されているメモリエリアで、関数呼び出しやローカル変数の保持に使われます。
以下のC言語での関数呼び出し時のスタックの使われ方の例を図1に示します。
func( arg1, arg2, arg3); /* ------- ※1 */
図1
スタックは伝統的にアドレスの上位（数字が大きい）から下位に向かって領域が確保されます。
※1の関数が呼び出されるとき、先ず引数がスタックに積まれ、次いでリターンアドレス、そしてローカル変数の領域が確保されます。関数というのはどこから呼び出されても元の場所に戻ることが出来ますが、それが実現できるのは、呼び出し後に実行すべき命令のアドレス（リターンアドレス）をスタックに保持しているからです。
また、同時にどこから呼び出されてもローカル変数が『関数内で一時的に有効な変数』として機能できるのもスタックに変数のエリアを確保しているからになります。
ちなみに、数年前に流行したセキュリティリスクでバッファオーバーランというものがありますが、これはローカル変数の領域を溢れさせアドレスの上位にある戻りアドレスを書き換えてウイルスのプログラムを実行しようというC言語の関数呼び出しの仕組みを悪用したものになります。現在ではCPUレベルでの対策（NXビットとかXDビットとか呼ばれものでデータ領域の実行の禁止）が行われ、バッファオーバーランの脆弱性が起こりにくくなっています。
スタックには引数が積まれていますが、引数が積まれる順番には2通りのやり方があります。図１ではリターンアドレスに次いで arg1,arg2,arg3 と積まれていますが、反対に arg3,arg2,arg1 というやり方もあります。arg3,arg2,arg1の順番ですが、一見すると反対に見えますが、スタックに積む順番はarg1,arg2,arg3となります。ややこしいですが、※1の擬似アセンブラコードを示すと意味が良く分かるかと思います。
※2 ※1の擬似アセンブラコード（cdecl呼び出し）
PUSH arg3
PUSH arg2
PUSH arg1
CALL func
PUSH命令の発行順とスタック上のリターンアドレスから見た順番が反対になります。
関数の呼び出し方法（つまりどのように機械語に翻訳するか）を呼び出し規約（主にx86のCPUで用いられている表現）といい、※2のような呼び出し方法をcdeclと呼びます。呼び出し規約はその他にPASCAL（文字通りPASCALで採用されている）とかstdcall（Windows-APIで採用）とかthiscall（C++のメンバ関数呼び出し）等があります。
メンバ関数の呼び出しでのスタックの使われ方
続いて、C++のメンバ関数呼び出しでのスタックの使われ方について説明します。
以下のC++でのメンバ関数の呼び出し時のスタックの使われ方の例を図2に示します。
object.method( arg1, arg2, arg3); // ------- ※3
図2
※3の擬似アセンブラコードを以下に示します。
※4 ※3の擬似アセンブラコード（thiscall呼び出し）
PUSH arg3
PUSH arg2
PUSH arg1
PUSH object
CALL method
違いは、object（正確にはobjectのアドレス）がthisポインタとして引数の一つとしてスタックに積まれていることです。その他の違いはありません。こうしてみるとオブジェクト指向というのは単純に
method( &object, arg1, arg2, arg3)
というコードを、
object.method( arg1, arg2, arg3)
という風に記述できる構文上の違いであるに過ぎないということに気づくかと思います。
ADPでは、この考え方を推し進めて、メソッド形式（メンバ関数呼び出しとほぼ同じ意味）として通常の述語形式での呼び出しとメソッドの呼び出しを混ぜて使うことができるようにしています。
ちなみに、私も含めて、多くのC言語の上級エンジニアがこのような見方をしてC言語からC++（オブジェクト指向）に移行していたかと思います。
もっとも、この話は、『仮想関数はどのように機械語に翻訳されるのか？』の話をしなければ終わりになりません。
次いで、仮想関数の呼び出しの話をします。
仮想関数の呼び出しでのスタックの使われ方
前節で説明したメンバ関数の呼び出しは従来の関数呼び出しの延長線上のものですが、ここでは、仮想関数と呼ばれるオブジェクト指向独特の呼び出し方法について説明します。
ちなみに仮想関数の説明自体は省略します（コメント欄でリクエストを頂ければ記事を追加するかもしれません）。 仮想関数の説明は次の記事で行います。
以下の仮想関数の呼び出しについて考えます。ちなみにスタックの構成は図2で仮想関数・通常のメンバ関数（非仮想関数）での違いはありません。
object.virtual_method( arg1, arg2, arg3); // ------- ※5
※5の擬似C++コードを以下に示します。
※6 ※5の擬似アセンブラコード（thiscall呼び出し）
PUSH arg3
PUSH arg2
PUSH arg1
PUSH object
MOV EAX, [object + vptr] ; ------------------- A
MOV EDX, [EAX + virtual_method_offset] ; ----- B
CALL EDX ; ------------------------------------ C
object + vptrなどや、EAX + virtual_method_number の部分がかなり曖昧ですが、エッセンスとして読んでいただければと思います。
※6のアセンブラコードではよく分からないかと思いますので、まずはオブジェクトのメモリレイアウトを図3に示します。
図3
vtableと呼ばれるテーブルに呼び出すべき仮想関数の場所（アドレス）が格納されています。
また各objectはvtableの場所（アドレス）を保持する変数（ポインタ）を持っています。
さらに、機械語の特徴のとして関数呼び出し（CALL命令）は、常に同じ場所（アドレス）の関数を呼び出すだけでなく、変数（レジスタ）を通して間接的に呼び出すこともできるようになっています。
以上を踏まえて再度、擬似アセンブラコードを説明しますと、
Aでは、vtableを参照しています。EAXとはレジスタというCPUが持っている変数になりますがそこへvtableのアドレス（vptr）を代入しています。[] というのはアセンブラでのポインタ参照（間接演算子 *）になります。
Bでは、virtual_methodの呼び出すべきアドレスを、EDXに代入します。このvirtual_method_offsetですが配列のインデックスのようなもので、図3では0ということになります。
最後のCのCALL命令が、A,Bを通して取得した呼び出すべき仮想関数の呼び出しを行っていることになります。
このように擬似アセンブラコードを通してみますと、説明は難しいですが、たったの2命令の追加で仮想関数呼び出しを実現しており、C++での仮想関数呼び出しというのはかなり効率的であることが分かります。
もともと、私はアセンブラが大好き（ハードウェアを直接制御できるので）だったのですが、時代に押されてC言語を使うようになりましたが、その理由の一つとしてC言語が高級アセンブラとして設計された（つまりこのように簡単にアセンブラに置き換えられる）から動作がよく理解しやすい面があったからで、その設計思想はC++にも引き継がれていることが分かります。
続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（３）』を書いてみます。
ADPの1周年記念特集のPart3です。『プログラミング言語の制御構造のいろいろ』ということで数回にわたって記事をアップします。ちなみに本日でちょうどADPの初回リリースから１年になります。
「なぜ、制御構造？」と思われるかもしれませんが、それはADP（Prolog）が持っている制御構造（バックトラック）が独特のものということと、JavaScriptやRubyにありますクロージャが本格的に普及してきて私自身が持っている制御構造に対する考え方（というか感覚）を変える必要があるので記事にしてみます。
制御構造とは
制御構造とはプログラムの流れ、広くはその命令（for文とかif文）を指します。制御構造を有名なものにしたのは、かのダイクストラ氏が提唱した構造化プログラミングがあります。今となっては『構造化プログラミング』という言葉を始めて聞いた人もいらっしゃるかと思いますが、『構造化プログラミング』が提唱された後に、今ではおなじみの制御構造文
・選択(if)
・反復（for,while等のループ）
が明確になりました。それまでの言語ではif文やfor文もありましたが充分でなく、本格的なプログラムの記述にはgoto文を使う必要がありました。そのれに加えてgoto文では様々なプログラムの流れを作ることが出来、流れの追いにくいいわゆるスパゲティプログラムというものもありました。私が駆け出しの頃（20年程前）にはよく可読性の悪いプログラムに対して『このスパゲティプログラムが～』という表現を聞いていました。
機械語ではどうしているのか？
なぜ、「機械語の話が出てくるのか？」と思われるかもしれませんが、制御構造の発展の歴史のルーツを探ることと、コンパイラ言語では制御構造が機械語に変換されるのでその仕組みを探るという意味で、続いて機械語の話をします。
機械語では初期のプログラミング言語のように比較文（if文）とgoto文のみで制御を行います。今となっては逆に難しいかもしれませんが、for文やwhile文がなくてもif文とgoto文の組み合わせでループを記述することが出来ます。
意外に思われるかもしれませんが、もう一つの制御構造文である関数呼び出し（サブルーチン呼び出し）も機械語にCALL命令という形で存在します。初期のCPUにはCALL命令がないものもあったらしいですが、今われわれが主に使っているパソコンのx86と呼ばれるCPUにもCALL命令があります。さらにx86の先祖をたどりますと、8080というパソコン用の8ビットCPUがありますが、そのCPUにもCALL命令があります（それから先は8008、4004とたどれますがこれらにCALL命令があるかどうかは不明です・・・）。
もちろんCALL命令が関数呼び出しとイコールではありません。CALL命令と関数呼び出しの違いは引数の受け渡しになります。CALL命令には引数の概念がありません。引数の受け渡しはレジスタまたはスタックまたはグローバル変数ということになります。C言語の関数呼び出しが機械語に翻訳されるるとCALL命令に翻訳されますが、その引数はスタックで渡されます。
続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（２）』を書いてみます。
以前にも、震災関連で何かお役に立てないかと思いとりあえず
電力量表示アプリとかを作ってみたのですが、さらになにかないか思っていましたら、
Hack For Japanでイベントをやっていると言うことで、5/22のハッカソンに行ってまいりました。
もともと、5/21にアイデアソンがあり、そこでプロジェクトの内容を詰めて、5/22に開発を行うのですが、どこかのプロジェクトのお手伝いをしようと思っていましたとこで、朝にプロジェクトの割り振りがあり、ちょうど２人しかいないとのことで、『だじゃれくらうど』に参加させて頂きました。
軽いノリで参加したのですが、『だじゃれと言えば私でしょう！』ということで参加してよかったかと思います。
で、このプロジェクトですが、後で知ったのですが、ニッポン放送さんの
app10という番組との共同開発企画ということで、その後ニッポン放送さんにおじゃまして打ち合わせしたり、２７日のapp10に出演（予定）だったりと思わぬところでプロジェクトが進んでいます。
たまにこういう企画に参加しますと、いろんなエンジニアの方と交流し色々な技術的な刺激を受けます。
Twitterからデータを拾うのですが、TwitteｒのAPIって『何にそれ？』ってなノリだったので、勉強にはなり、それはそれで楽しかったりします。
まぁ、今は時間的に余裕があるだけなのですが・・・。どこまでお手伝いが出来るかですが出来る範囲でがんばります。
もっとも、ということでモックアップをADPで開発してたりします。
5/22のハッカソンの写真です。
以前からSourceForge.JPさんで、ドキュメント執筆者とテスト担当者を募集しているのですが、残念ながら良い人が来なくて、自己顕示欲の強いというか思い込みの激しい人が来て手間ばかりかかって結局ご遠慮頂きましたということでそのレポートを。
こんなことはわざわざ書かなくてもよいかとも思いますが、こちらもドキュメントを書いて欲しいため、チャットまでして説明した手間もありせっかくなのでネタにしたいというのもありますし、また変な人がこられても困るのでその予防線と、一応開発日誌と銘打っているブログなのでこういうマイナスなことも隠さずに書くのも面白いかと思ったので書いてみます。
その方（以下Aさんとします）は、某大手のIT企業に勤めているらしいのですが（わざわざご自身で大手IT企業と言ってしまうところはどうかと思ったのですが）、ご自身でもプログラミング言語を作成しているとのことで互いに勉強にもなるかとも思いました。
何回かメールでのやり取りで、簡単な自己紹介、技術概要、開発方針、ドキュメント作成のポイント等を説明し、チャットでさらに補足説明をしました。
で、ドキュメント作成を行わなければならないのですが、Aさんは片手間にしか参加できないとのことで、レビューをやってもらおうとその旨をお伝えしたところ、Aさんから
『後、気になっているのは(もしもですが)参加者がたくさん増えたときに大藤さんの心構えが実はできているか？です。』
とのコメントを頂きました。私はオープンソースに対する心構ができていないとのことなのですが、そもそも『心構え』ということが理解できなくて、真意を確かめることも含めてまずは今回はご遠慮いただく旨のメールを送りました。そうすると、
『確かにメール受け取りました。想定通りの回答です。』
で始まり、
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
と来て、
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
『色々な人の意見を採り入れたいと言っていたが、まだその時期ではないのではと。』
と結論付けておられました。どう突っ込んだらよいのか困ったのですが、まぁ今回はご遠慮いただいてよかったかと思いました。
Aさんの勘違いを指摘しますと、私はADPをGPLで配布していますが、これは利用者が好き勝手にできることを私が認めたことになります。つまり、
『他の人に触らせること』
については私もライセンス上認めております。AさんはGPLをご存知ないのでしょうか。
また、『色々言われること』についてですが、実際にSkypeでAさんとチャットしているときも『Prologが解らない人向けのドキュメント作りを』と指摘されそりゃもっともだと思ったでのでSourceForgeのチケットにも登録しました。
もちろんですが、人の意見を聞きたいといっても、必然的に他の方の意見を取り入れる面と取り入れない面があります。その取捨選択はアーキテクトである私の仕事だと思っています。
もっともADPはプログラミングの初心者を対象としています。ので初心者の方の意見というは極力尊重したいです。ちなみにですが、PHPのようなお手軽な言語を目指しています。のでご意見どしどし受け付けています。
自分自身の若かりしころの反省も含めてITエンジニアの方にコメントしますと、他人とのコミュニケーションをとる上で相手の内面についての不用意な否定はやめた方がよろしいかと思います。Aさんは私に心構えという単語を使いましたが、根本的にオープンソースのプロジェクトをやろう！、という人間が心構えができていないことは、ほぼないです。
本当に心構えができていなくかつ教育が必要な新人を除いて、このような単語を使うことは相手を怒らせるくらいしかできません。もしくは相手から『こいつはコミュニケーション能力がない』と思われるでしょう。
これは仕事の面でもいえるかと思います。大手のIT企業に勤めていたら、出来の悪い協力会社の担当者に向かって思わず『やる気があるのか？』等、同様のことを言ってしまうこともあるかもしれませんが、そう思ったときはじっとこらえて『なぜ、私はこの人がやる気がないと感じたのか？』とじっくり自問自答しましょう。そのときに根拠となる理由が1つでは足りないですし、またその理由が思い込みではないと、確認する必要があります。
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
私の話のどこにそう思ったのか不明ですが、私がソースをオープンにし、GPLでリリースした時点で、ノーということはありえません。このように多角的な検証が必要です。
相手を批判する場合（相手の内面の場合は特に）、思い込みで論理を展開しないで自分の考えを吟味する必要があります。さらに、相手の置かれている立場や考え方も考慮に入れましょう。
私も若かりしころ上司から、『口のきき方が悪い』と怒られたりしたことがありましたが、そのときは何で怒られたかよく解っていませんでしたが、おそらくAさんのように思い込みが激しかったのかもしれません。
最近では、あまりこういう面で他人から指摘を受けることもなくなっていましたが、今度は自分が指摘をする番になったようです。
OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。
http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害
http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。
ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails
この記事の
7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと
一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。
ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。
かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話は
こちらで参照できます。また先の主張は、実際に
Ruby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。
このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、
『どちらでも良い』
というのが私の経験から来る見解になります。
この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。
私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。
今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。
というわけで、まぁブログビューアーは作り直さずに公開したいと思います。