程序運行時出現問題，選擇的是Release，win64位的模式，並且已經看到了宏定義NDEBUG，但是程序依然進入上面的部分
解決方案是將屬性->C/C++->代碼生成器->運行庫里面的多線程調試（/MTD）修改為多線程DLL（/MD）即可
修改之后：
編譯一下
解釋原因來自 http://blog.csdn.net/u013829933/article/details/50321355，感謝~~
這里總結下他們的區別,后面的那個'd'是代表DEBUG版本，沒有'd'的就是RELEASE版本了。
首先說/MT
/MT是 "multithread, static version ” 意思是多線程靜態的版本，定義了它后，編譯器把LIBCMT.lib 安置到OBJ文件中，讓鏈接器使用LIBCMT.lib 處理外部符號。
/MD是 "multithread- and DLL-specific version” ，意思是多線程DLL版本，定義了它后，編譯器把 MSVCRT.lib 安置到OBJ文件中，它連接到DLL的方式是靜態鏈接，實際上工作的庫是MSVCR80.DLL。
即：
靜態運行時庫：LIBCMT.lib
動態運行時庫：MSVCRT.lib + MSVCR80.DLL
所以，當你用CMAKE生成工程文件時，若CMAKE是用/MT生成的（查看工程原始目錄的CMakeLists.txt)，則它所調用的運行時庫為：LIBCMT.lib，若生成的工程的運行時庫（Runtime Library)你選擇/MD，則此工程在編譯后鏈接的時候，將會調用動態運行時庫：MSVCRT.lib + MSVCR80.DLL，明顯，兩次對同一個某運行時庫里的函數調用的庫不同，則會出現重定義的錯誤。若此工程生成的是庫文件，則其他工程調用此庫時也必須是/MT。
===============================================
VC項目屬性→配置屬性→C/C++→代碼生成→運行時庫 可以采用的方式有：多線程(/MT)、多線程調試(/MTd)、多線程DLL(/MD)、多線程調試DLL(/MDd)、單線程(/ML)、單線程調試(/MLd)。
Reusable Library Switch Library Macro(s) Defined
| Single Threaded | /ML | LIBC | (none) |
| Static MultiThread | /MT | LIBCMT | _MT |
| Dynamic Link (DLL) | /MD | MSVCRT | _MT and _DLL |
| Debug Single Threaded | /MLd | LIBCD | _DEBUG |
| Debug Static MultiThread | /MTd | LIBCMTD | _DEBUG and _MT |
| Debug Dynamic Link (DLL) | /MDd | MSVCRTD | _DEBUG, _MT, and _DLL |
其中以小寫“d”結尾的選項表示的DEBUG版本的，沒有“d”的為RELEASE版本。大型項目中必須要求所有組件和第三方庫的運行時庫是統一的，否則將會出現LNK2005井噴。
單線程運行時庫選項/ML和/MLd在VS2003以后就被廢了。
/MT和/MTd表示采用多線程CRT庫的靜態lib版本。該選項會在編譯時將運行時庫以靜態lib的形式完全嵌入。該選項生成的可執行文件運行時不需要運行時庫dll的參加，會獲得輕微的性能提升，但最終生成的二進制代碼因鏈入龐大的運行時庫實現而變得非常臃腫。當某項目以靜態鏈接庫的形式嵌入到多個項目，則可能造成運行時庫的內存管理有多份，最終將導致致命的“Invalid Address specified to RtlValidateHeap”問題。另外托管C++和CLI中不再支持/MT和/MTd選項。
/MD和/MDd表示采用多線程CRT庫的動態dll版本，會使應用程序使用運行時庫特定版本的多線程DLL。鏈接時將按照傳統VC鏈接dll的方式將運行時庫MSVCRxx.DLL的導入庫MSVCRT.lib鏈接，在運行時要求安裝了相應版本的VC運行時庫可再發行組件包（當然把這些運行時庫dll放在應用程序目錄下也是可以的）。 因/MD和/MDd方式不會將運行時庫鏈接到可執行文件內部，可有效減少可執行文件尺寸。當多項目以MD方式運作時，其內部會采用同一個堆，內存管理將被簡化，跨模塊內存管理問題也能得到緩解。
結論：/MD和/MDd將是潮流所趨，/ML和/MLd方式請及時放棄，/MT和/MTd在非必要時最好也不要采用了。