Re: [Xenomai] [Xenomai-git] Jan Kiszka : alchemy: Replace static variable no_alchemy_task with macro

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2014-02-04 18:53, Philippe Gerum wrote:
> On 02/04/2014 06:48 PM, Philippe Gerum wrote:
>> On 02/04/2014 06:44 PM, Gilles Chanteperdrix wrote:
>>> On 02/04/2014 06:39 PM, Philippe Gerum wrote:
>>>> On 02/04/2014 06:32 PM, Gilles Chanteperdrix wrote:
>>>>> On 02/04/2014 06:27 PM, Philippe Gerum wrote:
>>>>>> If g++ chokes on the initializer part because it is outdated, then
>>>>>> using
>>>>>> old-fashioned ones may be an option. Actually, I find macroizing this
>>>>>> definition quite bad.
>>>>>>
>>>>>> static const RT_TASK no_alchemy_task = {
>>>>>> -    .handle = 0,
>>>>>> -    .thread = 0
>>>>>> +    handle: 0,
>>>>>> +    thread: 0
>>>>>>     };
>>>>>
>>>>> No, the previous version is better, it is standard compliant C and
>>>>> C++,
>>>>> the second version is a gcc extension, which works only when compiling
>>>>> C, if I remember correctly.
>>>>>
>>>>
>>>> Recent g++ is happy with both (no -std forced though). But the
>>>> former is
>>>> allowed by the C++ parser only since recently.
>>>>
>>>
>>> Well, on the other hand:
>>> static const RT_TAKS no_alchemy_task;
>>>
>>> Will zero initialized the structure just as well...
>>>
>>
>> In that case you will have the object exist in the .bss.
>>
> 
> It turns out that old gcc 4.x releases will create a private bss entry
> for this symbol in any case, which recent ones won't produce regardless
> of the optimizing level (unless I messed up with nm, but it does not
> seem so).
> 

Then what is so bad about the symbolic NO_ALCHEMY_TASK? The code will be
the same anyway.

BTW, there are way more issues with C++ when enabling standard
compliance. Not sure where all the errors come from and if they easy to
fixing. But I think we should try to be as clean as possible in out
external interfaces.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux