On Tue, Mar 11, 2014 at 4:47 AM, Sebastian Huber
<sebastian.hu...@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.hu...@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@rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
