Re: [boost] [config] [chrono] consexpr workaround

Subject: Re: [boost] [config] [chrono] consexpr workaround
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-03-19 18:44:10

Le 19/03/13 22:25, Krzysztof Czainski a écrit :
> 2013/3/19 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>
>> Le 19/03/13 17:00, Krzysztof Czainski a écrit :
>> So now, narrowing the question to use of
>>
>>> BOOST_CONSTEXPR in Boost.Chrono:
>>> 1. Could the functions marked BOOST_CONSTEXPR be also marked inline (and
>>> this question probably applies to other Boost libraries)?
>>> 2. This is probably related only to the TI compiler I use: marking
>>> constructors inline doesn't work for me, they need to be marked
>>> BOOST_FORCEINLINE (I've configured it), so could the constexpr
>>> constructors
>>> in Boost.Chrono be marked with BOOST_FORCEINLINE as well?
>>>
>>>   Hi,
>> could you point me to the cases that need to be inlined that the compiler
>> doesn't inline by itself?
>>
>> Please create a ticket so that I don't forget it.
>>
>> Best,
>> Vicente
>
> Hi Vincente,
>
> Thanks for looking at this.
>
> I think this TI compiler doesn't inline anything not marked inline.
> Additionally it doesn't seem to inline constructors, unless marked
> BOOST_FORCEINLINE [1].
>
> So if there aren't any thoughts against this, I suggest all constexpr
> functions in duration and time_point to be marked inline, and constexpr
> constructors to be marked forceinline. Or should I just touch the cases,
> that need to be inline in my example situation? I'd prefer the former ;-)
>
> I'll create a ticket and supply a patch shortly.
>
> Cheers,
> Kris
>
> [1] The TI compiler supports the GCC extension attribute forceinline.
>
>
What makes the consexpr functions different from the other functions 
that the compiler could inline and it doesn't?
Are you proposing that all the boost libraries uses BOOST_FORCEINLINE on 
all the functions defined in the declaration?

Vicente