C プラグマのソースを表示新しいページはコチラ

※このページではC言語にも存在していたという意味で記事タイトルがC プラグマになっていますが、<br />
[[C PlusPlus|C++]]でも同様です。[[C PlusPlus|C++]]だけの機能がある場合は明記します。<br />
<br />
<big><big>'''プラグマ'''</big></big> 


プラグマは、一般的に処理系独自のコンパイルオプションやコンパイル時の取り扱いをプログラムソースコード上で制御するためのディレクティブです。このように説明するとなんだか簡単なことを制御するだけのディレクティブに思えますが、VisualStudioでWindowsアプリを作成するようなプログラマにとっては、全てを理解することは非常に難しいことです。なぜなら、Windows独自の技術自体をコンパイルオプションによって制御するということですから、Windows OSの技術の中でも、通常のパソコン操作程度では聞いたこともないような技術について知る必要があることを含め、Visual Studioで設定可能なプロジェクトのプロパティの全てを理解していくのと等しいことだからです。プラグマによって制御できる全てを理解することは非常に難しいことですが、基本的に意識する必要のないコンパイルオプションもふんだんに含まれているので、深く理解をせずに、アプリケーションを作成する上で効率をあげるために理解するべき内容から理解していくことのほうが重要になります。


OS自体も人間には理解しにくい部分はなるべく意識せずにコンピュータを制御することを支援するために、作られているのですから、制御できるすべてを改めてプログラム側で制御する指示をすることを理解するのは、難しくて当たり前です。それでも、制御できる部分があるということは、一般的によく利用されるべき制御部分があることも確かなことでありまして、コンピュータを使って何をする人が多いのかを考えれば、インターネットをする人や文書を作成する人が多いことと同じで、プログラムを作成する際に制御されるべき部分についても、よく制御される部分とあまり制御されない部分とがあります。もちろん、どんなことにも対処できるプログラマになるにはすべてを理解した方がいいに決まっています。どこまで理解するべきかはプログラマ自身が決めることです。


ここでは、よく使われるであろうマイクロソフト固有のプラグマについて触れ、出来る限りの解説を長期間をかけて記載していきたいと思いますが、まずはプラグマによる制御の基本だけを触れて、Windowsアプリの記事を書くまでの間は、基本の部分以外については放置することになります。すべてを理解したい人は、MSDNによる解説とインターネットに散在している解説記事を閲覧して頂ければと思います(自分に言われなくても、勉学に励んでおられる人ならば、そうするにきまってるんでしょう。)。


*MSDNでのプラグマに関する説明ページ
:https://msdn.microsoft.com/ja-jp/library/d9x1s805.aspx

=='''#pragma'''==
<nowiki>#</nowiki>pragmaディレクティブは半角スペースに続けてもう一つのワードと引数パラメータを伴って定義する形式のものがほとんどです。また、マイクロソフト固有の仕様ですが、<nowiki>#</nowiki>pragmaの代わりに__pragmaでも同様の機能として動作するようになっています。これはディレクティブとして先頭に使われる#以降の#はプリプロセッサ演算子の文字列化演算子として扱われることを回避するために用意されています。

===#pragma comment===
<nowiki>#</nowiki>pragma commentはよく使われるプラグマの中のひとつで、その中でも1つ目の引数のlibと記述するパラメータを渡すものがよく使われていると思います。具体的には


'''<nowiki>#</nowiki>pragma comment(lib, "拡張子libのタイプライブラリ名")'''


として利用します。ライブラリの検索と読み込みについての指示を実行ファイル(.objや.oの拡張子がよく使われる)に記述するための指示です。リンク処理時に実行ファイルに記述されたライブラリ検索と読み込みを実行させることができるため、結果的に予め準備していたタイプライブラリの関数を利用することができるようになります。このような指示はVisualStudioではプロジェクトのプロパティでも同様に指定する手段が設けられています。


また、プロジェクトのプロパティで実行ファイルに記述されたライブラリの検索と読み込みの指示を無視するオプション /nodefaultlib も用意されているため、このオプションの内容に従ってリンクがなされた場合、ライブラリは読み込まれません。もしライブラリを読み込まないでリンク処理を実行するとエラーになるような場合には当然、関数(シンボル)が見つからない旨のエラーが発生しますので、別の方法でライブラリの読み込まないオプションを利用したことを補う必要が発生します。更には /Zl オプションを使うと実行ファイルにライブラリの検索と読み込みの指示についての書き出しがされないようにすることもできます。つまり、#pragma comment(lib, "xxxxx")の指示が無視されます。/Zlオプションは不要意にライブラリを読み込んで実行ファイルが肥大化するのを防ぎ、スペースを節約する役割のモノです。ライブラリの読み込み順序や読み込まれる部分を思慮深く、指定することを制御することを実現するための仕組みです。このあたりのオプション関連の動作も含めて一連の処理を理解しようとすると非常に複雑なものになります。このような問題からライブラリが見つからない場合、実行ファイルからリンク処理をするときには関数名が若干、修飾変換された関数名になっているため、少し変化した関数名で関数が見つかりませんというエラーが表示されます。こういった表示が出る場合は、これらのライブラリ読み込みに関するオプションやpragmaでの制御がうまくいかずにリンク処理が失敗していることを意味しますので、何が欠けているのか？その関数は何と言うライブラリで提供されていて、どこで読み込みを指示しているか？どのタイミングで読み込まれるか？きちんと読み込まれるかまでを再検討する必要が発生します。人からもらったプロジェクトをそのままコンパイルしてうまく動かない場合は、だいたいこのあたりの記述で問題が起こっていたり、環境変数LIBへのパス設定不足やライブラリの不足あるいはライブラリパスの変更による問題が発生していることがほとんどです。


プロジェクトファイルを配布しているにも関わらず、受け取ったファイルがそのまま動かせなかったり、プロジェクトの展開方法についての指示がないというものは、プロジェクト配布者に落ち度があると考えてよいですが、それが、意図的なのか、能力不足なのかは知る由はありません。プロジェクトファイルを公開しようとしているスタンスだけを評価し、プロジェクト配布者の能力や人柄を判断することになります。自分の場合はプロジェクトの中身を精査して、ライブラリパスに個人的なフォルダ設定を残したまま配布してる場合は、こういうものにはあまり関わりたくないと感じるほうですね。プロジェクトを完成させたくらいだから能力はあるんだろうけど、こんな状態で配布してるプロジェクトと関わると最終的には、どうせろくなことにならないと、そのように感じてしまいます。それが意図的であるなら尚更です。


このサイトを含め、ただで勉強しようとすると、結局は時間の無駄に終わることはよくあります。学ぶべき手段を選び間違えた自分を悔いるしかないです。そうならないように、できるだけ有用なものにはしていきたいとは思いますが、違う生業(なりわい)のかたわらの執筆です。なにぶんお聞き苦しい点も多々あろうかとは存じますが、耳を傾けていただければと思います。

===#pragma once===