特集

Vista時代のVisual C++の流儀（後編）

STL/CLRによるDocument／Viewアーキテクチャ

STL（Standard Template Library）の新バージョンが導入されます。このバージョンのSTLは、マネージ・コードやデータと相互作用するようにチューニングされています。従来のC++アプリケーションの作成にSTLを使い慣れているプログラマーは、CLRベースのアプリケーションにも同じ技法を適用できることが分かります。

Visual C++ 2005では、標準テンプレートライブラリ（STL）が.NET Frameworkで使用できるように再設計されています。シリーズの第1回となる今回は、STL.NETの概要を紹介します。

STL.NETの詳細に入る前に、ある意味避けては通れない疑問があります。Visual C++プログラマーが、System::Collections（名前空間*）やSystem::Collections::Generic（名前空間*）などの、言語に依存しない（.NET標準の*）クラス・ライブラリの代わりに、STL.NETコンテナ・ライブラリを使用するメリットはどこにあるのでしょうか。

一般に、System::Collectionsライブラリはまっ先に選択肢から外れます。その理由は、Visual Studio 2005でGeneric（ジェネリック*）ライブラリが用意されることになった理由と同じです。すなわち、パラメータ化のオブジェクト・モデルが複雑であり、型情報が失われるため安全でないからです。単純な用途については問題ありません。これは、要素数が16以下のコンテナではバブル・ソートを使用しても問題にならないのと同じです。しかし、アプリケーションで現実的な問題に対処するには、より洗練されたソリューションが必要になります。

従って、Visual C++のようなシステム・プログラミング言語にとっての選択肢は、STL.NETとSystem::Collections::Genericライブラリのいずれかになります。では、Visual C++プログラマーがこの2つのうちSTL.NETを選択する理由はどこにあるのでしょうか。また、STL.NETを選択するとして、プログラムがほかの.NET言語から孤立する心配はないのでしょうか。これらは当然の疑問であり、ここで取り上げる価値があります。

1つ目の答えは、拡張性です。Alex Stepanov氏によって考案されたSTLのオリジナル・デザイン・パターンでは、アルゴリズムとコンテナが別のドメイン空間に分離されています。従って、すべてのコンテナに適用できるアルゴリズムを追加したり、アルゴリズムを適用できるコンテナを追加したりできます。これに比べると、Genericライブラリは従来のコンテナ・モデルに近いといえます。このことは、2つ目の答えにもつながります。

2つ目の答えは、統一性です。現役のC++プログラマーがこれまでに築き上げてきたものは、既存のコードばかりではありません。STLライブラリを使ったプログラミングのノウハウも大事な資産です。私たちは、既存のコードだけでなくそうしたノウハウも移行できるようにしたいと考えています。それまでSTLを利用してきたC++プログラマーにとって（STLを利用していない現役のC++プログラマーはまずいないでしょう）、.NETでそれを利用できないことは大きなマイナスです。少なくとも、筆者はそう感じてきました。これについては、多くの熟練C++プログラマーから懸念の声が上がっており、彼らが.NETへの移行を見合わせる理由となっています。

3つ目の答えは、パフォーマンスです。しかし、C++プログラマーはパフォーマンスの問題にうるさいことで有名なので、ここでこの問題に踏み込むのはやめて、後の記事で取り上げることにします。

最後に、STL.NETは確かに素晴らしいが、それを使用することによってC++プログラマーやC++/CLIプログラマーが.NETコミュニティから孤立するのではないか、という疑問にお答えしておきましょう。その答えはノーです。私はそう思っています。この問題については、Anson Tsao、Martyn Lovell、P.J. PlaugerをはじめとするSTL.NETのアーキテクトが徹底的な調査を行っており、IEnumerator、IList、およびICollection（などのインターフェイス*）のサポートを通じてほかの.NET言語との互換性を確保できるようになっています。これについては、後の記事である程度詳しく取り上げる予定です。