It won't. The compiler will dead code away any branches where the test evaluates to a constant.
On 27 Mar 2016 3:30 p.m., "Programmingkid" <
address@hidden> wrote:
On Mar 26, 2016, at 2:48 AM, Alex Bennée wrote:
>
> Programmingkid <address@hidden> writes:
>
>> Add debug macros to the code for easier debugging.
>>
>> Signed-off-by: John Arbuckle <address@hidden>
>> ---
>> hw/input/hid.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/hw/input/hid.c b/hw/input/hid.c
>> index 329a27b..42ca592 100644
>> --- a/hw/input/hid.c
>> +++ b/hw/input/hid.c
>> @@ -37,6 +37,13 @@
>> #define RELEASED -1
>> #define PUSHED -2
>>
>> +/* #define DEBUG_HID_CODE */
>> +#ifdef DEBUG_HID_CODE
>> + #define DEBUG_HID(fmt, ...) printf(fmt, __VA_ARGS__)
>> +#else
>> + #define DEBUG_HID(fmt, ...) (void)0
>> +#endif
>> +
>
> This style of debug setup is discouraged these days as its prone to
> bitrot. It's better to define like this:
>
> #define DEBUG_HID(fmt, ...) \
> if (DEBUG_HID_CODE) { \
> printf(fmt, __VA_ARGS);\
> }
>
> This means you get the benefit of the compiler checking your format
> strings even if the code gets optimised away when DEBUG_HID_CODE isn't
> defined.
I don't like if conditions in the debug macro because they do take up cpu time. The (void)0 is just zero. I don't think it would take any cpu time away from the program.