我已經(jīng)審查了問題：如何正確使用include指令和C ++ #include語義，并且既沒有解決這個問題，也沒有解決SO在輸入標題時建議的其他問題...編寫的好處（如果有）是什么：#include "../include/someheader.h"#include "../otherdir/another.h"與僅使用純文件名相比：#include "someheader.h"#include "another.h"或不帶' ..' 的相對名稱：#include "include/someheader.h"#include "otherdir/another.h"我看到的問題是：您不能移動標題而不必擔(dān)心哪些源文件包含它。您最終可能會為依賴項和錯誤報告中的標頭提供非常長的路徑。我今天有一個與“ ../dir1/include/../../include/../dir2/../include/header.h”。我看到的唯一優(yōu)點是，盡管您不需要移動文件，但可能不必總是使用' -I'指令來查找標頭就可以擺脫困境，但是卻失去了靈活性，并且在sub-sub中進行編譯非常復(fù)雜目錄等似乎超過了收益。那么，我是否忽視了好處？感謝您的投入。我認為，共識是使用“ ..”這個符號并沒有太大的好處。一般而言，我喜歡“ somewhere / header.h”表示法。我確實在新項目中使用了它。我正在研究的東西不是什么新東西。其中一個問題是，有各種套頭的，往往帶有前綴，如rspqr.h，rsabc.h，rsdef.h，rsxyz.h。這些都與rsmp目錄中的代碼相關(guān)，但是某些標頭位于其中，rsmp而其他標頭位于中央的include目錄中，該目錄中沒有諸如此類的子目錄rsmp。（然后對代碼的其他各個部分重復(fù)上述操作；在多個位置都有標頭，而其他位的代碼則隨機需要。）隨處移動內(nèi)容是一個主要問題，因為多年來這些代碼變得如此復(fù)雜。并且makefile在-I提供的選項中不一致?？偠灾@是一個數(shù)十年來不那么良性的忽視的悲慘故事。修復(fù)所有問題而不破壞任何東西將是一項漫長而乏味的工作。
3 回答
白板的微信
TA貢獻1883條經(jīng)驗 獲得超3個贊
問題#include "../include/header.h"在于它經(jīng)常會偶然工作，然后看似無關(guān)的更改將使其稍后停止工作。
例如，考慮以下源布局：
./include/header.h
./lib/library.c
./lib/feature/feature.c
假設(shè)您使用的包含路徑運行編譯器-I. -I./lib。怎么了？
./lib/library.c可以做到#include "../include/header.h"，這是有道理的。
./lib/feature/feature.c#include "../include/header.h"即使沒有任何意義，也可以做到。這是因為編譯器將嘗試#include相對于當(dāng)前文件位置的指令，如果失敗，它將嘗試#include相對于路徑中每個-I條目的指令#include。
此外，如果您稍后-I./lib從#include路徑中刪除，則會中斷./lib/feature/feature.c。
我發(fā)現(xiàn)以下內(nèi)容更可?。?/p>
./projectname/include/header.h
./projectname/lib/library.c
./projectname/lib/feature/feature.c
我不會添加任何包括比其他路徑項-I.，然后雙方library.c并feature.c會使用#include "projectname/include/header.h"。假設(shè)“項目名稱”可能是唯一的，那么在大多數(shù)情況下，這不應(yīng)導(dǎo)致名稱沖突或模棱兩可。VPATH如果絕對必要，您還可以使用include路徑和/或make 功能在多個目錄之間劃分項目的物理布局（例如，以適應(yīng)特定于平臺的自動生成的代碼；這在使用時確實會崩潰#include "../../somefile.h"）。
月關(guān)寶盒
TA貢獻1772條經(jīng)驗 獲得超5個贊
在以下情況下，請#include ""使用一個或多個“ ../” 序列開始指令的路徑：
您要包含一個與包含文件的搭配是固定的文件，并且
您在POSIX系統(tǒng)或VC ++上構(gòu)建，并且
您希望避免對要包含的文件有歧義。
總是很容易提供一個示例，說明您的代碼庫中包含錯誤，并在此之后導(dǎo)致難以診斷的錯誤。但是，即使您的項目沒有故障，但如果您依靠絕對路徑來指定相對于彼此的文件，則第三方可能會濫用該項目。
例如，考慮以下項目布局：
./your_lib/include/foo/header1.h
./your_lib/include/bar/header2.h
./their_lib/include/bar/header2.h
your_lib / include / foo / header1.h應(yīng)該如何包含your_lib / include / bar / header2.h？讓我們考慮兩個選項：
#include <bar/header2.h>
假設(shè)your_lib / include和their_lib / include都被引為標頭搜索路徑（例如，使用GCC -I或-isystem選項），那么將選擇哪個header2.h對搜索這兩個路徑的順序很敏感。
#include "../bar/header2.h"
編譯器將搜索的第一個位置是your_lib / include / foo / header1.h的位置，即your_lib / include / foo /。它將首先嘗試your_lib / include / foo /../ bar / header2.h，該文件會縮小為your_lib / include / bar / header2.h，在其中可以找到正確的文件。標頭搜索路徑將完全不使用，并且?guī)缀鯖]有歧義。
出于給出的原因，在這種情況下，我強烈建議您選擇選項2）。
針對其他答案中的一些論點：
@ andrew-grant 說：
...非常清楚標頭文件屬于哪個名稱空間或模塊。
也許。但是相對路徑可以解釋為“在同一模塊中”。如果在不同模塊中存在多個具有相同名稱的目錄，它們將提供清晰的信息。
@ bk1e 說：
...它經(jīng)常會偶然地工作...
我認為相對路徑僅在非常罕見的情況下會偶然起作用，在極少數(shù)情況下，項目從一開始就被破壞并且很容易修復(fù)。在不引起編譯器錯誤的情況下經(jīng)歷這樣的名稱沖突似乎不太可能。一種常見的情況是，從屬項目的文件包含一個標題，而另一個包含另一個標題。與該從屬項目隔離進行編譯時，編譯測試套件應(yīng)導(dǎo)致“沒有這樣的文件或目錄”錯誤。
@singlenegationelimination 說
...這不是便攜式的，標準不支持它。
ISO C標準可能未指定在其下編譯或運行程序的系統(tǒng)的所有詳細信息。這并不意味著它們不受支持，只是該標準并未過多指定C將在其上運行的平臺。（在常見的現(xiàn)代系統(tǒng)上，如何解釋""和如何<>解釋的區(qū)別可能源于 POSIX標準。）
@ daniel-paull 說
“ ..”采用相對位置且易碎
脆弱如何？大概對兩個文件的搭配敏感。因此，..僅在（包括始終）在包含文件的作者控制其位置時使用“”。
- 3 回答
- 0 關(guān)注
- 738 瀏覽
添加回答
舉報
0/150
提交
取消