変数は「箱」か「名札」か？― 初心者教育から束縛モデルまでを考える

　以前、「変数は箱か名札か？」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。

プログラミング教育の現場では、今も昔も「変数とは何か？」が最初のハードルです。
伝統的には「変数は値を入れる箱」と説明されますが、
最近では「変数はオブジェクトに貼られた名札（ラベル）だ」と主張する声も聞かれます。

一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。

Ⅰ. 初心者教育での「箱」モデルの意義

最初に登場するのが、もっとも直感的な「箱」モデルです。

変数とは、値を入れておく箱である。

a = 1
b = a
a = 2

このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。

C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。

Ⅱ. 「名札」モデルの登場と混乱

一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。

変数は、オブジェクトに貼る名札である。

a = [1, 2, 3]
b = a
a[0] = 9

ここで b を出力すると [9, 2, 3]。
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。

しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。

Ⅲ. C/C++が示す「共存モデル」

C や C++ では、値型と参照型（ポインタ型）が共存しています。

int a = 1;
int &r = a;

このとき r は a の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。

教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。

ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。

Ⅳ. 関数型言語における「束縛モデル」

さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値（あるいは式）に束縛される名前”だ」
という考え方が登場します。

束縛（binding）＝変数と式の対応を定めること。

Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。

x = 1
y = x + 2

このとき x や y は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。

この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。

Ⅴ. 束縛モデルの強みと限界

束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL（ドメイン固有言語）の分野では、
式構造を保持して解析・変換する必要があります。

しかしその一方で、束縛モデルには現実的な制約もあります。

項目 束縛モデル（遅延評価） 参照モデル（即時評価）
抽象性 高い 低いが直感的
実装効率 低い（オーバーヘッドあり） 高い
デバッグ 難しい（評価タイミング不明） 容易
メモリ予測 困難 明確

結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する設計を採用しています。

Ⅵ. 束縛モデルが主流にならなかった理由

    1. パフォーマンスとメモリ効率の問題
      遅延評価や式構造の保持にはコストがかかる。

    1. 最適化の困難さ
      コンパイラが静的解析しにくく、最適化しづらい。

    1. デバッグや可視化が難しい
      どの時点で評価されたかが分かりづらい。

    1. 実際に必要なケースが限られている
      自動微分やDSLなど一部領域に限定される。

Ⅶ. 現代的アプローチ：必要な部分だけ「束縛的」に

今日では、C# の Expression<T> や
Python の sympy / jax、
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。

つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。

Ⅷ. 教育的まとめ：段階的理解のすすめ

学習段階 目標 モデル 教育上の重点
初級 値の代入と操作の直感的理解 箱モデル シンプルな心象で理解する
プロ（中級） メモリと参照の関係を理解 箱＋参照モデル オブジェクト共有・ポインタ・参照
研究レベル 抽象的な束縛・遅延評価・純粋関数 束縛モデル 数理的抽象化・関数をデータとして扱う

Ⅸ. 結論：「名札」は“箱”を超えるものではない

「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。

しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。

実務的な観点から見れば、
「箱モデル＋参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。

最後に：比喩の目的を取り違えない

変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。

重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。

プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造（値 → 参照 → 束縛）を自然に昇っていけるように導くこと
なのかもしれません。

この文章は、ChatGPTとの共同作業により作られています。

マルチスレッド＆アセンブラプログラミングをしてみる（コラッツ予想のプログラム）

　多コアCPUのコアを使い切るにはどうするか？とここ数年考えていたのですが、そういえばコラッツ予想（3n+1問題）を確認するプログラムはちょうどよい例だと思いプログラムを作成してみました。

CollatzAsmについて

　せっかくなので64ビットアセンブラで作成し、128ビット（2の128乗）までの数を扱えるようにしました。ちなみに64ビットだと入力が数百億程度（35ビット程度）で内部の計算が桁あふれを起こします。
Visual Studio 2022(C++/Asm)で作成しています。ここからプロジェクトファイル一式をダウンロードできます。

　Visual C++ですが32ビットバージョンはインラインアセンブラが使えるので、お手軽にアセンブラを使えたのですが、64ビットになりなぜかインラインアセンブラをサポートしなくなりました。ということで約30年ぶりにアセンブラのソースコードを書きました。
ちなみに、16ビット時代はアセンブラプログラミングの参考書が豊富にあったのですが、64ビットになりあまり見当たらなくなりました。昔はミックスドランゲージといって、Cからアセンブラを呼び出す方法もよく解説をされていたのですが、今では、ここに資料があるくらいで、基本的なことが分かっている人じゃないと意味不明かと思われます。
詳しい解説はご希望があればやりますが、このプロジェクトをサンプルとしてもらえればと思います。

　また、このサンプルはC++14のマルチスレッドのサンプルにもなっています。長い間マルチスレッドプログラムと言えばOSのAPIかランタイム関数を使って作っていたのですが、C++14からプログラミング言語にサポートされたということで作成してみました。

実行例は以下のとおりとなります。

最初の引数で何処までの数を確認するかを入れ、2つ目の数は並列度（スレッド数）になります。
サンプルでは10になっていますが、当然コア数以上の値をいれます。32論理コアに対して100とかにしてもパフォーマンスが上がります(後述）。

CollatzAsmBenchについて

　アセンブラでのプログラミングに限った話ではないのですが、プログラムの最適化の過程で試行錯誤を行うことがあります。特にアセンブラでプログラムすると様々な命令を使うことができるのでそのバリエーションが増えるかと思います。
ということで試行錯誤の記録として10個程アセンブラのコードのパフォーマンスを比較するプログラムを書いてみました。
以下、実行結果になります。

ChatGPTの出力コードとの比較

　いわゆるバイブコーディングということで専用のツールも出てきていますが、コラッツ問題を扱うプログラムに関していうと、どこにでもあるのでChatGPTでも簡単なプロンプトでかなりいい感じのコードを出力しています。ということでChatGPTでプログラムを出力させてみました。、実際に試してみたところ可能でしたがあまり速度が変わらなかったので、今回はアセンブラでの出力はしていません。ChatGPTが作成したマルチスレッドのものを掲載します。

　私が作ったコードと比較するとマルチスレッドの初期化の取り扱いがうまいです（emplace_backを使っている）。一方で、データ長は64ビット止まりで、並列性も論理コア数に従ってスレッドを作成していますが（hardware_concurrencyメソッドを呼んでコア数を取得している）、このプログラムの場合、各スレッドの実行時間が必ずしも同じではないので、スレッド数をより多くして各スレッドのタスクを細かくした方が、実行時間のばらつきの減少が期待できます。一方で、一般論になるのですが、論理コア数以上のスレッドを実行させると各スレッドがCPUのリソースを食い合いすることになるので、実行スレッド数を論理コア数に合わせるのも一つの手になります。

　今回はアセンブラでは比較をしませんでしたが、CやC++のコードを単純にアセンブラにしてもあまり早くならないということもあります。一方で128ビットのような桁数の多い計算をさせる場合、アセンブラには桁あふれを処理する命令があり、CやC++で組むよりはるかに効率的なプログラムが記述できます。機会があればChatGPTでアセンブラプログラムの最適化を行いたいですが、↑の例にあるようにAIに任せるより、自分で工夫をした方が手っ取り早い面があります。もちろんですがアイデア出しをAIに頼ることもできますので、こういうことではあまりAIと人間の比較は意味がない（人間からしたらAIも利用する）ということになりますが、2025年9月現在、このあたりのチューニングはまだ人間の方に一日の長があるかと思います。（追記）この記事の公開後、１週間でClaudebotと名乗るロボットからZipファイルがダウンロードされたのでひょっとしたらClaudeにコードがパクられるかもしれません。

　最後に実行結果を

ということで、倍以上のパフォーマンスを示しています。逆にいうと倍程度にしかならないのですが、ある処理時間が半分になるということは2020年代のCPUの進化でいうとほぼ10年に相当します（この場合シングルスレッド性能の比較になる）。つまり上手くアセンブラでプログラムを書き直すことができればCPUの進化を１０年先取りできるとも言えます。CPUのシングルスレッド性能の向上が顕著だった90年代ですと概ね1，2年でパフォーマンスが倍になっていました。
余談ですが、アセンブラでのプログラミングは8ビットや16ビットの時代は割と一般的でした。90年代以降ではCPU自体の進化が早かった為、アセンブラでのプログラミングがエンコードなど、いわゆるSIMD命令を使うためとか、ニッチになった感がありました。CPUのシングルスレッド性の向上が見込めなくなった昨今、アセンブラでのプログラミングが見直されるかもしれません。
話を戻すと、コラッツ予想の確認プログラムの場合、スレッド数を100にしても性能が伸びていることを確認できます。これは、前述のとおり値により処理ステップにばらつきがあるためで、区間を細かくした方が（スレッド数を多くし多方が）、CPUから見た場合のトータル処理時間が平均化される為です。

Visual C++ 2022 でも regex の multiline はサポートしない

時が流れるのも早いもので、ADPの開発に使用しているコンパイラをVisual Studio 2012 に変えてから10年が経とうとしています。
途中、一度Visual Studio 2017 C++を試したのですが、regex がboostのモノと挙動が違うらしく（$を行末とするにはmultilineサポートが必要とのこと）、この時はVisual Studio 2012に戻した。

最近、OSをWindows 11に変えて、『いい加減コンパイラも変えるか』ということで、Visual Studio 2022 の C++に変えました。
ちなみにVisual Studio 2012 は Professional を購入しましたが、Visual Studio 2022 は Community版 をインストールしました。
まぁ仕事で使うようになったら Professional を購入します。
Visual Studio は 2003、2008、2012と一つ飛ばしで買っていましたが（2012は不本意ながら、2008がWindows8で動かなかったから買った記憶があります）、その後、Visual Studioを使うのも ADP と SQL Server 2012 の開発用となったので、特にバージョンアップをしないで、だらだらとしていたら気が付けば、2013、2015、2017、2019、と結構なスキップとなりました。

気が付けば、Gitに対応していたり、なかなかの変わりっぷりですが、C++の開発関係はあまり変わらずでよかったです。
もっとも、C++言語の方が、C++11、C++14、C++17、C++20 と今迄の停滞はなんだったんだというぐらいに変わっているので如何したものかと思う。
一部、最適化に関わる部分（右辺値参照とか）があるので無視するわけにはいかず、コード自体は今後、変えていこうかと思います。
ちなみに長く止まっていた、C言語の方もC11やらC17やらに対応しているらしく（単にプロジェクトのプロパティを見ただけ）、C言語に徐々に書き換えるのもありかと思う今日この頃です（現実的ではないですが）。

新しい規格への対応で、1点、期待していたものが regex がありました。ADPは boostライブラリの regex を使っていたのですが、そのregex がC++11から規格に入り C++17 ではmultilineをサポートしたものになっていました。あくまでも個人的な趣味もありますが、私的には $ を行末としたいのですが、それまでのC++ の 標準regexは$はあくまでも文字列の最後という扱いでした。multilineで$が行末とみなしてくれるようになります。
ということで、さっそく試してみたのですが、VC 2022 ではどうも、multilineに対応していないようでした。
「なんでやねん」ということで、色々検索してみましたが、以下、Microsoft のDeveloper Communityの投稿を見つけました。

multiline [C++]

同じようなことを感じた人が投稿したらしいのですが、Visual C++の開発者と思われる方のコメントで、要約すると『規格制定で色々あったのですが、現在のところABIの破壊がないようにするために、このような実装となっています。回避策として引き続きBoostのRegexを使ってください、その方が挙動が一貫しているだけでなくパフォーマンスも良いです（意訳）』とのことです。

BoostのセットアップがVisual C++の環境では面倒なのですが、Boostも一緒にバージョンアップし（1.45 → 1.80）Visual C++ 2022の環境に移行しました。ちなみにコンパイラを変えただけではパフォーマンスが変わることは特になかったです（AVX等の命令を使うように変えればまた違うかもしれませんが・・・）。

RYZEN

2020年もすっかり明けて２月になりましたが、年明けに１０年ぶりにPCを更新しました。
ちょうど１０年ほど前に、購入するPCの世代を統一しようと初代Core i7でソケット1366に決めたのですが、そこからCore i7-980Xを３つ程とi7-920を入手し４台のPCがあるわけですが、その後継ということでZEN2世代のRYZENに決めました。
Core i7を買ったときはちょうどWindows7に乗り換えた時でそこから8,10ときて、ここ2，3年は自分のPCがもっさりしていてグラフィックカードを変えたりしていましたがやっとこさ全とっかえができました。

今回はインテルからAMDに乗り換えたのですが、長いPC歴でちょこちょこAMDを使っています。今までメインマシンで使ったCPUを思い出すだけ書き出すと、こんな感じになります。

1984 （不明）ポケコンPB110
1985 uPD780(Z-80相当品) NEC
1989 80286相当品 AMD
1989 V30 NEC
1992 i486SX(J) Intel
1994 Am486 SX2-66 AMD
1996 Pentium 133 Intel
1997 MMX Pentium 166 Intel
1998 K6 AMD
1998 K6-2 AMD
1998 M2 Cyrix
1999 K6-III AMD
2000 Pentium III 600 Intel
2000 Pentium III 1000 Intel
2002 Celeron 1.4(PentiumIII系） Intel
2003 Celeron 2.3(Northwood-128K) Intel
2003 Pentium4(Northwood) Intel
2004 Athlon 64 3000+ AMD
2006 Pentium D 805 Intel
2006 Core 2 DUO E6400 Intel
2008 Xeon X3350(Core 2 Quad) Intel
2009 Core i7 – 920 Intel
2010 Core i7 – 980X Intel
2020 RYZEN9 3950X AMD

年号は大体ということで割といい加減です。その時の懐事情と趣味とその他諸事情で買い集めたり絞ったりしていましたが、こうしてみると2010年代のスキップぶりが半端ないですね。Core i7についてはSandy Bridge世代でそろえればよかったと少し後悔して、AMDからZenマイクロアーキテクチャが出る噂を聞きつけたときに様子見をしてZen2になったところで「行こう！」となった感じです。

話は戻って、初めての16ビット、32ビット、64ビットCPUは、AMDになります。初めての16ビットパソコンはPC-9801RXでしばらくはIntelを使っていると思っていたのですがあるときに中を開けてみたらAMDのCPUでした。よくよくカタログをみたら80286相当品と書かれていてものすごくがっかりした記憶があります。初めての32ビットCPUは、i486SX(J)と思いきや、このCPUは外部バス16ビットで、それを初めて知った時のがっかり感は半端なかったです。そのあとに買ったパソコンが今はなきコンパックのPresario CDS 524でこちらもメモリの増設で筐体を開けた時にみたらAMDでまたもやがっかりした記憶があります。その後、懐事情が改善し自作に移行して狂ったように買いましたが、初めてのDual-processor, Dual-core, Quad-core, Hexa-core はIntelになります。
RYZEN9は、初めての16-core（書き方を探すのが面倒）、PCI-E Ver4.0(Ver3.0はスキップ）、DDR4-RAM、UEFIです。利用面からは、初めてのCPUプロファイラ（AMDuProf）を使うプロセッサになります。CPUはキャッシュミスとか分岐予測ミスとかが発生すると内部のカウンタで記録をとるのですが、それを読み出すソフトウェアがCPUプロファイラということになります。有名どころではIntelのVTuneがあるのですがこのソフトがめっぽう高くCPUと合わせての購入となると個人では手が出しにくいです。AMDの方はなんと無料ということでまぁAMDということになりました。
そんなものを何に使うのか？と言われそうですが、もちろんADPのインタプリタ部分で、当初はVisualStudio付属のプロファイラを使って最適化を行っていましたが、いろいろ私に合わず、『V-Tuneかー』と思っていたところへ、CodeXL(AMDuProfの前身)の存在を知り、CodeXLに乗り換えたのが5年ほど前になります。CPUがIntelの場合、プロファイラは命令毎にかかった時間が分かるのですが具体的な原因（キャッシュミスなのか？ブランチペナルティか？とか）までは分からずそのあたりは手探りになっておったのがこれでばっちりと分かるようになります。早速プロファイルをしてみると、

パットと見てよくわからない指標があるのでカウンタの意味についてはお勉強が必要なようです。例えばハイライト部分はただの代入になるのですが、それでなぜRet branchとかが関係するのか？（おそらく他のブランチとの関係で結果的に実行された／なかったとか言いたいのかもしれないのですが・・・）とか直接的でないところがあります。

ここにきて、ADPの実行ファイルサイズは約1MBになりますが、今まではプログラムやデータのメモリへの配置はコンパイラに任せていましたがそろそろそういったところまでも手を出す必要があるのかなと思っています。といっても具体的にどうするのか？という話ですが、先ずCPUプロファイラを使いながら基礎データを集めてその上でソースコードを再編集したり、インタプリタ本体を抜き出してミニマムなプログラムを作ってプロファイルをかけたりいろいろ実験ができそうです。

ちなみにこういった話をすると『じゃアセンブラで組めや！』と言われかねないのですが、まぁうざい煽りに真面目に答えると、要は今のプログラムはCPUの潜在能力を十分に生かし切れていないので工夫の余地があり、上手くいけば数倍早いプログラムが作れるということになり、2020年現在ではシングルスレッド性能で数倍といえば時間軸に置き換えると10年以上先に行けるという話になります。

どういうことかと言いますと、例えば1989年に出たi486DX（33MHz）と2000年に出たPentiumIII(1GHz）の性能比は、単純にクロック周波数で見ても30倍（実際はそれ以上）になります。次いで2010年に出たCore i7-980X（3.33GHz、ブースト3.6GHｚ）とPentiumIII(1GHz)との性能比は、クロック周波数でみて約3.3-3.6倍と伸び率が10分の１程度に減速しています。そして今回のRYZEN9 3950X（3.5GHZブースト4.7GHZ）とCorei7-980Xはクロック周波数ではブースト時で比較して1.3倍、実際に手元にあるADPのプログラムを動かしてみると整数演算で2倍となっています。つまり、それまでは最新のCPUと言えば以前のCPUより格段に速くなって10年も経てば桁違いの速さを見せたのですが2000年代の中盤頃からそのスピードが止まり、今では10年で2倍のパフォーマンスアップに留まることになります。
つまり今まではプアなプログラムを組んでも時間が経てば解決してくれるのですが、これからはきちんと考えて作らないとダメということになります。

CPUプロファイルの話はこの辺にしておいて、今回もう一つ試したいことがあるのが、仮想マシンの活用で今回、私が使う必要のあるプログラムの一部（eTaxとか弥生会計とか）を仮想マシンの方へ移しました。今までは再セットアップとなるとこれらのソフトを再インストールしなければならなくなり面倒なだけなのですが、それが不要となり気軽に再セットアップができるようになるので便利です。欠点としてはOSやらその他のライセンスがインストールするマシンの台数分必要になることと、RYZEN9 3950X特有かもしれませんがCPUプロファイルとの共存ができない（切替にUEFIレベルで設定変更が必要になる）ことでCPUプロファイルを取りたいときはいちいちマシンを再起動することになります。

オブジェクト指向おじさん？

オブジェクト指向再考 連載目次

私の盟友（？）ことみながわさんの日記が更新されたので覗いてみた。2016年1月29日の記事によると、とあるWEBの記事「staticおじさん」はなぜ自信満々なのかというのが目につく。
この手の記事に対しての警鐘は以前にも行ったのだが、未だにこういう煽り記事が出てくるということは出版業界はよっぽど不景気なのか？と邪推したくなる。
アメリカに留学して習った単語にobjectiveというのがあり日本語訳は客観的で、反対語はsubjective（主観的）になります。論文を書くときは客観的であれといわれます。といっても何が主観で何が客観か分からないでしょう。本当かウソか分かりませんがアメリカではこのobjectiveということを子供の頃から教わるらしいです。もっとも子供の頃にそんなことを習ったことのない日本人は文章を読むときに、何が主観的か客観的かが判断がつかないこともあるでしょう。ちなみに何の説明もなしに『普通はこうだ』とか、他にも記事を読んで『俺の意見を代弁していてくれる』と思ったら、その記事は主観的である可能性があります（主観的の定義に従えば自明ですよね）。

さて、元の記事にあるこの部分

　Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。

これは、

インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり

と読み取れます。思わず普通ってなんやねん？と突っ込みたくなるのですが、
そろそろこのインスタンスメソッドを使うのが普通という誤謬を解きたいのですが、staticメソッドは場合によっては推奨されています。
期待するコードを期待するように書こうという本から引用させていただくと

クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ

このReadable codeという本は私は英語版を購入したのですがそこでも同様のことが書かれています。

また、英語が読める人は、static methodで検索をかければいろいろ議論を見ることができます。たとえば以下のQAたち
https://www.quora.com/Why-is-using-statics-Static-method-block-variable-in-Java-programming-bad-programming
http://programmers.stackexchange.com/questions/98083/cant-i-just-use-all-static-methods

ここでは、インスタンスメソッドを使うのが普通とか訳のわからん理由ではなくきちんと事実に則って議論がされています。
事実（fact)に則って議論するということは客観的(objective)な議論ができているということになるでしょう。

ざっくりとまとめますと、staticメソッドを使うと

欠点：継承ができなくなる。ポリモーフィズムも使えなくなる。
利点：メンバー変数へのアクセスを制限できる。パフォーマンスが上がる。

ということです。他のものは自明として、利点のところで『パフォーマンスが上がる』かは検証の必要があるのですが、ポリモーフィズムはオーバヘッドを発生させるのでそれを使わなければパフォーマンスがあがる可能性はあります。
また欠点の中で、『ややこしくなる』という意見もあったのですが、これは主観的な意見でしょう。たとえばstaticメソッドを使いなれた人はむしろすっきりとすると考るかもしれません。

さて、継承もポリモーフィズムも使わないということであれば、staticメソッドを使ってもよいということになるのですが、この反論として、『オブジェクト指向でなくなる』というのがあります。もはや手段と目的が混同されているとしか言いようがない意見でいやはや疲れます。
まぁ一介の無名なエンジニアが何をいっても仕方がないのでもっと説得力のある例を出しましょう。
επιστημη さんという著名なライターさんがいらっしゃいますが、彼は思い切りstatic メソッドを使っておられます。
http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx
のコードのrefereeクラスがそれに当たります。refereeクラスには3つのメソッドがありますが、すべてstaticメソッドになっています。
つまり、事実としてstaticメソッドは使うときは使うのです。ちなみにもちろんですが、επιστημη さんがオブジェクト指向を理解していないということはないでしょう。

という訳で、

　ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。

というヒマがあったら自身が思わぬ誤謬をしていないか記事の検証を行うことを勧めます。

2/4追記
コメント欄で文意を汲み取っていないという指摘を受けましたが、まぁ充分文意を汲み取って反論をしているのですがどうも分かりづらいかもしれないので、補足します。

　ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。

こういう教示的な文章は一見ごもっとなことのように受け取れますが、冷静に読めば分かりますとおり、ど素人でも同様のアドバイスができるでしょう（例を出すとサッカーや野球観戦をしているおっさんが野次っているさまと同じと言えば納得できるでしょうか？）。
社会人としては自分を律したり反省することは歳をとろうが若かろうが、技術者であろうがなかろうが、常に必要でいちいちアマチュアに指摘されることではないです。

そうはいっても100歩譲って、プログラミングに携わるプロが
『（引用先の記事に書かれてるニュアンスでの）自分はstaticおじさんではないか？』
と自問するということはどういうことでしょうか？
つまり、『staticは使えるのか？使えないのか？』という正に私がここで行っている議論をすることです。
そしてまさに

インスタンスメソッドを使う→普通
staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり

こういう意見が20年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。

2025/11/20 追記
すっかり放置していたブログですが、改めてアクセス解析をしたら、ほぼ10年前のこの記事で今でもそこそこのアクセスがあります。コメント欄についてはあまりにもレベルの低い書き込みがあったので承認制にしてコメント自体は落ち着いたのですが、皆様の参考になっているようで何よりです。
約10年ぶりに改めて幾つかの記事をアップしました。

 

HitAndBlow

ADPの開発が滞っていますが、思わぬところで話が進んでしまい、今年最後の記事になります。

社会人であり、技術者でありのコメント欄で結合について話が盛り上がったのですが、『私がHitAndBlowを作ったらどんなコードになるか？』ということで作成してみました。Visual C++ 2008で動作確認しました。
επιστημηさんの真似だと芸がないので、出題者・回答者をそれぞれ人間・コンピュータから選べるようにしました（大掃除をさぼったので嫁に怒られながら作りました・・・）。

それにしてもC++のコードは人によって個性が出ますね。


#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

class HABReferee {
    vector     answer;
    vector    blowtable;
public:
    bool prepareAnswer(const vector &answer_) {
        blowtable.assign(10, false);
        for ( size_t i = 0; i < answer_.size(); i++ ) {
            if ( blowtable[answer_[i]] ) {
                return false;
            }
            blowtable[answer_[i]] = true;
        }
        answer = answer_;
        return true;
    }

    bool submitAnswer( const vector submit, int &hit, int &blow) {
        if ( answer.size() != submit.size() ) return false;
        hit = 0;
        blow = 0;
        for ( size_t i = 0; i < submit.size(); i++ ) {
            if ( answer[i] == submit[i] ) {
                hit++;
            } else if ( blowtable[submit[i]] ) {
                blow++;
            }
        }
        return hit == submit.size();
    }
};

static vector inputNumbers(int N) { // N桁の数値の入力を行う（違った場合はやり直し）
    vector result;
    string str;
    do {
        result.clear();
        cin >> str;
        for ( size_t i = 0; i < str.size(); i++ ) {
            if ( isdigit(str[i]) && str[i] != '0' )
                result.push_back(str[i] - '0');
            else
                break;
        }
    } while ( result.size() != N );
    return result;
}

class HABContributor {    // 出題者（人間）
public:
    virtual vector prepareAnswser(int N) {
        cout << "各桁が1～9である" << N << "桁の数を入力してほしい。各桁で数が重複するのは避けてくれ" << endl;
        return inputNumbers(N);
    }
};

class HABContriburerComputer : public HABContributor {    // 出題者（乱数生成）
public:
    virtual vector prepareAnswser(int N) {
        vector digits;
        for ( int i = 1; i < 10; i++ ) {
            digits.push_back(i);
        }
        vector result;
        srand((unsigned int)time(0));
        for ( int i = 0; i < N; i++ ) {
            vector::iterator itor = digits.begin() + rand() % digits.size();
            result.push_back(*itor);
            digits.erase(itor);
        }
        return result;
    }
};


class HABSolver {    // 回答者（人間）
public:
    virtual void prepare(int N) {}

    virtual vector getAnswer(int N) {
        cout << "答えを予想してくれ" << N << "桁の数だ。" << endl;
        return inputNumbers(N);
    }

    virtual void giveHint( int hit, int blow) {
        cout << hit << "Hit" << " / " << blow << "blow" << endl;
    }
};

class HABSolverComputer : public HABSolver {    // 回答者（コンピューター）
    HABReferee           checker;
    vector>  candidate;
public:
    void recur(vector &answer, int N) {
        if ( N == 0 ) {
            candidate.push_back(answer);
        } else {
            for ( int i = 1; i < 10; i++ ) {
                if ( find( answer.begin(), answer.end(), i) == answer.end() ) {
                    answer.push_back(i);
                    recur( answer, N-1);
                    answer.pop_back();
                }
            }
        }
    }
    virtual void prepare(int N) {
        vector answer;
        recur( answer, N);
    }

    virtual vector getAnswer(int N) {
        cout << "答えは";
        for ( int i = 0; i < N; i++ ) {
            cout << candidate.back()[i];
        }
        cout << "かな？";
        return candidate.back();
    }

    virtual void giveHint( int hit, int blow) {
        HABSolver::giveHint( hit, blow);
        checker.prepareAnswer(candidate.back());
        for ( vector>::iterator i = candidate.begin(); i < candidate.end(); ) {
            int ahit, ablow;
            checker.submitAnswer( *i, ahit, ablow);
            if ( ahit != hit || ablow != blow ) {
                i = candidate.erase(i);
            } else {
                i++;
            }
        }

    }
};

class HABGame {
    int        N;
    HABReferee       referee;
    HABContributor   *c;
    HABSolver        *s;
public:
    HABGame(int N_, HABContributor *c_, HABSolver *s_) : N(N_), c(c_), s(s_) {};
    void play() {
        // 出題者から問題をもらいレフリーに渡す。
        while ( !referee.prepareAnswer(c->prepareAnswser(N)) )
            ; // 規格にあったものが出てくるまでループする

        bool endflag = false;
        int hit;
        int blow;
        s->prepare(N);    // 回答者に準備をさせる
        while ( endflag == false ) {
            // 回答者から回答をもらい判定する。
            endflag = referee.submitAnswer( s->getAnswer(N), hit, blow);
            // 回答者にヒントを言う。
            s->giveHint( hit, blow);
        }
    }
};

int main()
{
    HABContributor           hc;
    HABContriburerComputer   cc;
    HABSolver                hs;
    HABSolverComputer        cs;
    HABContributor           *c;
    HABSolver                *s;

    string    str;
    while ( true ) {
        cout << "メニュー" << endl
             << "1:出題者(Human) vs 回答者(Human)" << endl
             << "2:出題者(Human) vs 回答者(Computer)" << endl
             << "3:出題者(Computer) vs 回答者(Human)" << endl
             << "4:出題者(Computer) vs 回答者(Computer)" << endl
             << "0:終了" << endl;
        cin >> str;
        switch( str[0] ) {
            case '0' :
                return 0;
            case '1' :
                c = &hc;
                s = &hs;
                break;
            case '2' :
                c = &hc;
                s = &cs;
                break;
            case '3' :
                c = &cc;
                s = &hs;
                break;
            case '4' :
                c = &cc;
                s = &cs;
                break;
        }
        HABGame g(3, c, s);
        g.play();
    }

    return 0;
}

[ADP開発日誌-公開1周年記念特集 Part6] プログラミング言語の制御構造のいろいろ（4）

ちょっと余計な記事が入りましたが、続きを

C++の仮想関数の欠点

　話が少し前後しますが、Part4の記事でC++の仮想関数呼び出しの仕組みについて説明しましが、ここではC++の仮想関数の欠点について指摘します。C++ではvtableというメンバ関数のアドレスを集めたテーブルを用いて仮想関数の呼び出しを実現していました。この方式は効率がよいのですが『コンパイル時に呼び出すべき仮想関数が決定しなければならない』という弱点があります。
どういうことかといいますとC++でのメンバ関数呼び出し

　object.virtual_method( arg1, arg2, arg3)

という呼び出しで、virtual_methodというメンバ関数名はコンパイル時に参照されますが、実行時には内部的に振られた番号（vtableのインデックス）になります。つまり実行時にはこの名前は参照できません。と同時にvtableのインデックスを取得する手段もないので、実行時に呼び出すメンバ関数を選択したいということができません。
これの何が欠点かピンとこないかもしれませんが、例えば、バッチファイルからVBScriptを使ってExcelを操ったりしますが、この特にExcelのバージョンをあまり気にせずにExcelを操作（メソッドを呼び出す）するでしょう。これと同じことは、C++の仮想関数の仕組みではストレートに実装できないということです。Windowsでは皆さんご存知のとおり、COMという仕組みをOSに実装することで実行時に呼び出すメソッドを特定することを行っています。
COMというとえらく古いと思われるかもしれませんが、.NET Framkework からExcelを呼び出す場合もCOM相互運用性という仕組みを使って.NET Framework → COM → Excel という風に呼び出しいます。
話が脱線しますが、私は.NET Frameworkが廃れるのではないか？ と思っていますが、その理由のひとつが .NET FrameworkがCOMやOLE DB等のようにWindows APIを充分に置き換えていないと思えるところにあります（もっとも先のことは解りませんのでなんともいえませんが）。

関数の動的なロード＆実行の例

　　場合によって呼び出す関数を変える
というプログラミングテクニックは、オブジェクト指向プログラミング以外にもあります。典型的な例のひとつにデバイスドライバがあります。
デバイスドライバはご存知のとおりハードウェアとOSのAPIを橋渡しするソフトウェアでハードウェアに合わせて作成されています。ハードウェアを変えるとそれにあわせてデバイスドライバも変えます。
デバイスドライバはCで記述されることが多いです。最近のOSではPlag＆Playが一般的になりましたし、USB接続機器ではOSを再起動せずに、デバイスドライバがロードされます。このような動的なソフトウェアのロードの仕組みはどうなっているのでしょうか？

続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（５）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part5] プログラミング言語の制御構造のいろいろ（３）

Part3の記事が短く、Part4（前回の記事）が長かったりバランスが悪いですが、まぁBlogということでご容赦を。

メンバ関数呼び出し（thiscall）の補足

前回の記事にありましたメンバ関数の呼び出し規約（thiscall）について少し補足しますと、この呼び出し方法は一部のコンパイルで採用されているもので全てのコンパイラに当てはまりません。ちなみにVisual Studio 2008のC++コンパイラも違うやり方を採用しており、thisポインタをスタックに積むのではなくECXレジスタに代入します。thisポインタをECXに保存するとメンバ変数にアクセスする際に高速に処理が行えるのでこの方が効率的かと思います。
思い出話をしますと、Visual Stduioの昔のバージョンでは、thisポインタはスタックに積まれていたと記憶しています。ADPの高速化に際してアセンブラコードを読んでいて『なんか変だな・・・』という感じで調べるとVisual Stduio 2008ではこのようになっていると気づきました。

仮想関数とif文

前回の記事に「仮想関数の説明はしない｣と書きましたが、よくよく考えると仮想関数の仕組み（というか利用方法）を書かないと言いたいことが言えないことに気づきましたので書きます。

仮想関数の有効性を示す例を示します。
以下、C/C++の擬似コードになります。if文を用いてデータタイプを判定しデータタイプに応じた変換を行い、valueの内容を文字列に変換しています。

	char	buf[512];

	if ( value_type == int ) {
		sprintf( buf, "%d", value);
	} else if ( value_type == double ) {
		sprintf( buf, "%f", value);
	} else if ( value_type == char* ) {
		strcpy( buf, value);
	}

ここで、個別の変換処理（sprintfやらstrcpy）を仮想関数に置き換えます。

	virtual int::to_string(char *buf) {
		sprintf( buf, "%d", value);
	}

	virtual double::to_string(char *buf) {
		sprintf( buf, "%f", value);
	}

	virtual char*::to_string(char *buf) {
		strcpy( buf, value);
	}

呼び出し部分のコードは、以下のとおりになります。

	char	buf[512];
	value.to_string(buf);

仮想関数とはデータのタイプに合わせて実際のメンバ関数が呼び出される言語の機能になります。ここで、to_stringが仮想関数になり、実際に呼び出されるメンバ関数は、valueのデータタイプ(intやらchar*)に合わせて呼び出されることになります。ちなみにC++ではintやdoubleはクラスではないのでこのような仮想関数を作成することは出来ませんのであくまでも例になります。

仮想関数ですが、一見ややこしいですが、『データタイプに合わせて処理を行う』ような場合にはほぼ問題なく仮想関数に変換できるかと思います。ADPはC++で作成していますが、多くの場面で仮想関数を使っています。

例ではかなり端折っているので便利さが伝わりにくいですが、仮想関数を用いるとswitch文が減る（switch文もif文の一種と考えられる）といわれているとおり、今までif文が連なっていたコードが
value.to_string
とすっきりと記述出来るようになっています。重要な点はif文で書かれたコードブロックが to_string に置き換わり抽象度が上っていることです。抽象度が上がることが必ずしも可読性が増すわけではないですが、仮想関数を用いると呼び出し側のコードがすっきりとすることは分かるかと思います。

本記事のテーマである制御構造のいろいろという観点でみますと、仮想関数とはif文と関数呼び出しが混ざったものとも理解できます。

ちなみに、オブジェクト指向というとどうしても大きな括り（動物クラスとか社員クラスとか）の話になりますが、int型とかdouble型のような基本的な型でも行うことが出来、結構便利だったりします。C++では、intやdoube型ではメンバ関数を作ることが出来ませんが、Rubyのように使える言語もありますので試す価値はあります。またADPも同様なコードを記述することができます。

ADPのユニフィケーション（パターンマッチング）

前節で、仮想関数はif文と関数が混ざったものと説明しましたが、ADPでは関数呼び出し（述語の評価）に際しては、まずユニフィケーションが行われます。これは仮想関数を一般化しより強力かつ柔軟に呼び出すべき関数を選定できると考えることも出来ます。
ユニフィケーションについては、こちらを参照下さい。

続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（４）』を書いてみます。

[ADP開発日誌-公開1周年記念特集 Part4] プログラミング言語の制御構造のいろいろ（２）

前回からちょっと間が空いてしまいましたが、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の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周年記念特集記事として『プログラミング言語の制御構造のいろいろ（２）』を書いてみます。