Named fields in Structure Initialization

[Gedare Bloom]

On Fri, Aug 10, 2012 at 4:00 PM, Joel Sherrill <joel.sherrill at oarcorp.com>wrote:

> On 08/10/2012 02:36 PM, Steven Grunza wrote:
>
>> -----Original Message-----
>>> From: rtems-devel-bounces at rtems.org [mailto:rtems-devel-
>>> bounces at rtems.org] On Behalf Of Joel Sherrill
>>> Sent: Friday, August 10, 2012 3:27 PM
>>> To: rtems-devel at rtems.org
>>> Subject: Named fields in Structure Initialization
>>>
>>> Hi
>>>
>>> I was looking at the definition of the default pthread_attr_t in
>>> cpukit/posix/src/pthread.c. What's the consensus on explicitly
>>> naming fields as opposed to using order to resolve things.
>>>
>>> In the filesystem code, I think it is all named now. I was thinking
>>> of changing this over to something like this:
>>>
>>> const pthread_attr_t _POSIX_Threads_Default_**attributes = {
>>>
>>>     .is_initialized = true,                       /* is_initialized
>>> */
>>>     .stackaddr = NULL,                            /* stackaddr */
>>>     .stacksize = 0,                               /* stacksize --
>>> will be
>>> adjusted to minimum */
>>>     .contentionscope = PTHREAD_SCOPE_PROCESS,     /* contentionscope
>>> */
>>>     .inheritsched = PTHREAD_INHERIT_SCHED,        /* inheritsched */
>>>     .schedpolicy = SCHED_FIFO,                    /* schedpolicy */
>>>     .schedparam = {                               /* schedparam */
>>>       .sched_priority = 2,                        /* sched_priority
>>> */
>>>       #if defined(_POSIX_SPORADIC_**SERVER) || \
>>>           defined(_POSIX_THREAD_**SPORADIC_SERVER)
>>>         .sched_ss_low_priority = 0,               /*
>>> sched_ss_low_priority */
>>>         .sched_ss_repl_period = { 0L, 0 },        /*
>>> sched_ss_repl_period */
>>>         .sched_ss_init_budget = { 0L, 0 }         /*
>>> sched_ss_init_budget */
>>>       #endif
>>>     },
>>>
>>>     #if defined(_POSIX_THREAD_CPUTIME)
>>>       .cputime_clock_allowed = 1,                 /*
>>> cputime_clock_allowed */
>>>     #endif
>>>
>>>     .detachstate = PTHREAD_CREATE_JOINABLE,       /* detachstate */
>>>
>>> };
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research&
>>>
>> Wow, just goes to prove there's always something new to learn.  I was
>> unaware of this ability in C to explicitly name fields like this.
>>
> :) I must admit to learning this from the RTEMS Community also. :)
>
> These are called "designated initializers" c.f.
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

They don't work for headers that are included from C++ code; i.e. C++ does
not compile them properly. That is one concern I know about. But for a
plain C file they should be OK to use.

-Gedare


>  It seems to me that using explicit naming would decrease problems caused
>> by adding a new field to the structure but neglecting to update the
>> initialization.  I don't see a downside to this change, other than the
>> effort required to make the change.
>>
>>
> It is trading one risk for another. Without explicitly naming
> the fields, there is a risk that you didn't initialize things
> in the right order and "it just works". Or that a new field
> got added and it just continues to compile.
>
> This way, it will compile unless a field changes names but
> there is a risk that when new fields are added to the structure,
> it will not be automatically be caught.
>
> I like it now that some of the code has started doing it.
>
> --
> Joel Sherrill, Ph.D.             Director of Research&   Development
> joel.sherrill at 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 at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120810/9446fbf9/attachment-0001.html>