条件が増えると、#if‐#else‐#endifだけで記述すると込み入ってしまう場合がある。そういう場合のために#elifが用意されている。これは、#elseの機能と#ifの機能が合体したものである。List 19-8はそれを用いた例である。
1: #define MY_SYMBOL2
2: using System;
3:
4: namespace Sample008
5: {
6: class Class1
7: {
8: [STAThread]
9: static void Main(string[] args)
10: {
11: #if MY_SYMBOL1
12: Console.WriteLine("MY_SYMBOL1");
13: #elif MY_SYMBOL2
14: Console.WriteLine("MY_SYMBOL2");
15: #elif MY_SYMBOL3
16: Console.WriteLine("MY_SYMBOL3");
17: #else
18: Console.WriteLine("no symbols");
19: #endif
20: }
21: }
22: }
これを実行するとFig.19-10のようになる。
複数条件で#if‐#else‐#endifを使う場合、#ifを1回記述するごとに、それに対応する#endifを記述しなければならない。つまり、#ifで判定すべき条件が3個あれば、#endifも3個必要になる。しかし、#elifを使えば、上記のように条件が3個でも、#endifは1個だけの記述で済む。
込み入ったプログラムを記述していると、C#の文法エラーではないが、プログラムの意図として間違いだとプログラマーに伝えたい場合がある。特に、個人ではなくチームで開発しているケースでは、ほかのプログラマーに間違った使い方をさせないために、これを実現する機能が必要となる。このために、C#のプリプロセッサには、警告を発する#warningと、エラーを発する#errorが用意されている。List 19-9はそれを用いた例である。
1: using System;
2:
3: #if DEBUG
4: #warning This is a sample warning.
5: #endif
6:
7: #if DEBUG
8: #error This is a sample error.
9: #endif
10:
11: namespace Sample009
12: {
13: /// <summary>
14: /// Class1 の概要の説明です。
15: /// </summary>
16: class Class1
17: {
18: /// <summary>
19: /// アプリケーションのメイン エントリ ポイントです。
20: /// </summary>
21: [STAThread]
22: static void Main(string[] args)
23: {
24: //
25: // TODO: アプリケーションを開始するコードをここに追加してください。
26: //
27: }
28: }
29: }
これをビルドするとFig.19-11のようになる。
1: ------ ビルド開始 : プロジェクト : Sample009, 構成 : Debug .NET ------
2:
3: リソースを準備しています...
4: 参照を更新しています...
5: メイン コンパイルを実行しています...
6: q:\awrite\gh\cs\wk2\samples\chapt19\sample009\class1.cs(4,10): warning CS1030: #warning : 'This is a sample warning.'
7: q:\awrite\gh\cs\wk2\samples\chapt19\sample009\class1.cs(8,8): error CS1029: #error : 'This is a sample error.'
8:
9: ビルドの完了 -- エラー 1、警告 1
10: サテライト アセンブリをビルドしています...
11: メイン プロジェクト出力がないため、サテライト アセンブリを作成できません。
12:
13:
14: ---------------------- 終了 ----------------------
15:
16: ビルド : 0 正常終了、1 失敗、0 スキップ
見てのとおり、警告が1件、エラーが1件出力されているが、この2つは、ソース・コード上で明示的に指定されたものである。警告は、List 19-9の4行目の#warningにより引き起こされたもので、エラーは8行目の#errorで引き起こされたものである。それぞれ、ソース・コード上に記述された文字列がエラー・メッセージ中に出力されていることが分かるだろう。
これらの機能は、主に#ifと同時に使われることになるだろう。いつでもエラーになるソースは常識的には意味がないからだ。指定した条件が適切ではないことを警告またはエラーとして報告するために使用されることが多いだろう。
Visual Studio .NETでWindowsアプリケーションのプロジェクトを生成すると、ソース・コードが生成される。その際、一部のソース・コードが、折り畳まれて見えない状態になっていることにお気づきの方も多いと思う。このような、ある範囲のソース・コードをワンクリックで見せたり隠したりする(折り畳む)機能が、IDEには存在するのである。通常は、クラスやメソッドなどの単位で折り畳むことができるのだが、この範囲に該当しない単位で折り畳める場合もある。これは、#regionと#endregionというプリプロセッサの命令を使って実現できるものである。List 19-10はそれを用いた例である。
1: using System;
2:
3: namespace ConsoleApplication10
4: {
5: class Class1
6: {
7: static void Main(string[] args)
8: {
9: #region sample output code
10: Console.WriteLine("Output 1");
11: Console.WriteLine("Output 2");
12: Console.WriteLine("Output 3");
13: Console.WriteLine("Output 4");
14: Console.WriteLine("Output 5");
15: #endregion
16: }
17: }
18: }
このソースをIDEで開いてみよう。Fig.19-12を見てほしい。
そして、9行目左側の[-]マークをクリックすると、#regionから#endregionまでの範囲が、Fig.19-13のように折り畳まれるのである。
折り畳まれた段階では、#regionの後に記述した文字列がグレーで表示されていることに注目していただきたい。何が折り畳まれているのか、分かりやすい説明の文章を入れておくとよいだろう。
この機能は、ツールが自動生成したソースなど、見る必要のないソースを隠すために便利である。
『新プログラミング環境 C#がわかる+使える』
本記事は、(株)技術評論社が発行する書籍『新プログラミング環境 C#がわかる+使える』から許可を得て一部分を転載したものです。
【本連載と書籍の関係について 】
この書籍は、本フォーラムで連載した「C#入門」を大幅に加筆修正し、発行されたものです。連載時はベータ版のVS.NETをベースとしていましたが、書籍ではVS.NET製品版を使ってプログラムの検証などが実施されています。技術評論社、および著者である川俣晶氏のご好意により、書籍の内容を本フォーラムの連載記事として掲載させていただけることになりました。
→技術評論社の解説ページ
ご注文はこちらから
Copyright© Digital Advantage Corp. All Rights Reserved.