Am 07.05.2013 22:37 schrieb "Daniel Krügler" <daniel....@gmail.com>:
>
> 2013/5/7 <andrew...@gmail.com>:
> > If there is no difference, why not simplify by replacing all occurrences of
> > one with the other?
>
> I think the main reason here is that in some parts the focus is on
> ill-formedness with required diagnostics being a flavour in regard to
> the specification, but sometimes not. But I cannot give a very good
> reason otherwise.
>
I have heard the statement that illformed; NDR is for cases that an implementation could in principal diagnose if it works hard enough (if had whole program optimization or a sufficient intelligent linker for instance).
And that undefined behavior is used for the remaining cases and for the "no explicit behavior defined" (for example there is no behavior defined for the case when a resource limit is exceeded).
2013/5/8 Jens Maurer <Jens....@gmx.net>:
> On 05/08/2013 05:49 AM, andrew...@gmail.com wrote:
>> If this were true, than you would expect that the ~50 cases that are
>> designated undefined behaviour would be in general harder to diagnose
>> than the ~40 cases designated illformed NDR. Reading through each
>> case however, this trend does not seem to be present. There seems to
>> be no correlation between the difficult of diagnosis and the
>> selection of the two phrasings.
>
> I always considered "ill-formed, no diagnostic required" something that
> could (in principle) be checked at translation time, e.g. during
> linking.
>
Am 08.05.2013 20:44 schrieb "Jens Maurer" <Jens....@gmx.net>:
>
> On 05/08/2013 08:43 AM, Daniel Krügler wrote:
> > Aren't the following cases at least theoretically testable during compile-time:
> >
> > a) [lex.phases] p1 b2:
> >
> > "If, as a result, a character sequence that matches the syntax of a
> > universal-character-name is produced, the behavior is undefined."
>
> Yes.
>
> > b) dito b4:
> >
> > "If a character sequence that matches the syntax of a
> > universal-character-name is produced by token concatenation (16.3.3),
> > the behavior is undefined."
>
> Yes.
>
> > c) [lex.pptoken] p2:
> >
> > "The categories of preprocessing token are: header names, identifiers,
> > preprocessing numbers, character literals
> > (including user-defined character literals), string literals
> > (including user-defined string literals), preprocessing
> > operators and punctuators, and single non-white-space characters that
> > do not lexically match the other
> > preprocessing token categories. If a ’ or a " character matches the
> > last category, the behavior is undefined."
>
> Yes.
>
> > d) [basic.def.odr] p6:
> >
> > "If the definitions of D do not satisfy these requirements, then the
> > behavior is undefined."
>
> Yes.
>
> > e) [temp.dep.candidate] p1:
> >
> > "If the call would be ill-formed or would find a better match had the
> > lookup within the associated namespaces
> > considered all the function declarations with external linkage
> > introduced in those namespaces in all
> > translation units, not just considering those declarations found in
> > the template definition and template
> > instantiation contexts, then the program has undefined behavior."
>
> Yes.
>
> It seems all your examples should be "ill-formed, no diagnostic
> required". Could you please send e-mail to Mike Miller to open
> a core issue?
>
And I recommend adding an issue report about a missing (non normative) note about the difference.
Otherwise we will find ourselfs with the same discussion in 2016 and we will showcase other counterexamples added by C++14 wording.
> Thanks,
> Jens
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
> To post to this group, send email to std-dis...@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/?hl=en.
>
>