Empty inline functions vs. empty CPP macros

Gedare Bloom gedare at rtems.org
Tue Mar 11 13:01:38 UTC 2014


On Tue, Mar 11, 2014 at 4:47 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> I would like to add a new section to the RTEMS coding style.  How do we want
> to deal with features available only in case certain pre-processor symbols
> are defined?  For example
>
> #define FEATURE_X
>
> 1:
>
> static inline feature_x_func(int a, double b, void *c)
> {
> #ifdef FEATURE_X
>   /* Do something */
> #else
>   (void) a;
>   (void) b;
>   (void) c;
> #endif
> }
>
> 2:
>
> #ifdef FEATRUE_X
> static inline feature_x_func(int a, double b, void *c)
> {
>   /* Do something */
> }
> #else
> #define feature_x_func(a, b, c) do { } while ( 0 )
> #endif
>
> 3:
>
> #ifdef FEATRUE_X
> static inline feature_x_func(int a, double b, void *c)
> {
>   /* Do something */
> }
> #else
> #define feature_x_func(a, b, c) \
>   do { (void) *a); (void) (b); (void) (c); } while ( 0 )
> #endif
>
> I am in favor of variant 1. since it has the benefit that type checks are
> also performed in case feature X is disabled.
>
The advantage of checks is a good reason. I don't like option 3.

> Is the optimization of an empty inline function really a problem for modern
> compilers?
>
If no one knows, it should not take long to write a simple program to check.

> In 2. we could also use an (for basedefs.h)
>
> #define RTEMS_EMTPY_MACRO do { } while ( 0 )
>
This option is "cleaner-looking" which is my preference for code
readability. However the technical advantage of having the same
function call invocation and thus type checks with option #1 is a good
reason for it. I'm on the fence at the moment. I would like to get
resolution about the question of optimizing compilers first.

If the code size is the same with the two approaches, then I'm fine
with option 1.

-Gedare

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel




More information about the devel mailing list