に含まれていることを保証するために、どのように私はこの例のためにOpenSSLがインストールヘッダー構造を使用します:C/C++プリプロセッサ:正しいファイルが
/usr/include (or some folder in include search path on Windows box) | + --openssl | +-- e_os2.h +-- rsa.h +-- sha.h ...
/usr/include
コンパイラである検索パスが含まれます。 OpenSSLヘッダーは通常次のようになります。#include <openssl/sha.h>
最初の行で、openssl/sha.hには次のものが含まれています。#include <openssl/e_os2.h>
。 だから、私の質問:インストールされたヘッダが同じフォルダのヘッダを参照するのは本当に良い考えですか?その方法でe_os2.hを参照すると、他の場所からe_os2.hを取得する可能性があります。必ずしもsha.hと同じフォルダにある必要はありません。たとえば、opensslのローカルコピーをいくつかの場所にインクルードし、sha.hを次のように組み込んだ場合:#include "../../3rdpath/openssl/sha.h
私は互換性のないバージョンのヘッダーを組み合わせることでコードにいくつかの厄介なバグを取得するかもしれません。
#incldue <...>
vs #incldue "..."
に関して、コンパイラが異なる動作をすることを考慮すると、opensslのようにlibに適切な方法が含まれていますか?
私は、opensslのやり方がそれを行う最も間違った方法だと考えました。他の2つの方法があります。
a) #include "e_os2.h"
と
b) #include "./e_os2.h"
のopensslの方法は次のとおりです。
c) #include <openssl/e_os2.h>
悪いの決定は、それがopensslの中で行うの方法を行うためにということですか? a)またはb)の問題? b)は、同じフォルダからのみe_os2.hをインクルードすることを意味し、すべての主要コンパイラ(ms cl、armcc、intel cl、gcc et all)で保証されていますか?
よく、gccとclは、例えば< >と ""については全く異なっていますか?私はそれがmsコンパイラで正しく動作することを確信しています。問題は、私が使っているコードでは、別のバージョンのlibを使う必要があり、もし私がopensllのやり方をすれば、(完全なABIの非互換性のために)不思議なバグが出てくるだろうということです。 – Pavel
なぜ#include "./file.h"は未定義の動作をしますか?私が理解しているように、プリプロセッサのメカニズムを含むものは、「何でも」、コンパイラの実装の詳細です。私のインクルードは#include "../../some_file.h"のような参照がいっぱいです。#include "./some_file.h"とはどのように違いますか? (このコードは多くのコンパイラ/システムで問題なくコンパイルされています) – Pavel
"../../some_file.h"のようなパスは、見つかったインクルードファイルに対して相対パスで解釈される*ソースファイルのどちらかです。このアイディアをサポートするコンパイラのインクルードパスを基準にして解釈されます。したがって、あなたが得ようとしているヘッダについては、それ以上の保証はありません。 –