ソースコードのmodularityの低さ(3)

C++の標準もどんどん進化している。それはそれで構わないのだが、古いバージョンのコンパイラ向けに書かれたコードは新しいバージョンでコンパイルできないという事態は起こりうる。そういう事態が起こったとき、プログラマは通例FDIS/ISではどちらが正しい実装なんだ？とか調べることになる。

まあ、それはそれで真摯な姿勢なのだとは思うけど、それ以前に考えんとあかんことがあるんちゃうの？VC++5用のコードがVC++6で、VC++6用のコードがVC++.NETでそのままコンパイル出来ないという事実には変わりないし、両方のコンパイラで動くコードを書くことはもちろん大切なことだし、複数のコンパイラでコンパイルが通るようにすることは現実的にはとても大切なことだろうけど、しかしやね、同じベンダーの同じコンパイラの異なるバージョンに対してさえコードの互換性はないってどういうことよ？そこには、上位互換性すらないのよ。おまけにlibファイルすらもフォーマットが変わろうとしている。

C++の標準がどんどん変革していき、それに伴い古いコードはコンパイルすら通らなくなる。globalなstatic変数は知らない間に廃止の方向に向かい、無名namespaceで代用することになっている。それはそれで構わないんだけど、そのツケをユーザーが背負わなければならない。5年とか10年ほど前のコードを引っ張り出してくると必ずコンパイルが通らなかったりする。そんな時、とてもやるせない気持ちになる。

C++は、標準の仕様があって、VC++6とかVC++.NETとかは、その実装の一つにすぎない。必ず標準に従ったプログラムを書いて、標準から外れているならそのソースをなおさなければならない。そうするのが常識のように思われているが、よく考えるとこれはとても馬鹿げている。それこそ、ソースとコンパイラをセットにして管理するのならば、そんな手間は不要になる。逆に言えば、そうしない限りは、いつまでもC++の標準にソースを追随させていかなければならない。これは尋常ならざる手間なのだ。

ソースコードを部品として再利用することを考えようにも、その部品を作る工場（コンパイラ）が破棄され、部品が作れなくなってしまうというのは、もうそもそも話にならない。部品以前の問題なのである。しかし、プログラマはコンパイラがバージョンアップするごとに自分のソースを新しいコンパイラに追随させる苦労を繰り返す。これは、まだこの先、5年も10年も続いてゆくだろう。そんなことが慣例として行なわれ、常識と思われている。そうしてみるとプログラマはよほど馬鹿なのか、非常識な連中だと言わざるを得ないだろう。もちろん、コンパイラを作っているわけでもない、単なるコンパイラユーザーにすぎない一介のプログラマにとって、そうする以外にどうしようもないという意味もあるのだが。