【ITニュース解説】C++を使った数値計算ライブラリの整備で辛かったこと

C++を使った数値計算ライブラリの開発は、複雑な数学的処理を効率よく行うための基盤を作る重要な作業だ。システムエンジニアを目指す上では、このようなライブラリがどのように開発されるのか、その過程でどのような課題があるのかを理解することは、プログラミング言語の特性や開発の難しさ、工夫について深く学ぶ良い機会となる。今回紹介する記事では、C++で数値計算ライブラリを開発してきた経験から、特に何が大変だったのかが語られているが、これはC++という言語を批判する意図で書かれたものではなく、あくまで開発経験の共有として提供されている。

記事の著者が特に辛かったと述べているのは、「標準的なパッケージマネージャー、コンパイラー、ビルドシステムの不在」という点だ。これらは、ソフトウェア開発において非常に重要な役割を果たす要素であり、それらがC++においては統一されていないことが、開発における大きな課題となっている。

まず、「標準的なパッケージマネージャーの不在」について説明する。ソフトウェア開発では、多くの場合、ゼロからすべてのコードを書くのではなく、すでに作成されている便利なプログラム部品（これをライブラリと呼ぶ）を組み合わせて開発を進める。パッケージマネージャーとは、これらのライブラリを簡単に見つけ、ダウンロードし、自分のプロジェクトで使えるように設定するための仕組みを提供するツールのことだ。スマートフォンのアプリストアのようなものと考えると理解しやすいだろう。他の多くのプログラミング言語、例えばPython、Julia、Rustなどには、その言語専用の標準的なパッケージマネージャーが存在する。これは開発者にとって非常に大きなメリットであり、必要なライブラリを探したり、そのライブラリがさらに別のライブラリに依存している場合（これを「依存関係」と呼ぶ）、それらすべてを自動で解決してくれるため、開発者は本来のプログラム開発に集中できる。しかしC++には、このようなコミュニティ全体で広く使われる「標準的な」パッケージマネージャーが存在しない。Conan、vcpkg、hunter、CMake FetchContentなど、いくつかの選択肢はあるものの、どれか一つがデファクトスタンダード（事実上の標準）とは言えない状況だ。この不在が引き起こす問題として、まず自分の開発しているライブラリを機能ごとに小さな部品に分割しにくいという点がある。特定の計算処理を独立したライブラリとして提供したい場合、そのライブラリが依存する他の部品をどう管理するかを、開発者自身が考え、実装する必要が出てくる。結果として、複数のライブラリで共通して使いたい機能があっても、それを簡単に共有できず、それぞれのライブラリに同じコードをコピーしてしまったり、非常に大きな一つのライブラリとして開発せざるを得なくなったりすることがある。つまり、部品の再利用や管理が非常に難しくなってしまうのだ。

次に、「コンパイラーの不在」について解説する。コンパイラーとは、人間が書いたプログラムの命令（ソースコード）を、コンピューターが直接理解して実行できる形（機械語）に翻訳してくれるソフトウェアのことだ。例えるなら、日本語の指示書を英語の指示書に翻訳する翻訳家のような役割を担う。C++には、標準とされる単一のコンパイラーがなく、主にGCC、Clang、MSVCといった複数の主要なコンパイラーが存在する。これらのコンパイラーは、C++の仕様に沿って動作するものの、完全に同じではない。具体的には、特定のコンパイラーでしか正しく動作しないコードが存在したり、同じコードでもコンパイラーによって警告の出方が異なったり、プログラムの実行速度を決める「最適化」の結果が異なる場合がある。特に、CPUが複数の計算を同時に実行する能力（SIMD命令）を最大限に活用するような高度な数値計算ライブラリでは、コンパイラーごとの挙動の違いが顕著に現れることがある。開発者は、自分のライブラリがどのコンパイラーのどのバージョンで動作するようにするかを常に意識し、テストする必要がある。また、ライブラリを利用するユーザーも様々なコンパイラーを使っているため、開発者はそれらの環境すべてで問題なく動くように配慮しなければならない。開発チーム内で使うコンパイラーを統一できたとしても、ライブラリの利用者までは統一できないため、この問題は非常に根深く、多くの手間と時間を要する原因となる。PythonやJuliaのような言語では、言語の処理系自体がコンパイラーの役割も担うことが多く、このような問題は比較的少ない。

最後に、「ビルドシステムの不在」について説明する。ビルドシステムとは、ソースコードをコンパイルするだけでなく、複数のファイルを連結したり、必要な設定ファイルを配置したりして、最終的に実行可能なプログラムやライブラリを作り上げるまでの一連の作業を自動化するためのツールだ。ちょうど、料理のレシピと調理器具一式のようなもので、材料（ソースコード）から完成品（実行可能なプログラム）を作り出す手順を定義し、実行する。C++には、CMake、Make、Ninja、Bazelなど、多数のビルドシステムが存在するが、これも標準とされるものは一つもない。C++のビルドシステムは、その機能の豊富さゆえに非常に複雑で、習得するのに時間がかかることが多い。開発者は、自分のプロジェクトに合ったビルドシステムを選び、その設定をイチから設計する必要がある。これは、コンパイラーの選択、使用するライブラリの依存関係、さらにはWindows、Linux、macOSといった異なるOS（オペレーティングシステム）でプログラムが動作するようにする「クロスプラットフォーム開発」を考慮する必要があるため、非常に大きな労力となる。他のプログラミング言語では、ビルドシステムが言語に組み込まれていたり、事実上の標準となるものが存在したりするため、開発者はビルド方法について深く考えることなく、すぐに開発を始められることが多い。しかしC++では、プログラムの機能開発とは別に、このビルドシステムを設計・管理するだけでも、かなりの時間と専門知識が求められるのだ。

C++での数値計算ライブラリ開発において、著者が辛いと感じたのは、ソフトウェア開発の基盤となる「パッケージマネージャー」「コンパイラー」「ビルドシステム」という重要な要素が、他の言語のように標準化されておらず、選択肢が多く、それぞれに互換性の問題や学習コストがある点である。これはC++という言語が持つ柔軟性や強力な性能の裏返しとも言えるが、その一方で、開発者にとっては、本来のプログラム機能開発以外の部分で多くの手間や専門知識が求められるという課題を示している。システムエンジニアを目指す上では、このようなプログラミング言語ごとの開発環境の違いを理解し、その特性を把握することが、効率的かつ安定したソフトウェア開発に繋がるだろう。