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