為什么sizeof實現為運算符而不是宏

Question

我理解為什么sizeof沒有實現為函數的原因是為什么sizeof被認為是運算符？

但我不明白為什么我們需要將sizeof實現為特殊類型的unary operator ，它作為編譯時而非運行時執行（ 我猜其他運算符總是作為運行時執行）

同樣的事情，我們可以做的sizeof微距不是它實現？ 這樣compiled time unary operator和macros什么區別？

---

我只是想知道他們為什么不首先考慮宏而不是實現不同的運算符。 當我第一次想到sizeof（）時，我認為它應該是宏觀的。 沒想到這樣的一元經營者。

Answer 1

你的問題並非毫無根據。 實際上，標准庫已經具有與宏實現的非常相似的特性：它是宏的標准offsetof 。 另請注意， sizeof的可用性的很大一部分來自其編譯時性質（對於offsetof也是如此），這就是為什么運行時實現會明顯低劣的原因。 （而且，BTW，你聲稱所有其他運算符“總是在運行時執行”的斷言聲明完全是不真實的。）

即使在原始C語言中， sizeof無法實現為宏的一個原因是它應該接受類型和表達式作為參數。 使用單個宏來覆蓋這兩種參數是不可能的。 我們至少需要兩個宏：一個用於類型，一個用於表達式。 但即使我們同意將這兩種sizeof形式分成兩個不同的宏，實現一個能夠正確處理表達式參數的宏仍然是相當困難的（甚至是不可能的）。

同時，如果我們將自己局限於原始C（即從考慮C99 VLA中排除），那么我們可以將類型參數的sizeof實現為宏

#define sizeof(T) ((size_t) ((T *) 0 + 1))

這幾乎與用於將標准offsetof實現為宏的技術相同。

上面的宏實現仍然不完美，因為它不適用於int[6]參數，但你明白了。 BTW可能是另一個支持內置運算符實現而不是宏的點。

但是如何為表達式參數做同樣的事情 - 我不知道。 你呢？

Answer 2

宏由預處理器處理。 運算符由編譯器處理。

雖然sizeof(int)可以由預處理器輕松確定，但請考慮sizeof(MyCustomStruct) 。 為了評估它，我們必須知道MyCustomStruct的結構，它只由編譯器評估。

編譯時間超過運行時間的優點當然是性能。 如果你可以在編譯時做一次，為什么在運行時多次這樣做？

Answer 3

其他運算符始終作為運行時執行

那不是真的; 常量表達式中的運算符在編譯時進行計算。 例如， 15 * 60是評估的編譯時間。 除了在C99中引入的VLA之外， sizeof運算符表達式按定義是常量，因此始終在編譯時進行求值。