別プロジェクトのソースファイルを使う時にresorce.hが、ダブってしまう

Question

別プロジェクトのソースファイルを利用したい時に、
そのソースファイルをこのプロジェクトのディレクトリにコピーしたくない、
　　理由としては、同じファイルをあちこちに作りたくない、メンテナンスが１箇所のほうが便利
等の理由で、結構在ると思うのですが、、

このプロジェクトのプロパティのＣ／Ｃ＋＋の全般の追加のインクルードディレクトリに
別プロジェクトのディレクトリを追加すると、コンパイル時に追加されたディレクトリが先に、
読み込まれる様で、その別プロジェクトのresource.hが読み込まれて
本来のディレクトリのresource.hが読み込まれ無くて、コンパイルエラーが出ます。

ダイアログエディタ等がresource.hという決め打ちのファイル名に依存している上にそのresource.hが
プロジェクトのルートに在る。
のが問題点だと思うのですが、、

ダイアログエディタ等が正常に使える前提で何か手立ては無いでしょうか？

対策例（実現可能かは無視）
１．追加のインクルードディレクトリが確実に本来のディレクトリの後に読み込まれるように指定する。
２．プロジェクト毎にresource.hのファイル名を変更する。
３．resource.hをプロジェクトのディレクトリでは無くresというサブディレクトリ等に移動する。
というような対策を考えてみたのですが「ほとんど妄想に近い（^^;）」

どなたか、良い対応策をご存知の方いらっしゃいませんか？

Answer 1

かりゆし さんからの引用

このプロジェクトのプロパティのＣ／Ｃ＋＋の全般の追加のインクルードディレクトリに 別プロジェクトのディレクトリを追加すると、コンパイル時に追加されたディレクトリが先に、 読み込まれる様で、その別プロジェクトのresource.hが読み込まれて 本来のディレクトリのresource.hが読み込まれ無くて、コンパイルエラーが出ます。

本当ですか？

下記のページのインクルード順序を参照する限り、ソースファイルと同じフォルダのresource.hが優先されるように見受けられます。

http://msdn.microsoft.com/ja-jp/library/73f9s62w(VS.80).aspx

 

それとも、そのコンパイルエラーを起こすcppファイルは、別プロジェクトのフォルダにあるのでしょうか？

そうだとすれば、別プロジェクトのresource.hが読み込まれるとは思います。

 

かりゆし さんからの引用

そのソースファイルをこのプロジェクトのディレクトリにコピーしたくない、 　　理由としては、同じファイルをあちこちに作りたくない、メンテナンスが１箇所のほうが便利 等の理由で、結構在ると思うのですが、、

その共有したいコードをDLLやLIBにできないのでしょうか？

別のプロジェクトのフォルダを参照するという形が分かりにくく感じます。

 

共有している事実が認識しにくいため、一方のプロジェクトの事情でコードを大きく編集したら、他方のプロジェクトでうまく動かなくなった等のトラブルを生むような気がします。

それであれば、最初から共有DLLプロジェクト等として、分離しておいたものを2つのプロジェクトで共通利用するようなイメージが良いのかなと感じました。

Answer 2

Azuleanさん、返信ありがとうございます。

最初の発言では書き忘れていましたが、ＸＰ－ＶＣ２００８で開発しています、、

今、まさにそのプロジェクトの開発・デバッグ中なので、忙しくて、お返事が遅くなりました。

Azulean さんからの引用

かりゆし さんからの引用 このプロジェクトのプロパティのＣ／Ｃ＋＋の全般の追加のインクルードディレクトリに 別プロジェクトのディレクトリを追加すると、コンパイル時に追加されたディレクトリが先に、 読み込まれる様で、その別プロジェクトのresource.hが読み込まれて 本来のディレクトリのresource.hが読み込まれ無くて、コンパイルエラーが出ます。 本当ですか？ 下記のページのインクルード順序を参照する限り、ソースファイルと同じフォルダのresource.hが優先されるように見受けられます。 http://msdn.microsoft.com/ja-jp/library/73f9s62w(VS.80).aspx   それとも、そのコンパイルエラーを起こすcppファイルは、別プロジェクトのフォルダにあるのでしょうか？ そうだとすれば、別プロジェクトのresource.hが読み込まれるとは思います。

実際に読み込まれているインクルードファイルは、
プロジェクトのプロパティのＣ／Ｃ＋＋の詳細のインクルードファイルを表示する
で、確認しました。
この件は実際にその問題が起きる極単純なプロジェクトたちをどこかにアップロードしたいと思います。
いつになるかのお約束は出来ませんが、、、

Azulean さんからの引用

かりゆし さんからの引用 そのソースファイルをこのプロジェクトのディレクトリにコピーしたくない、 　　理由としては、同じファイルをあちこちに作りたくない、メンテナンスが１箇所のほうが便利 等の理由で、結構在ると思うのですが、、 その共有したいコードをDLLやLIBにできないのでしょうか？ 別のプロジェクトのフォルダを参照するという形が分かりにくく感じます。   共有している事実が認識しにくいため、一方のプロジェクトの事情でコードを大きく編集したら、他方のプロジェクトでうまく動かなくなった等のトラブルを生むような気がします。 それであれば、最初から共有DLLプロジェクト等として、分離しておいたものを2つのプロジェクトで共通利用するようなイメージが良いのかなと感じました。

まず、以下の説明で言うプロジェクトとはあくまでＶＣの上でのプロジェクトであり、一般的な業務上のプロジェクトではありません。

今の所、私は．ＮＥＴは使用するつもりがありません、どうしても．ＮＥＴを使用する場合たぶんＶＢでコーディングするでしょう。

ＭＦＣもでかくて重いので極力避けています、しかし場合によっては、ＭＦＣを使用する方が手っ取り早い場合もありますので、使用する場合もあります。

今回共有したいソースは、ＡＴＬ・ＭＦＣは、極力使って無く、またマルチバイト・ユニコードの両方をひとつのソースファイルにまとめ、パス名の変換・ファイルの検索等、１つずつのソース単体でまとめており、他から使えるものたちです。

但し、そのソース達は使う側からの要求で機能追加・修正をする必要があります。

また、それを使用する側のプロジェクトは、ＡＴＬ・ＭＦＣ使用の有無と、マルチバイト・ユニコードの違いもあります。

その様な場合、ソースの状態で、共有する方が便利だと思います。

その上、ＤＬＬは、メモリ管理の関係で下手をすると動きませんし、その問題がどちらにあるのか区別が付きにくいです、逆に言うとそのメモリ関係の対策をちゃんとした状態（本人の理解度・コーディング）で無いとＤＬＬ化出来ません。

という事で、ソースの状態で共有しています。

上記の様な理由で「結構在ると思うのですが、、」と書きました。

Answer 3

かりゆし さんからの引用

最初の発言では書き忘れていましたが、ＸＰ－ＶＣ２００８で開発しています、、 （略） 実際に読み込まれているインクルードファイルは、 プロジェクトのプロパティのＣ／Ｃ＋＋の詳細のインクルードファイルを表示する で、確認しました。

フォルダ構成等によって変化するものではないでしょうか。

 

XP VC2008で手元の環境で、インクルードファイルの表示で確認しましたが、追加のインクルードディレクトリが何よりも優先されるような挙動は確認できません。

このため、本当に記載頂いている現象（何よりも追加のインクルードディレクトリが優先される）が起きているのか、確認して欲しい意図で書きました。

 

かりゆし さんからの引用

今回共有したいソースは、ＡＴＬ・ＭＦＣは、極力使って無く、またマルチバイト・ユニコードの両方をひとつのソースファイルにまとめ、パス名の変換・ファイルの検索等、１つずつのソース単体でまとめており、他から使えるものたちです。 但し、そのソース達は使う側からの要求で機能追加・修正をする必要があります。 また、それを使用する側のプロジェクトは、ＡＴＬ・ＭＦＣ使用の有無と、マルチバイト・ユニコードの違いもあります。 その様な場合、ソースの状態で、共有する方が便利だと思います。

ソースだけで共有するなら、commonフォルダとか完全に分離してはいかがでしょうか？

 

ソリューションフォルダ

+ common　（共有するcpp/h）

+ ProjectA　（プロジェクトA。そのプロジェクトでしか使用しないファイル群）

+ ProjectB　（プロジェクトB。そのプロジェクトでしか使用しないファイル群）

 

これにより、共有していることが明確になりますし、commonフォルダにはresource.hが存在しないので、今回の問題は起きないはずです。

もし、この構成でresource.hが見つからなくてコンパイルエラーになるのであれば、それはロジックとリソースを分離して下さいと言うこととになります。

 

 

 

 

（参考）

mfcappプロジェクトでmfcdllプロジェクトに含まれるtest.cpp/hを参照した模擬プロジェクト。

MFCを使う設定になっていますが、インクルード関係のテストという観点では差異がないはずです。

mfcappプロジェクトでは追加のインクルードディレクトリに mfcapp\mfcdll を設定しています。（test.hのために）

 

ChildFrm.cpp
メモ: インクルード ファイル: （略）\mfcapp\mfcapp\MfcApp.h
メモ: インクルード ファイル: （略）\mfcapp\mfcapp\resource.h ※ここではChildFrm.cppと同じフォルダのファイルが優先されている。
メモ: インクルード ファイル: （略）\mfcapp\mfcapp\ChildFrm.h
メモ: インクルード ファイル: （略）\mfcapp\mfcdll\test.h
メモ: インクルード ファイル: （略）\mfcapp\mfcdll\resource.h  ※ここではtest.hと同じフォルダのファイルが優先されている。

Test.cpp
メモ: インクルード ファイル: （略）\mfcapp\mfcdll\Test.h
メモ: インクルード ファイル: （略）\mfcapp\mfcdll\resource.h ※ここではtest.hと同じフォルダのファイルが優先されている。

 

※ChildFrm.cppは（略）\mfcapp\mfcappに存在する。
※Test.cpp/hは（略）\mfcapp\mfcdllに存在する。

Answer 4

１つ可能性を見つけた。

 

ProjectAフォルダ （共有するコードを持つプロジェクト）

　Test.cpp

　Test.h

　resource.h

ProjectBフォルダ （ProjectAのコードを使いたいプロジェクト）

　resource.h

　Testフォルダ

　　CompileError.cpp

　　CompileError.h

 

ProjectBの設定で、追加のインクルードディレクトリにProjectAを追加している場合、CompileError.cppで#include "resoruce.h"があると、ProjectAのフォルダを見に行きます。

（追加のインクルードディレクトリの設定が空の場合は、コンパイルエラーになります）

 

この場合でも、共有したいコードは別フォルダに分離するということをお薦めします。

どうしても分離したくないのであれば、「$(ProjectDir);$(ProjectDir)..\MfcDll」というようなインクルードディレクトリを設定すれば解決できるかも知れませんが、一時しのぎに過ぎません。

Answer 5

ひょっとして、#include <resource.h> となっていたりしませんか？
#include "resource.h" と #include <resource.h> では探しに行く順番が変化します。
（これをうまく使うという手も考えられます。）

Answer 6

こんにちは。中川俊輔 です。

 

Azuleanさん、zakioさん、回答ありがとうございます。

 

かりゆしさん、フォーラムのご利用ありがとうございます。

その後いかがでしょうか?

有用な情報と思われたため、Azuleanさん、zakioさんの回答へ回答済みチェックをつけさせていただきました。

 

今後ともフォーラムをよろしくお願いします。

それでは！