確認理解和的#define

有很多的教程和quesitons解決這個問題的。但我想在一個具體案例中確認我的理解。以下兩點不應該對編譯器產生影響，即任何一個都是正確的。對？確認理解和的#define

typedef _GridLayoutInputRepeater<_num-1,Figure,_types...> _base;

和

#define _base _GridLayoutInputRepeater<_num-1,Figure,_types...>

同樣的，下面不應該有什麼區別？

#define INT_32 uint32_t

和

typedef uint32_t INT_32;

編輯：跟進線程here

來源

2017-06-23 infoclogged

你確實應該使用'using'。 – Rakete1111

@ Rakete1111：是嗎？你能舉個例子嗎？ – infoclogged

不要使用「下劃線大寫」 [https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier。就個人而言，我不喜歡看到任何前導下劃線，因爲它使得用戶代碼看起來像系統頭文件，但隨着C++被python化，我越來越多地看到它。 –

目前沒有表現出用例2分的情況下都是「平等」的，但你應該注意的是，#define是一個整體與typedef不同的野獸。

typedef引入了另一種類型的一個別名，該別名將由編譯器可以看出，因此將遵循編譯規則，作用域等

甲#define被預處理宏，預處理器將實際編譯之前運行和將從字面上做文本替換，它不關心範圍或任何語法規則，這是相當「愚蠢」的。

通常，typedefs是要走的路，因爲他們是這麼多不容易出錯。在這種情況下，你可以使用using =以及但這是個人喜好，因爲他們都是一樣的：

using _base = _GridLayoutInputRepeater<_num-1,Figure,_types...>;

來源

2017-06-23 10:06:57

在使用的情況下將上述失敗即一個（類型定義）的作品，但其他（＃定義）不？ – infoclogged

@infoclogged [你去]（http://ideone.com/jUoIj8）。 – Rakete1111

@ Rakete1111非常有趣，但爲什麼#define在這裏失敗#define bar int bool bar = true; //失敗。和typedef int bar bool bar = true;成功了！ – infoclogged

使用#define而非typedef或using的問題是，[如已經指出] #define是宏，宏評估和預處理器擴展，所以編譯器不知道你想創建因爲#define指令只需用後一切以取代的數據類型。

其原因在語言如C和C++使用宏是允許的事情是不特異性地與源代碼邏輯做的，但與源代碼結構做。

的#include指令，例如，毫不誇張地包括文件到位derective的全部內容。

所以，如果myfile.h包含：

void func_1(int t); 
void func_2(int t);

然後

#inlude "myfile.h"

將擴大myfile.h的內容，與

void func_1(int t); 
void func_2(int t);

更換#include預處理指令然後，編譯器走來並編譯擴展文件h類定義和其他擴展宏！

這就是爲什麼宏觀

#pragma once

或

#ifndef __MYFILE_INCLUDE__ 
#define __MYFILE_INCLUDE__

是在頭文件開始時使用，以防止發生多種定義。

當您使用表達式像#define INT64 unsigned int預處理程序所做的完全一樣的東西。它評估表達式，然後用unsigned int替換所有出現的INT64。

當您使用typedef，而另一方面，編譯器可以進行類型替代，這意味着編譯器警告不正確使用新創建的類型。

#define只會提醒您錯誤地使用了unsigned int，如果您有很多類型替換會變得令人困惑！

來源

2017-06-23 11:19:29 GCUGreyArea

確認理解和的#define

回答

相關問題