Xcode6以后預(yù)編譯pch文件的添加

在Xcode6之前,新建一個(gè)工程的時(shí)候,系統(tǒng)會(huì)幫我們自動(dòng)新建一個(gè)以工程名為名字的pch (precompile header)文件,在開(kāi)發(fā)過(guò)程中,可以將那些整個(gè)工程都廣泛使用的頭文件包含在該文件下,編譯器就會(huì)自動(dòng)的將pch文件中的頭文件添加到所有的源文件中去,這樣在需要使用相關(guān)類的時(shí)候不需要使用import就可以直接使用頭文件中的內(nèi)容,很大程度上帶來(lái)了編程的便利性,但潛在的也帶來(lái)了一些問(wèn)題,這也是在Xcode6中默認(rèn)不再創(chuàng)建pch的原因吧。

As to where to put code that you would put in a prefix header, there is no code you should put in a prefix header. Put your imports into the files that need them. Put your definitions into their own files. Put your macros...nowhere. Stop writing macros unless there is no other way (such as when you need__FILE__). If you do need macros, put them in a header and include it.

The prefix header was necessary for things that are huge and used by nearly everything in the whole system (likeFoundation.h). If you have something that huge and ubiquitous, you should rethink your architecture. Prefix headers make code reuse hard, and introduce subtle build problems if any of the files listed can change. Avoid them until you have a serious build time problem that you can demonstrate is dramatically improved with a prefix header.

In that case you can create one and pass it into clang, but it's incredibly rare that it's a good idea.

那么有時(shí)候我們還需要pch文件,盡管會(huì)有一些問(wèn)題,但是在項(xiàng)目開(kāi)發(fā)過(guò)程中使用pch文件還是有一定的便利性,處于習(xí)慣將添加方法貼在下面,同時(shí)在路徑方面我采用了相對(duì)路徑,這樣的話可以避免在代碼管理或者移至其他文件夾后出現(xiàn)路徑找不到的問(wèn)題出現(xiàn)

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容