德爾福常數按位表達式

可能是一個愚蠢的問題，但它對我來說是一種閒置的好奇心。德爾福常數按位表達式

我有一些Delphi代碼，看起來像這樣;

 
const 
    KeyRepeatBit = 30; 

... 
    // if bit 30 of lParam is set, mark this message as handled 
    if (Msg.lParam and (1 shl KeyRepeatBit) > 0) then 
    Handled:=true; 
...

（代碼的目的並不重要）

該編譯器看到「（1個SHL KeyRepeatBit）」的東西，可以在編譯時計算的，因此它變成一個常數？如果不是，將數字作爲數字並用數字替換表達式會有什麼好處？

來源

2009-07-22 robsoft

是的，編譯器在編譯時計算表達式並將結果值用作常量。用自己的結果值聲明另一個常量沒有任何好處。

編輯：The_Fox是正確的。在這種情況下，可分配的類型常量（參見{$J+}編譯器指令）不被視爲常量，並且在運行時計算表達式。

來源

2009-07-22 10:40:33

謝謝，這就是我所需要的。 :-) – robsoft 2009-07-22 10:42:59

您忘記了可寫常量;）在這種情況下，表達式會在運行時被評估爲 – 2009-07-22 12:41:13

它在編譯時將其轉換爲常量。

但是，即使沒有，這對應用程序的性能也沒有明顯的影響。

如果您的應用程序繁忙，則您可能每秒處理幾千條消息。你的舊奔騰我可以做每秒輪換和安士的超聲波。

保持您的代碼可讀性，並對其進行概要分析，以找出您隨後優化的瓶頸 - 通常是通過查看算法，而不是像是否在移位那樣的低級別。

來源

2009-07-22 10:40:37 Will

我懷疑在這裏使用一個數字（將是1073741824，）會真的提高性能。您似乎在某些Windows消息上下文中，這可能會增加比單個更多的延遲，並且即使編譯時未優化該數字（無論如何，我認爲它已優化），它閃電般快。

唯一的例外，我能想象將是代碼的這件特定的運行真的經常出現的情況，但正如我所說，我認爲這個被在編譯時進行了優化，所以即使在這種情況下，它不會使根本不同。

來源

2009-07-22 10:41:40 schnaader

+1，因爲它會影響工作1 shl 30！ :-) – robsoft 2009-07-22 10:44:12

您可以確保就像和這個，單獨可讀性：

const 
    KeyRepeatBit = 30; 
    KeyRepeatMask = 1 shl KeyRepeatBit ;

來源

2009-07-22 10:42:35

也許這是offtopic你的問題，但我使用的情況下，記錄這幾樣東西，例如：

TlParamRecord = record 
    case Integer of 
     0: (
     RepeatCount: Word; 
     ScanCode: Byte; 
     Flags: Set of (lpfExtended, lpfReserved=4, lpfContextCode, 
      lpfPreviousKeyState, lpfTransitionState); 
    ); 
     1: (lParam: LPARAM); 
    end;

看article on my blog瞭解更多詳情

來源

2009-07-23 13:55:18 Remko

德爾福常數按位表達式

回答

相關問題