[gmx-developers] Re: gmx-developers Digest, Vol 96, Issue 16

Peter Kasson kasson at stanford.edu
Wed Apr 11 15:16:13 CEST 2012


> Date: Wed, 11 Apr 2012 14:33:09 +0200
> From: Erik Marklund <erikm at xray.bmc.uu.se>
> Subject: Re: [gmx-developers] Coordinate scaling in pdbio.c
[...]
>>>>>> What happened to A2NM and NM2A?
>>>>>> In my (4.0.5, yes that is very old) includes/physics.h I still see:
>>>>>>
>>>>>> #define A2NM (ANGSTROM/NANO) /* NANO */
>>>>>> #define NM2A (NANO/ANGSTROM) /* 10.0 */
>>>>>>
>>>>>> Why aren't these still used for that?
>>>>>>
>>>>>>
>>>>> At some stage macros were removed from the code, even though these seem rather harmless. I agree that it is confusing to hard code these numbers. If we cannot use macro's like this we should probably replace them by
>>>>> static const real ANGSTROM=1e-10;
>>>>> static const real NANO=1e-9;
>>>>>
>>>>> etc.
>>>>>
>>>>> Comments?
>>>>
>>>> include/physics.h still has these macros. IMO, hard-coded constants are a greater evil than macros to prevent that, though I expect we will transition to const values at some stage soon.
>>>
>>> But are these the kind of macros we want to avoid? Aren't function-like macros the ones to kill in the first place?
>>  They're taking no parameters, so they're hardly function-like. The code fragments above are compiled into constants by the pre-processor. A macro that is used as
>>
>> dist_in_nm = dist_in_angstrom * A2NM;
>>
>> is much less evil than a macro
>>
>> dist_in_nm = A2NM(dist_in_angstrom);
>
> My point exactly. I'm just not seeing the harm in using macros in cases like these.

Consts are preferred (not #defines but actual consts).

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Preprocessor_Macros



More information about the gromacs.org_gmx-developers mailing list