CODEWITHSUNDEEP
delphioptimization
robsoft
robsoft

Reputation: 5585

Delphi constant bitwise expressions

Probably a stupid question, but it's an idle curiosity for me.

I've got a bit of Delphi code that looks like this;

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;
...

(the purpose of the code isn't really important)

Does the compiler see "(1 shl KeyRepeatBit)" as something that can be computed at compile time, and thus it becomes a constant? If not, would there be anything to gain by working it out as a number and replacing the expression with a number?

Upvotes: 6

Views: 582

Answers (5)

Remko
Remko

Reputation: 7340

Maybe it's offtopic to your question but I use a case record for these kind of things, example:

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

see article on my blog for more details

Upvotes: 1

Ondrej Kelle
Ondrej Kelle

Reputation: 37211

Yes, the compiler evaluates the expression at compile time and uses the result value as a constant. There's no gain in declaring another constant with the result value yourself.

EDIT: The_Fox is correct. Assignable typed constants (see {$J+} compiler directive) are not treated as constants and the expression is evaluated at runtime in that case.

Upvotes: 7

Henk Holterman
Henk Holterman

Reputation: 273274

You can make sure iike this, for readability alone:

const
  KeyRepeatBit = 30;
  KeyRepeatMask = 1 shl KeyRepeatBit ;

Upvotes: 4

schnaader
schnaader

Reputation: 49719

I doubt that using a number (would be 1073741824, by the way) here would really improve performance. You seem to be in some Windows message context here and this will possible add more delay than a single and that is lightning fast even if the number is not optimized at compiled time (anyway, I think it is optimized).

The only exception I could imagine would be the case that this particular piece of code is run really often, but as I said I think this gets optimized at compile time and so even in this case it won't make a difference at all.

Upvotes: 2

Will
Will

Reputation: 75635

It converts it to a constant at compile time.

However, even if it didn't, this would have no noticeable impact on your application's performance.

You might handle a few thousand messages per second if your app is busy. Your old Pentium I can do gazillions of shifts and ands per second.

Keep your code readable, and profile it to find bottlenecks that you then optimize - usually by looking at the algorithm, and not such a low level as whether you're shifting or not.

Upvotes: 3

Related Questions