怎么去掉Xcode工程中的某種類型的警告 Implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int32
標(biāo)簽： iOSios7iphonemacxcode
2014-12-17 17:40 12876人閱讀 評(píng)論(1) 收藏 舉報(bào)
分類：? IOS（11）
版權(quán)聲明：本文為博主原創(chuàng)文章，未經(jīng)博主允許不得轉(zhuǎn)載。
問題描述
在我們的項(xiàng)目中,通常使用了大量的第三方代碼,這些代碼可能很復(fù)雜,我們不敢改動(dòng)他們,可是作者已經(jīng)停止更新了,當(dāng)sdk升級(jí)或者是編譯器升級(jí)后,這些遺留的代碼可能會(huì)出現(xiàn)許許多多的警告,那么我們有沒有辦法去掉這些煩人的警告,不然一個(gè)工程幾百個(gè)警告,你看著怎么都不爽吧.我們?cè)趺慈サ艟婺?/p>
1.最直接,最一勞永逸,最安全的方式,直接找到警告的那段代碼,改為不警告.這個(gè)方式,最安全.
可是它有一個(gè)問題,就是,當(dāng)我們很多文件都有這種類型的警告的時(shí)候,我們就需要改動(dòng)很多很多的源碼了, 對(duì)于不是我們寫的源碼,有可能隨時(shí)會(huì)更新的,我們這種方式,顯然就不太可取了.
2.使用編譯器提供的宏來操作,這個(gè)方式在我們的工程中會(huì)大量的看到
#pragma clang diagnostic push
#pragma clang diagnostic ignored"-Wdeprecated-declarations"
//寫在這個(gè)中間的代碼,都不會(huì)被編譯器提示-Wdeprecated-declarations類型的警告
dispatch_queue_tcurrentQueue =dispatch_get_current_queue();
#pragma clang diagnostic pop
這種方式的問題,同第一個(gè)差不多,也是要修改源代碼的實(shí)現(xiàn)的,對(duì)于第三方,我們肯定是不想改動(dòng)它的,尤其是一些更新很頻繁的第三方,一般警告出現(xiàn)后不久,作者就更新了,我們?cè)诖俗鲞@樣的操作,就顯得浪費(fèi)了.并且在 添加arm64支持的時(shí)候,一下出現(xiàn)幾百個(gè)某種類型的警告,改起來也是相當(dāng)費(fèi)時(shí)費(fèi)力的啊!
比如我們的工程,打開了arm64,然后編譯
3.關(guān)閉某一個(gè)指定文件的某種指定類型的警告
這里,拿一個(gè)具體工程來說吧.比如我們工程里有一個(gè)文件? PresencePacket
其實(shí)關(guān)閉某個(gè)指定文件的某種類型的警告很簡單,就如同我們以前給某一個(gè)文件添加 ARC支持或者不支持的時(shí)候那樣 添加 忽略/顯示 某種類型警告
雙擊 文件, 在其中添加? -Wno-shorten-64-to-32? (這個(gè)關(guān)鍵在就是讓編譯器忽略 Implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int32_t' (aka 'int') 警告)
添加完成后,再編譯,那么PresencePacket文件中的? Implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int32_t' (aka 'int’) 警告就沒有了,是不是很簡單,很方便.
這種方式,已經(jīng)是大大的減少了工作量了,只需要在指定的文件的編譯中添加 -Wno-shorten-64-to-32就可以了.那么有沒有什么方式可以讓編譯器忽略整個(gè)工程中的 指定類型的警告呢?
4.關(guān)閉工程中指定 類型的警告
這個(gè)最簡單了, 工程的target有一個(gè) Other Warning Flags
在其中添加 -Wno-shorten-64-to-32
再重新編譯,哈哈,整個(gè)文件中的? Implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int32_t' (aka 'int’) 警告全部消失了!!!!
5.大家可能很疑惑,上面的-Wno-shorten-64-to-32 是怎么來的,我怎么知道? Implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int32_t' (aka 'int’) 警告 就是 -Wno-shorten-64-to-32類型呢?這里,其實(shí)不需要記憶的,當(dāng)工程中有這種類型警告的時(shí)候
在警告窗口,某個(gè)警告上,我們右擊,顯示出右鍵菜單,選擇其中的 Reveal in Log
則會(huì)顯示
注意到其中 [-Wshorten-64-to-32],在這個(gè)括號(hào)中的就是 這種警告的類型? -W是前綴,這個(gè)前綴表示的是 打開這種類型的警告 如果我們是要關(guān)閉某種類型的警告的話, 要將 -W換成 -Wno-
這樣就得到了? -Wno-shorten-64-to-32了.
后記:
對(duì)于我們使用cocoapod引入的第三方,我們可以在podfile文件中 增加一句? inhibit_all_warnings! 來要pod的工程不顯示任何警告,
例如
link_with 'SecondHouseBrokerAPP','SecondHouseBrokerCOM'
platform :ios,'6.0'
inhibit_all_warnings!
pod 'CocoaAsyncSocket'
pod 'Reachability'
pod 'ProtobufObjC'
pod 'SDWebImage'
pod 'FMDB'
pod 'GPUImage'
pod 'CXPhotoBrowser'
pod 'CocoaLumberjack'
還有就是,上面的方法也適合其它類型的警告!!!
參考
http://oleb.net/blog/2013/04/compiler-warnings-for-objective-c-developers/
http://amattn.com/p/better_apps_clang_weverything_or_wall_is_a_lie.html
http://stackoverflow.com/questions/16384530/clang-in-xcode-start-with-weverything-and-manually-disable-particular-warnin
http://adoptioncurve.net/archives/2013/02/selectively-disabling-warnings-with-xcode-compiler-flags/
頂
6
踩
0
上一篇MAC/IOS中使用protocolBuf
下一篇cocoapods應(yīng)用第一部分-xcode創(chuàng)建.framework相關(guān)
我的同類文章
IOS（11）
?怎樣創(chuàng)建一個(gè)xcode插件 第一部分/3部分2016-03-07閱讀85
?xcode7 插件制作入門2016-02-05閱讀283
?cocoapods應(yīng)用第二部分-私有庫相關(guān)2015-09-15閱讀854
?MAC/IOS中使用protocolBuf2014-12-08閱讀4029
?一個(gè)關(guān)于MFMessageComposeViewController的ios7中的詭異問題 收件人視圖黑色 和解決方式2014-04-26閱讀4814
?iOS中的正則表達(dá)式2016-03-01閱讀28
?NSTimer和實(shí)現(xiàn)弱引用的timer的方式2016-01-31閱讀167
?cocoapods應(yīng)用第一部分-xcode創(chuàng)建.framework相關(guān)2015-08-26閱讀2141
?IOS/MAC中使用Thrift框架2014-12-05閱讀3291
更多文章
