Re: #define and (brackets)

"David Webber" <dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23dF9SKaTJHA.5080@xxxxxxxxxxxxxxxxxxxxxxx

"Gerry Hickman" <gerry666uk2@xxxxxxxxxxxxxxxx> wrote in message
news:%23nDeGJNTJHA.6060@xxxxxxxxxxxxxxxxxxxxxxx

#define DELETE (0x00010000L)
#define READ_CONTROL (0x00020000L)
#define WRITE_DAC (0x00040000L)
#define WRITE_OWNER (0x00080000L)
#define SYNCHRONIZE (0x00100000L)

What's the deal?

The L was once needed to define a 32bit integer, as has been said.

Brackets are quite generally a very good habit to get into in defining
things. They may not make much difference in this case but in many
cases they are absolutely crucial.

Consider either

#define one_more_than(x) x+1

True, but for a numerical constant using brackets may actually *hide* coding
errors. For instance, consider the following:

#define SHRINK_BOX_AMOUNT -20

CRect rct(l,t,r,b);
rct.DeflateRect(-SHRINK_BOX_AMOUNT, -SHRINK_BOX_AMOUNT);

leads to a compiler error (cannot decrement an rvalue). So by leaving out
the brakets you are implicitly saying that this quantity is *negative* which
is something you can't tell without looking at the actual #define.

Conversely:

#define SHRINK_BOX_AMOUNT (-20)

CRect rct(l,t,r,b);
rct.DeflateRect(-SHRINK_BOX_AMOUNT, -SHRINK_BOX_AMOUNT);

Compiles fine, even though that it's clear that the intention is to make a
smaller box, not a larger one.

- Alan Carre


.

Relevant Pages

  • Re: Program does not invoke methods of ActiveX-DLL
    ... "Dermot Hardy" wrote: ... If you're calling a sub then you mustn't use brackets (unless you're ... > compiler error. ... >> the main programm can access the properties of the objects inside the dlls ...
    (microsoft.public.vb.com)
  • Re: #define and (brackets)
    ... Brackets are quite generally a very good habit to get into in defining things. ... Clearly the guy who wrote the first lot, didn't bother thinking about whether he could safely miss them out. ...
    (microsoft.public.vc.language)
Loading