[cfe-dev] integer constant expression oh my!

[Cédric Venet]

Eli Friedman a écrit :
> On Mon, Nov 17, 2008 at 12:43 PM, Doug Gregor <doug.gregor at gmail.com> wrote:
>> On Mon, Nov 17, 2008 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Nov 17, 2008 at 10:47 AM, Doug Gregor <doug.gregor at gmail.com> wrote:
>>>> We have to instantiate the correct template *declaration* as part of
>>>> type-checking. We don't have to instantiation the template
>>>> *definition* until we try to evaluate the value of the expression.
>>> Right... but I'm pretty sure we're still going to instantiate it
>>> before we try to evaluate the value of the expression.  Take the
>>> following program:
>>>
>>> template <int i> int f(int (*a)[-i]) {
>>>  int b[i]; return 2;
>>> }
>>> int b() {return 0 ? f<-1>(0) : 0;}
>>>
>>> I'm pretty sure we're still supposed to emit a diagnostic (at the very
>>> least, g++ does).
>> Yes, it emits a diagnostic. However, the diagnostic actually comes
>> later on, since GCC (like many compilers) delays the instantiation of
>> function templates until the end of the translation unit. (Or later,
>> if one is using a prelinker-based approach like the one EDG supports).
>>
>>>  In -fsyntax-only mode, there isn't anything after
>>> Sema; therefore, Sema has to force the instantiation of the definition
>>> at some point.  The only reasonable place to force the instantiation
>>> of the definition is when Sema processes the call to f<-1>.  This is
>>> before the call exists in the AST, so the template will be
>>> instantiated before we might want to evaluate it.
>> If you add a bit of bogus code that doesn't involve templates to the
>> end of your example and run it through GCC, you'll see that the error
>> message for the problem inside f<-1> comes *after* the error messages
>> for that bogus code. That's the delay in performing the instantiation.
>> It can be helpful: for one, it means that error messages due to failed
>> instantiations of function templates don't come from inside the bodies
>> of other functions that just happen to use the broken template.
> 
> Hmmm, interesting.
> 
> Actually, it looks like C++0x is making some significant changes to
> the definitions of constant expressions. I think we'll just have to
> wait until C++0x stabilizes a bit more, then figure out what's going
> on... the current draft looks convenient to implement, but it seems
> like they didn't think through the effect of the changes on
> floating-point arithmetic, and I'm not sure it leaves constexpr as
> usable as they might want.
> 

I was under the impression that
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf
would be the same as the final version except for a few minor 
clarrification. I am wrong?