On Tue, Mar 11, 2014 at 9:01 AM, Gedare Bloom <ged...@rtems.org> wrote:
> 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.
>
I wrote a simple test program that shows the size compiled with any
optimizations turned on is the same, although without optimization the
function is not inlined. Also, with the right warnings enabled, option
1 does provide a warning if there is a type mismatch.
So I am inclined to agree that Option 1 should be promotoed now and in
the future.
> -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
