第三接触
Bobby Schmidt
Microsoft Corporation
April 9, 2002
日本語版最終更新日 2002 年 6 月
おばあさんが群衆の中からよろよろ歩いて出てきました。
額に手を当て、そこからしばらく彼の顔をじっと見て、
「やっぱり! Rip Van Winkle だ! お帰りなさい。いったい、20 年間もどこにいたの?」と叫びました。
その間、誰もが驚いて立ちすくんでいました。
—Washington Irving 著『Rip Van Winkle』から引用
実際、20 か月近くたちました。しかし、何年もたっているような気がします。
1999 年 5 月に、「Deep C++」というプロジェクト名で MSDN のコラムを書き始めました。
翌年 7 月に、「Deep C#」というタイトルの同じようなシリーズを開始しました。
2 番目のシリーズが始まりそれほどたたないうちに、連載コラムが私の描いていた事態を完全に捕らえていないことに気がつきました。
C++ のコラムは、2000 年 9 月に 25 作目を書いた後に休止期間に入り、
2 か月後には、C# のコラムが休止期間に入りました。
天文用語で、"第三接触" は、
皆既日食の間に太陽が月の背後から姿を現す瞬間のことです。
「Deep C++」はちょうど今衰退した状態から抜け出しつつあるので、
この記事のタイトルとして天文用語を借用しました。
ただし、せいぜい 8 分しか続かない日食とは違って、
この衰退した状態は 1 年半以上続いていました。
その間、Microsoft の C++ コンパイラは、Microsoft® Visual C++® .NET のリリースによって、
何年もの衰退状態から抜け出しました。
コンパイラには、いわゆるマネージ コードをサポートするための多くの新しい拡張があり、
さらに、標準への準拠の控えめな改良点があります。
これらの変更、および、以下で説明する漠然としたその他の開発は、
再び活性化したこの「Deep C++」のタイミングとコンテンツの両方を刺激しました。
論理的根拠
以下は、3 年前の本当に最初の「Deep C++」のコラムから引用しています。
名前が示すとおり、このコラムでは個々のテクノロジではなく、C と C++ の言語そのものについて取り上げています。
私が今までに見たところ、プログラマはあまりにも簡単に、「クール」なテクノロジに飛びつく傾向があり、
テクノロジを成立させているのがプログラミング言語であることを忘れているようです。
このコラムの方針は、今までの MSDN の使命から外れているでしょうか? 私はそうは思いません。
表現手段の習熟度は、その手段を通した表現の質に直接的に反映します。
しかし、かなりの数のプログラマがその表現手段の仕組みについて不完全、または間違った知識を持っているようで、
欠陥だらけの設計や、場当たり的な実装という結果をもたらしています。
そのため、このコラムでは言語、つまり表現手段そのものについて取り上げたいと思います。
言語をテクノロジとしてではなく、言語は言語である姿勢は変わっていません。
変わったのは、Microsoft の C++ に基づいた実装と優先順位です。
衰退する前は、編集上の傾向は、ほぼ例外なく、標準への準拠に向かっていました。
ところが、現在、私の方針が 2 つに分かれていることに気がつきます。
- C++ 標準に準拠するプラットフォーム中立な機能。
- .NET Framework のマネージ プログラミング環境に準拠するプラットフォーム固有の機能。
なぜ、この 2 番目の機能があるのでしょうか?
.NET Framework はマイクロソフトに大きく関係しているので、
今のところ、その Framework 上での Visual C++ は、
だれもが納得できるところまでは至っていません。
きちんと注意を払わないと、
Microsoft® Visual Basic® と Visual C#™ は、
マイクロソフトが提供した .NET 用に単に "実在する" 言語だと考えてしまうでしょう。
危うく (不注意で) 中断した C# プロジェクトでもその考え方を進めていました。
しかし、Visual C++ チームと充実した時間を過ごした後、
現在は、この製品がマイクロソフトおよびその開発ユーザーにとって不可欠であることを十分確信しました。
さらに、テクノロジとしての Visual C++ と 言語としての標準 C++ の両方に、
密接で、いつまでも変わらない関係があることを確信しました。
マイクロソフトは、依然として営利目的の企業であり、慈善団体ではありません。
これらの関係が .NET 基づいた事業利益に役に立たない場合、
Visual C++ チームはその関係を維持しません。
すなわち、次のことが言えます。
- C++ を拡張して、マネージ プログラミングをシームレスにサポートすることによって、
Windows を使用する C++ プログラマに提供可能な.NET Framework を作成します。
- C++ 標準を完全に実装することによって、
別のプラットフォームを使用する C++ プログラマに提供可能な .NET Framework を作成します。
さて、どうでしょうか?
これら 2 つの利益は、思いがけなくも、私のコラムの方向性と合っています。
なんて運がいいんでしょう!
宇宙はこんなに広いのに信じられないない...とよく言われます。
確かに、どちらの利益も完全に理解するまでには及んでいません。
- C++ に対する既存のマネージ拡張は、まずまず役に立ちますが、不完全で、多くの場合扱いにくくなります。
- Visual C++ .NET の標準への準拠は Visual C++ 6.0 の標準への準拠より優れていますが、
標準のかなりの部分がまだ実装されていないままです。
マイクロソフトはこの辺りに費用を負担しますが、
私はこれらの制限を見過ごしません。
私の仕事は教育であり、考えを変えさせることではありません。
しかし、恐れることはありません!
これらの制限はいずれ解決されます。
現在の Visual C++ .NET のバージョンは、これまで目にした最新バージョンではありません。
マネージ拡張と標準への準拠は向上します。
そのため、これらの機能強化が実現されたときに、その機能強化についても説明しましょう。
対象読者、前提およびアプローチ
ある特定の対象読者、
言語中心で、標準に基づいた視点から Visual C++ .NET を理解して評価しようとする C++ プログラマに意図的に対象にしています。
これがあなたに当てはまらない場合は、すぐに終了して、代わりのものを探してください。
この対象読者に当てはまる場合、
以下の動機のうち少なくとも 1 つに当てはまることを前提とします。
- Visual C++ 6.0 (以降) を使用するので、Visual C++ .NET の新しい機能と修正事項について知りたい。
- 標準 C++ に関心があるので、Visual C++ の新しい標準への準拠の変更について知りたい。
- NET Framework のマネージ環境でプログラムを作成するので、C++ コンテキスト内のその環境について理解したい。
動機に関係なく、さらに以下のことを前提とします。
- 少なくとも中級レベルの専門知識を持つ C++ プログラマであること。
これは、特に、標準 C++ の C や ARM 時代の側面に精通しており、
ARM 以後に追加された機能に通じていることを意味します。
このシリーズでは C++ を教えるつもりはありません。
- .NET Framework のマネージ プログラミングの基礎を学んだことがあるか、学んでいること。
マネージ プログラミングを教えたり、
一般に C++ コンテキスト以外の Framework について説明しません。
これらのトピックについては、
Dr. GUI .NET への相談をスケジュールに入れる必要があります。
- Visual C++ .NET 製品版をインストールしていること。
コマンドライン環境が十分であること。
グラフィカル開発環境の参照、スクリーン ショットの表示、または UI シーケンスにしたがって説明することはしたくありません。
セットアップを独自に記述して教えているときは、IDE を動作させる必要がありません。
- Visual C++ .NET のヘルプ ファイルをインストールしていること。
- Usenet ニュースグループにアクセスできること。
前提とはしませんが、手近に見つかる別のオプション リソースが多少あります。
- ISO C++ 標準。
標準の参照と引用を行います。
この標準が手元にあると、すばらしいです。
たとえなくても、心配しないでください。
1) ひどく動作が遅い、2) タルムード学者の根気がいる、3) お金がかかるという理由により、C++ 標準を必要条件として扱いません。
- 『C/C++ Users Journal』 (CUJ)。
私は 1995 年から『CUJ』のコラムニストおよび補助編集員をしています。
3 年以上もの間、「Journal」の Q&A コラムを書いています。
特に、Visual C++ が標準に準拠する製品として注意を引き始めると、
(私はもちろん) 数人のコラムニストがそのコンパイラについてより頻繁に好意的に記事を書くことが予想されます。
ほかのコラムニストのうち 1 人は、C++ 標準化委員会会員の Herb Sutter 氏です。
彼は、最近、マイクロソフトの新しい C++ コミュニティとの連絡役として Visual C++ チームに雇われました。
Herb は、インタビューで新しい役割について説明しています。
このインタビューは、私の仕事をうまく裏付け、事前に示しています。
Visual C++ にまだ危機感を抱いている理由をすぐに理解したい場合は、Herb のインタビューをご覧ください。
- マイクロソフト以外の別の C++ コンパイラまたはトランスレータ。
私の知る限り、ほかのコンパイラは C++ のマネージ拡張を実装しません。
しかし、多くのほかのコンパイラは、C++ 標準をある程度まで実装します。
特に、そのコンパイラが Visual C++ .NET が実装するのとは別の標準動作を実装するときは、
これらのコンパイラの動作を参照することもあります。
標準 C++ に向かう私の姿勢により、
最初は C++ のエクスペリエンスとして、次に .NET のエクスペリエンスとして Visual C++ .NET を扱うでしょう。
- Visual C++ .NET がどのように C++ 標準を実装するかを示します。
- マネージ拡張が標準 C++ コンテキスト内部でどのように動作するかを示します。
- C++ コードをソース ストリームに挿入する Visual C++ の属性とその他の拡張の場合は、
元のソースを挿入したソースと対比して、挿入したソースを分析します。
- C++ のソース要素を中間言語翻訳にマップします。
- 標準 C++ ライブラリに関連して .NET Framework クラスをモデル化します。
- 標準 C++ ライブラリの機能を .NET Framework と同等の機能にマップします。
(この方法では、標準 C++ ライブラリ全体のドキュメント化というはっきりしない目標がありますが、それはまた別の話です。)
- 参照する C++ 用語のやや風刺的な用語集を維持していますが、コラムには関係ありません。
(1999 年にその用語集を始めましたが、コラムを休止してから更新していません。)
コミュニティ
このコラムは、コンテンツとコミュニティの両方に関するものです。
コミュニティをサポートするために、
MSDN の各コラムにはすべて独自のスレッドを持つディスカッションがあります。
公開する記事ごとに、その記事に付随するディスカッションを正確に読み取るでしょう。
折に触れてメッセージも投稿します。
ディスカッションでは、やや不当な制限を受けます。
上記の制限が原因で、コミュニティを別の方法で利用することを期待します。
おそらく、もっとも明白な別の方法は Usenet です。
その結果、以下の Usenet ニュースグループを監視したり、
場合によってはこのニュースグループに送信することを計画します。
定期的にこれらすべてのニュースグループに目を通していますが、
「Deep C++」ホーム コミュニティとして選定しているニュースグループは、
microsoft.public.dotnet.languages.vc です。
特に、「Deep C++」の記事がきっかけとなるメッセージや、
私のテーマの範囲と考え方に適切なメッセージを、
このニュースグループで探しています。
Developmentor の DOTNET メール リストにも再び加わりました。
C# プロジェクトが機能しなくなったときに上記の一覧をそのままにしておいたので、
現在、どの程度適切であるかわかりません。
気付いたことに応じて、メール リストを「Deep C++」コミュニティ バンクに追加することがあります。
あちこちに、その他の C++ コミュニティがあります。
もし見つけた場合はお知らせしましょう。
予告
今月、SD West 2002 が (カリフォルニアの) San Jose Convention Center で 4 月 22 日月曜日から開催されます。
カンファレンスは、26 日金曜日まで続き、同じ場所で Web Services World と同時に行われます。
(私はそれが何を意味するのかわかりませんが、マイクロソフトは SD West 2002 の "プラチナ スポンサー" として一覧されています。
現在、プラチナは高価かもしれませんが、それほど丈夫ではありません。
マイクロソフトは、ミスラル スポンサーまたはクリプトナイト スポンサーを要求する必要があったと思います。)
私は、オレゴンにいる Scott Meyers と彼の奥さんを訪問した後、San Jose まで車で行きます。
ショーでは、Dan Saks と同室し、
彼と Scott、さらにほかの産業界の著名人と過ごす予定です。
会わないのは Herb だけです。
彼は、オランダのアンティル諸島にあるキュラソー島というリゾート地で C++ 標準化委員会のミーティングに参加しています。
どのような成り行きで彼が犠牲になったのでしょう。
(何人かの人がこのように尋ねました。
私たちが Herb を仲間にしたということは、次に Scott を仲間に入れるということを意味するのではありませんか？
Scott は、採用できるかどうかどちらともいえない状態にあります。
彼はソロのロックスターという地位に慣れすぎて、バンドでリズムを取ることもできません。つまり、協調性がないのです。)
その週の火曜日までに、次のコラムを発表します。
公開スケジュールは月 2 回、第 2 火曜日と第 4 火曜日を予定しています。
最後に...
オンライン上でコラムが書けなくて非常に残念でした。
休止状態から得た喜びがあるとすれば、
それは新しい Visual C++ .NET が以前のバージョンにはなかった方法で私の興味をひくことです。
さらに嬉しいことに、将来のバージョンが大いに魅力的になることが完全に期待できます。
その他の点で良いほうに変化したことは、Visual C++ チームの位置付けです。
彼らの製品管理では、彼らが行ったとは本当に思えない方法で、標準および標準への準拠の利点を理解しています。
チーム メンバとの会話では、彼らが標準を信用しており、
かなり適合しているものとして、
そのコンパイラを推進しようとしていたことは明確ですが、
結局、別のより高レベルの条件によって彼らの念願はかないませんでした。
残念ながら、
私の知識と読者の考えの間には大きなギャップがあることがはっきりしています。
マイクロソフトにいる私たちが何を言ったとしても、
かなり多くの人は私たちを信じないでしょう。
悪の帝国に盲従し、
魂を売った嘘つきとして私たちを追い出そうとする人たちもいます。
私たちを信じようとする人もいることがありますが、
マイクロソフトが純粋に標準に準拠することに対する希望を捨てました。
(最近まで、私はこの 2 番目のグループにいました。といっても私自身を信じていませんでした。)
私が言おうとしていることは以下のことです。
仕様を参照しました。
テクノロジを使用しました。
Visual C++ チームの多くのメンバと一緒に時間を過ごしました。
各メンバは、全体的な関係をしっかりと承認しています。
同じことを確認したマイクロソフト以外の同業者が同様の反応に直面しました。
いずれにせよ、
私は Herb Sutter と顔見知りです。
あなたはこれほど誠実、上品、倫理的、清廉な人に会ったことがないでしょう。
彼が嘘をつけるかどうかさえ疑問です。
マイクロソフトは、C++ コミュニティの連絡役に彼以上に優れた人を見つけることはできないでしょう。
Herb の才能はもちろんのこと、現在連絡役がいるということは、多くのことを意味します。
何が起こるか彼がわくわくしているということも多くのことを意味します。
何を信じようと、それが何であり、それを信じる理由を教えてください。
スレッド化されたディスカッションやニュースグループ
(特に microsoft.public.dotnet.languages.vc) を使用して、互いに、マイクロソフト、そして私と話しましょう。
最後にさびついてしまった著者としての能力を回復して、
このコラムを活性化するにはどうすればよいかを断言することはできません。
ラジオ DJ をしていた頃に、
精神的に不安定になったことが原因で数か月間その仕事から離れていたときがあったことを思い出します。
DJ のマイクの前に戻ることは、個人向けの療法の一環でした。
MSDN の作者としてキーボードの前に戻ることも同じくらいよい気分になります。
あるべき場所に再び身を落ち着けることはすばらしいことです。
Deep C++ .NET
|
