連載:C# 2.0入門最終回 小さな改善とコンパイラの新機能、そして3.0への展望株式会社ピーデー 川俣 晶2008/01/11 |
|
|
C#コンパイラの新機能
C#コンパイラにもいくつか新機能が用意されている。
コンパイラをコマンドラインから起動するオプションとして指定できるほか、一部はVisual Studioからプロジェクトのプロパティとして変更できる。
以下、それらを簡単にまとめてみよう。
■/errorreportオプション
C#コンパイラがソース・コードを処理できない場合に発生する内部コンパイラ・エラー(ICE:Internal Compiler Error)をマイクロソフトに報告する方法を指定する。
このICEというのは、プログラマーがソース・コードを書き間違ったことで発生するコンパイル・エラーのことではなく、コンパイラ自身が処理を継続できない状態に陥ったことを示す。これは、コンパイラそのもののバグや、言語仕様の不整合などによって発生し得るものだと思われる。C#は、言語仕様そのものがシンプルに単純化されていないので、このような問題が比較的起こりやすいのかもしれない。その場合の対処は、コンパイラの修正や言語仕様の修正であるので、対処はマイクロソフトにしかできない。そのため、エラーの報告をいかにしてマイクロソフトに送るか……という選択肢しか存在しない。
このオプションで指定できる値は以下の4種類である。
| ||||||||||
/errorreportオプションで指定できる値 | ||||||||||
Visual Studio上で、プロジェクトのプロパティを使って設定を変更するには[ビルド]タブの[詳細設定]ボタン→[内部コンパイル エラー報告]ドロップダウンを使用する。
以上、長く説明を行ったが、このようなエラーに遭遇する頻度は決して高いものではない。筆者も、かなりC#のソースを書いたが、遭遇したという明瞭な記憶はない。遭遇するまで忘れていても構わない機能だろう。
■/incrementalオプションの削除
変更個所だけをコンパイルする、インクリメンタル・コンパイル機能のオン/オフを指定する/incrementalオプションは削除された。
■/keycontainerオプションと/keyfileオプション
/keycontainerオプションは、暗号化キー・コンテナの名前を指定する。コンパイラは、指定されたコンテナに格納された公開キーをアセンブリのマニフェストに追加し、最終的なアセンブリを秘密キーで署名することによって、共有可能なコンポーネントを生成する。
「/target:module」を使用してコンパイルすると、キー・ファイル名はモジュールに保持され、/addmoduleオプションを使用してこのモジュールをコンパイルするときに作成されるアセンブリに組み込まれる。
このオプションに相当する方法は、任意のソース・コード上でカスタム属性(System.Reflection名前空間のAssemblyKeyName属性)として指定することもできる。Visual Studioのプロジェクトのプロパティから指定することはできない。
一方、/keyfileオプションは、暗号化キーの格納されたファイル名を指定する。このオプションを使用すると、コンパイラによって指定したファイルに格納されている公開キーがアセンブリ・マニフェストに対して追加され、最終的なアセンブリが秘密キーで署名される。
Visual Studio上で、プロジェクトのプロパティを使って設定を変更するには[署名]タブの[アセンブリの署名]チェックボックスと[厳密な名前のキー ファイルを選択してください]ドロップダウンを使用する。
■/langversionオプション
受け付ける言語仕様の範囲を変更する。指定可能な値は以下の2種類となる。
|
||||||
/langversionオプションで指定できる値 | ||||||
ちなみに、Visual Studio 2008のC#コンパイラでは“ISO-2”も指定でき、「ISO/IEC 23270:2006」*に含まれていない構文をエラーとする。
* http://standards.iso.org/ittf/PubliclyAvailableStandards/index.htmlからダウンロード可能。 |
このような機能から分かるとおり、この/langversionオプションはC# 2.0コンパイラをC# 1.xコンパイラとして使用するような用途を想定したものではなく、国際規格であるISO/IEC規格に適合するソース・コードを利用するための機能と考えるべきだろう。
Visual Studio上で、プロジェクトのプロパティを使って設定を変更するには[ビルド]タブの[詳細設定]ボタン→[言語バージョン]ドロップダウンを使用する。
■/linkresourceオプション
前バージョンから存在するオプションだが、リソースのアクセシビリティを指定する機能が追加されている。以下のように、リソース・ファイル名、リソースの論理名の後にカンマで区切って「public」または「private」を記述してアクセシビリティを指定できる。
|
ちなみに、既定値は「public」となる。Visual Studioのプロジェクトのプロパティで指定することはできない。
■/moduleassemblynameオプション
モジュールを作成する際、外部のアセンブリからフレンド・アセンブリ(第7回参照)として参照される名前を指定する。ただし、このオプションはフレンド・アセンブリの機能を使用するために必須というわけではない。
このオプションを正しく理解するには、.NET Frameworkの世界において、アセンブリとモジュールは別個の存在であることを把握しなければならない。アセンブリは通常「.exe」や「.dll」の拡張子を持っているが、モジュールは「.netmodule」という長い拡張子を持つ。そして、モジュールはアセンブリの構成要素として取り込むことができる。C#コンパイラは、「/target:module」を指定することで、モジュールを作成することができ、そのモジュールは「/addmodule:ファイル名」というオプション指定によって、アセンブリに取り込むことができる。
さて、この機能性はフレンド・アセンブリとモジュールの作成に決定的な問題を生じさせる。なぜかといえば、第7回で解説したInternalsVisibleTo属性はアセンブリの名前を指定するにもかかわらず、モジュール単位でコンパイルする場合、コンパイル時にアセンブリの名前が確定できないからである。アセンブリの名前が決まっていなければ、いくらInternalsVisibleTo属性でアセンブリの名前を指定しても、許可が成立しない。
そこで、このオプションを使用して「そのモジュールが将来属するはずのアセンブリの名前」を指定するわけである。これによって、モジュール単位でコンパイルする場合にも、フレンド・アセンブリの機能性を利用することが可能となる。
なお、これに相当する機能はVisual Studioのプロジェクトのプロパティで指定することはできないが、そもそもVisual Studioではモジュール単位でコンパイルを行わない(行えない)ので、特に問題はないだろう。
■/pdbオプション
デバッグ情報ファイル(拡張子「.pdb」)は、通常、出力ファイル(.exeファイルまたは.dllファイル)が作成されるのと同じディレクトリに、出力ファイルと同じ名前で作成される。このオプションはそれを任意のパスに変更する。
Visual Studioのプロジェクトのプロパティで指定することはできない。
■/platformオプション
プログラムの実行対象となるプラットフォームを指定する。値としてはx86、Itanium、x64、anycpuを指定でき、anycpuが既定値となる。
本来、仮想マシン語の一種であるMSILの世界では、CPUの種類は関係がないはずである。しかし、32bit版のCLRと64bit版のCLRでは確保できる最大メモリが異なったり、参照のために消費するメモリ容量が異なったりするなど、実行環境の相違がプログラムの実行に影響を及ぼすことも考えられる。
このことは、特に64bit環境で顕著な問題となる。なぜなら、64bit環境の上では、プログラムを64bit版CLRとWOW64*環境の32bit版CLRの双方で実行できる可能性があるためである。
* Windows on Windows 64。64bit版のWindowsで32bit版のアプリケーションをそのまま動作させるための仕組み。 |
このような状況では、/platformオプションを使用することで、ある程度どのCLRで実行されるかを指定することができる。
以下は/platformオプションのドキュメントに記述された実行環境の選択条件である。
- /platform:x86を指定してコンパイルしたアセンブリは、WOW64環境の32bit CLR上で実行されます
- /platform:anycpuを指定してコンパイルした実行可能ファイルは、64bit CLR上で実行されます
- /platform:anycpuを指定してコンパイルしたDLLは、読み込み先のプロセスと同じCLR上で実行されます
Visual Studio上で、プロジェクトのプロパティを使って設定を変更するには[ビルド]タブの[プラットフォーム ターゲット]ドロップダウンを使用する。ただし、Express Editionではこの機能は使用できない。
INDEX | ||
C# 2.0入門 | ||
最終回 小さな改善とコンパイラの新機能、そして3.0への展望 | ||
1.固定サイズ・バッファ/volatileキーワード/#pragma warning | ||
2.C#コンパイラの新機能 | ||
3.C# 1.xから2.0への進化とは/C# 2.0から3.0への展望 | ||
「C# 2.0入門」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|