Op 10-Oct-16 om 4:41 PM schreef smplx:
>
> On Mon, 10 Oct 2016, Wouter van Ooijen wrote:
>
>> Op 10-Oct-16 om 2:45 PM schreef smplx:
>>> On Mon, 10 Oct 2016, Wouter van Ooijen wrote:
>>>
>>>> In your idea, as a user, can I be *sure* that a certain (complicated)
>>>> part is run by the compiler at compilation?
>>>>
>>>> In C++ 0x14 you can
>>>>
>>>> - declare any function as constexper, which means that the compiler mu=
st
>>>> check that it can evaluate that function at compile time (provided tha=
t
>>>> it knows the arguments at compile time). Such a function is still usab=
le
>>>> at run time too.
>>>>
>>>> - declare any const value as constexpr, which means that the compiler
>>>> must evaluate it at compile time.
>>>>
>>>> There isn't much special about a constexpr function that isn't obvious
>>>> (like: it can't access globals, can't do memory allocation, etc.).
>>> Hi Wouter,
>>>
>>> The short answer is yes - if you declare a constant and use a function =
to
>>> initalise it that does not depend on external unknowns.
>>>
>>> The longer answer is "it is not intended to be restricted that way". Wh=
en
>>> I explained how functions could be executed at compile time this was an
>>> attempt to quickly focus the reader on an obvious benefit. The reallity
>>> however is that compile time execution goes way beyond what I described=
..
>>> It opens up a huge number of possibilites for deep analysis and
>>> optimisation which I have not described. It is not just about executing
>>> functions as a unit but about executing as much of the code as possible
>>> without the function call acting as a barrier.
>>>
>>> What I would like to see users doing is writing code that describes the
>>> process they need to achive and let the compiler worry about the
>>> optimisation.
>> IMO that sounds good, but it is what an optimizer should do anyway. On
>> top of that, you (as an application writer) want guarantees that certain
>> parts are pre-caclulated. That is not worrying, that is getting certaint=
y.
>>
> Hi Wouter,
>
> If you are saying that you want to be able to guarantee that calling a
> function at a given place in your code will always cause the compiler to
> execute it at compile time then yes I could easily add a keyword (or some
> other simple mechanism) that will do that. It would not be hard at all.
>
> e.g.
>   	int x =3D (execute now)fred();
>
> I guess I could even add an attribute to the function itself so that it
> only ever gets executed by the compiler, that would not be hard either.
I don't think that would be useful, in general you'd want to write code=20
that can run either at compile time or at run time. It is the use (the=20
call) that you want to control.

succes!
Wouter

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.