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" <programmingk...@gmail.com>
wrote:
>
> On Mar 26, 2016, at 2:48 AM, Alex Bennée wrote:
>
> >
> > Programmingkid <programmingk...@gmail.com> writes:
> >
> >> Add debug macros to the code for easier debugging.
> >>
> >> Signed-off-by: John Arbuckle <programmingk...@gmail.com>
> >> ---
> >> 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.
