1980年代の登場以来，C++の人気は年々変化を遂げてきました。JavaやC#などマネージド言語の台頭，JavaScriptやPython，Rubyといったスクリプト言語の出現は，プログラム言語としてのC++の採用にも影響を与えています。しかしながらC++には，その制御性や言語自体の持つパワー，処理速度といった部分において，今でも多くの支持者が存在することも事実です。そのパワーがC++11では，これまで以上に効果的な方法でプログラマに提供されるようになるのです。そこで取り入れられた変更には，この言語が過去30年間，どれほど成長してきたかが示されています。C++11の参考資料を探しているプログラマ，あるいはC++の初学者ならば，C++ Primer 第５版を読んでみるとよいでしょう。Stanley B. Lippman，Josée Lajoie，Barbara E. Moo各氏による共著です。InfoQではその著者のひとりであるMoo氏に，新しい著書とC++言語全般について話を聞きました。
InfoQ: まず最初に，本書で採用されているアプローチについて伺いたいと思います。以前あなたが共著された "Accelerated C++" は， 標準ライブラリを中心としてC++を教育するというスタンスのものでした。今回のC++ Primer第５版でも同じスタイルを続けられていますね。それと比較すると，本書の第４版ではまったく違う方法 (CとC++) を採用しています。この話を伺ったのは，プログラム言語全般に加えて，C++11の導入に伴って必要となる変化をいかに伝えるか，という点において，今回のポリシーの変更には議論の余地があると思われるからです。今回の執筆陣は，どのような経緯でこのような方針を採用したのでしょうか？
Barbara: ありがとうございます。確かに私がAW(Addison Wesley)から Primer 第４版の話を頂けたのは，Accelerated C++ の成功ゆえのことだと思います。C++ Primer はC++のコミュニティにおいて，本当に重要な役割を担ってきました。最初に発行された1989年以来，C++の教育的入門書を真剣に求めるプログラマにとって，本書は多かれ少なかれ入門書の役割を果たしてきたのです。
C++ Primer の３版までの改訂は，言語仕様の変更に対応することが目的でした。例えば1998年に出版された第３版は，1998年のC++の標準化への対応を中心に改訂されたもので，新しい標準ライブラリが普及する前に出版されました。Accelerated C++ がライブラリを高度なトピックとしてではなく，言語と組合わせて教えることのメリットを実証してみせるよりも前のことだったのです。しかし第４版ではそれまでとは違って，教育方針の見直しがおもな目標になりました。Accelerated C++ と同じ教育アプローチを採用して，冒頭から意識的にライブラリを話題に取り入れるようにしたのです。残念なことに多くのC++書籍は，未だに配列やポインタをベースとした低レベルの機能を教えています。ライブラリは上級者用のトピックという扱いなのです。しかし配列やポインタの操作はエラーを起こしやすい上に，理解するのも簡単ではありません。さらに困ったことに，配列の操作を簡単に説明しようとして，固定サイズの配列を使うような悪習慣を教える書籍がとても多いのです。
stringクラスやvector型を使った方が，プログラムを書くのはずっと簡単です。ですからPrimerでは，このような型を早い段階で取り上げています。新しいC++ 11標準が完成に近づいたのを見て，私たちは，これと同じ方法で新機能を紹介することにしました。新しい機能を既存言語の上級者用トピックとして教えるのではなく，言語全体を統合されたものとして提示できるように，完全に書き直したのです。C++の新機能，特にautoやdecltype，範囲に基づくforループ，スマートポインタなどは，プログラムの記述を簡単にしてくれます。ですからこれらの機能を，他の基本機能と合わせて解説することにしました。
InfoQ: C++ 11標準で一番気に入っているのは，どの機能ですか？
Barbara: そうですね，先程の最後の部分ですでに答えてしまったかも知れません。autoとdecltypeという新しい型指定子を使えば，プログラマは長くて複雑な型定義を書いたり，どの型が必要なのかをプログラム中探し回ったりする苦労を強いられることなく，静的型付けのメリット(コンパイル時のエラー検出)を受けられるようになります。
スマートポインタを使えば，動的メモリを簡単かつ安全に使用できるようになります。ですが，それよりも大きなメリットは，リソースを管理するクラスの記述が簡単になることだと思います。(通常のポインタの代わりに)スマートポインタを使ったクラスには，代入演算子やコピーコンストラクタ，デストラクタなどを定義する必要がありません。つまりコピー管理について教えなくても，複雑なクラスを書けるようになるのです。
その他で気に入っているのは，新しいライブラリにあるbindやfunctionのような関数プログラミング機能ですね。とてもクリーンで，統一性のあるコードを書くことができます。それからラムダも，ライトウェイトな関数と考えてもいいものですが，標準アルゴリズムの動作のカスタマイズを簡単に行えるようにしてくれます。
多くのプログラマはその恩恵に気付かないかも知れませんが，それでも本当の意味で重要なものに，右辺値参照(rvalue reference)とムーブセマンティクス(move semantics)があります。オブジェクトをコピーする代わりに移動する機能は，ある種の限られたクラスで必要になるものです。実際のところ，ムーブセマンティクスの操作を直接記述するのは，かなりレベルの高いプログラマに限られることになるでしょう。それでもオブジェクトをコピーせずに移動させることが可能になれば，標準ライブラリのコンテナや文字列クラスのパフォーマンスが劇的に向上するかも知れません。
InfoQ: その他にも何かありますか？
Barbara: いいえ，特には。言語に制約検査を追加することについて，委員会がコンセプトの草案を作りましたが，今回は見送られています。設計が間に合っていませんでしたから，妥当な選択だったと思いますね。
InfoQ: 最近注目されている開発エリア (モバイル/ウェブ/クラウド) について考えたとき，C++は現在のソフトウェア開発にどの程度相応しいものだと考えていますか？プログラム言語はたくさんあって(Python / C#とJava / Go / その他)，その人気もさまざまですが，新たにプロジェクトをはじめようというとき，それらとC++とを比較してどう思われますか？(あるいは従来のC++コードベースでC++11を使う上で，何か問題はあるのでしょうか？)
Barbara: そうですね，他の言語は技術的にも，それ以外の面でも，多くの重要な点においてそれぞれが違っていますし，C++とも違います。Goについては詳しく知らないのですが，それ以外の言語はC++とは大きく違いますし，ターゲットとするアプリケーションも異なっています。パフォーマンスの制限が厳しかったり，移植性やハードウェアインターフェース，あるいはスケール性などを求められる大規模アプリケーションを開発する場合には，これらの言語はよい選択ではありません。反対にユーザとの対話が中心のアプリケーションを開発するのなら，この種の言語の中からどれかをひとつを選ぶでしょうね。
モバイルやウェブ，クラウドコンピューティングという具体的な質問について言うならば，C++はそのようなアプリケーションでも使用されています。(クラウドの)サーバを管理するためにも，それからもちろん，モバイルデバイス自体をコントロールするオペレーティングシステムにも使われています。ですから，コンピュータ産業の最新分野にもC++の利用範囲は広がっているのです。C++とPython，ちょっと違う部分もありますがJavaなどの言語と，C#やGoといった言語の間には，もうひとつ大きな違いがあります。前者のグループに属する言語がオープンな (Javaについて言えば，部分的にオープンな) 改良プロセスを備えている，と言う点です。その結果としてこのグループの言語は，さまざまなプラットフォームで利用可能なものになっています。もうひとつのグループは，そうではありません。特定のスポンサー企業がすべてを掌握しているのです。MicrosoftはC#をクロスプラットフォーム言語にしたいと思っているようですが，現実には同社のオペレーティングシステム上で実行されるプロジェクトでしか使われていません。同じようにGoはGoogleの言語ですし，Objective-CはAppleのiOSアプリ以外ではほとんど使用されていません。ひとつのプラットフォームに特定したアプリケーションを開発するのあれば，このような言語でもよいのですが，そうでなければ，他のハードウェアやオペレーティングシステムのサポートが必要になったときのことも考えておかなければなりません。
InfoQ: C++は３つの分離した言語 – スコープの概念を持たないCプリプロセッサ，C++ランタイム言語，それからコンパイルタイムのC++言語テンプレート – である，という見方があります。C++はこのようにセグメント化された言語なのでしょうか？だとすれば，それはどの程度問題なのでしょう？
Barbara: いいえ，そのような見方は極端だと思います。プリプロセッサは実際にありますし，C++言語自体と切り離されていることも事実です。ただし，#includeや条件コンパイルを除けば，C++でプリプロセッサを使用する理由はほとんどありません。80年代の中頃に，インラインとconstが導入されたからです。それによってほとんどのC++プログラマは，プリプロセッサを意識しなくなったのです。新たに追加された機能をマスタする必要もありません。
"ランタイム"と"コンパイルタイム"の区別について言えば，プログラマよりも言語のデザイナや実装者に対しての問題ではないかと思います。テンプレートでメタプログラミングを行っていれば別ですが，多くの，おそらくはほとんどのC++プログラマは，テンプレートと他の機能のどちらを使うか考えるときも，ランタイムとコンパイルタイムの違いを意識することはまったくありません。テンプレートに関してプログラマが意識するのは，コンパイルの最終段階になるまでエラーが表示されないことくらいでしょう。最初はびっくりするかも知れませんが，大した問題ではありません。それよりもっと大きな問題は，テンプレートをコンパイルしたときのエラーメッセージの内容でしょう！
InfoQ: C++に対して否定的な意見の中には，コンパイル時間の長さや，分かりにくいコンパイルエラーについて指摘しているものがあります。これらは本当に克服すべき課題だと思われますか，あるいは誇張に過ぎない (課題はいくつかあったとしても，解決する労力に見合うほど効果はない，ということです) のでしょうか？
Barbara: コンパイル時間に関しては，以前は今よりもずっと大きな問題だったと思っています。他のシステムソフトウェアと同じように，マシン速度が向上するにつれて，コンパイルの時間も短くなってきました。考えてみれば，1980年代半にC++を使い始めてから，マシンの速度は約1000倍にもなっているのです。システムの規模は1000倍にもなってはいませんから，C++のコンパイルが遅いと言われていた時代に比べれば，現在はずっと早くなっているはずです。もちろん，非常に大きなシステムに従事するチームには，コンパイル時間を短縮できるようなコード構成に配慮する必要があることに変わりはありません。残念ながらそれは，巨大プロジェクトを実施する上で避けられない問題だと思います。
InfoQ: 先回お話を伺った後に，Microsoftなどの参加する Standard C++ Foundation が発表されました。C++の採用に影響があったと思われますか？C++普及の中心として，迅速なリリースサイクルで新標準を提案しようという彼らの考えに対して，意見を聞かせてください。
Barbara: 先程の分かりにくいエラーメッセージの件ですが，私はテンプレート関連の処理におもな原因があると思っています。内部的に生成した名称でエラーを報告するのではなく，コード自体に記述されたことばでテンプレート関連のエラーを通知するように，コンパイラ開発者には努力を望みたいですね。Primerではおもにgccコンパイラを使用してコードをテストしたのですが，テンプレートベースのコードに関連するエラーメッセージは，コードの対象行を特定することはできても，どこが悪いのかを見つけるのにはほとんど役に立ちませんでした。これは認めざるを得ません。
Standrad C++ Foundationの影響については，まだ十分に分かっていません。何といっても始まったばかりですから。彼らの努力は称賛に値しますし，今後についても注目すべきサイトだと思っています。
回答者について
Barbara E. Moo氏は，ソフトウェアの分野で20年の経験を持つコンサルタントです。氏はAT&Tに在籍した約15年間，C++による初期の商用ソフトウェア開発に従事し，最初のC++コンパイラプロジェクトの管理を担当しました。またAT&Tが表彰を受けたWorldNetインターネットサービス事業では，開発の指揮も行っています。