Empty static inlines normally optimize away. So no worries there.
I always prefer static inlines over macros.
Do you have specific example? There are places this may work but
others that it cannot.
--joel
On 3/11/2014 8:01 AM, Gedare Bloom 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.
>
> -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
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
