Objective-c NSLog 的宏定義

__VA_ARGS__ 是一個可變參數的宏，這個可變參數的宏是新的C99規範中新增的，目前彷佛只有gcc支持（VC6.0的編譯器不支持）。宏前面加上##的做用在於，當可變參數的個數爲0時，這裏的##起到把前面多餘的","去掉,不然會編譯出錯。
2) __FILE__ 宏在預編譯時會替換成當前的源文件名
3) __LINE__宏在預編譯時會替換成當前的行號
4) __FUNCTION__宏在預編譯時會替換成當前的函數名稱

Objective-c NSLog 的宏定義

相信全部的iPhone開發者都曾經或者將會用到NSLog這個函數。NSLog的強大之處在於，它能在代碼運行過程當中顯示變量值以及程序實際走向，能幫助咱們發現大量錯誤和潛在風險。咱們但願儘量多的用到NSLog，但願它能無處不在，使得錯誤沒法存在——簡單的說NSLog是一個天使。
好比下面這段代碼就利用NSLog，在程序運行時判斷設備種類並顯示出來
NSString *deviceType = [UIDevice currentDevice].model;
NSLog(@」device type: %@.」, deviceType);
使用NSLog的一個風險是：它的運行會佔用時間和設備資源。當咱們用Simulator時，NSLog的資源佔用並不引人注意，風險也不會顯示出來。可是若是你寫的是一個即時戰略遊戲，而你在每個action中都加入了NSLog——那麼NSLog將成爲一個魔鬼。災難的具體表現經常是：你在 Simulator中運行遊戲暢通無阻，但到了真機上，會發現很「卡」，不管是拖動一個單位仍是縮放一個場景，FPS也降到了各位數。
簡單而粗暴的解決方案是：在一個遊戲release前，將全部的NSLog註釋掉。簡單有效，但反作用是：下次你要調試時，又得將NSLog一個個取消註釋。
我找到了一個最爲有效的解決方案：你以release模式編譯的程序不會用NSLog輸出，而你以debug模式編譯的程序將執行NSLog的所有功能。
#ifndef __OPTIMIZE__
# define NSLog(…) NSLog(__VA_ARGS__)
#else
# define NSLog(…) {}
#endif
這個代碼的魔術在於：release模式一般會定義 __OPTIMIZE__，固然debug模式不會。將這段代碼放在你的頭文件當中，你就能夠放心的使用NSLog了！

固然還有其餘的方式，好比：

1.直接本身寫#define,當release版本的時候把#define 註釋掉便可
1. #define IOS_DEBUG
2. #ifdef IOS_DEBUG  
3. #define NSLog(...) NSLog(__VA_ARGS__)  
4. #endif 

 
2.
1. #ifdef DEBUG    
2. # define DLog(format, ...) NSLog((@"[文件名:%s]" "[函數名:%s]" "[行號:%d]" format), __FILE__, __FUNCTION__, __LINE__, ##__VA_ARGS__);    
3. #else    
4. # define DLog(...);    
5. #endif