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
>>> in Boost.Chrono be marked with BOOST_FORCEINLINE as well?
>> 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.
> 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 .
> 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.
>  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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk