Compiling C++ Templates as opposed to Preprocessing them.
in [C++]
|
Prev: basic concatenation question
Next: type casting issue
From: Johannes Schaub (litb) on 8 Aug 2010 06:49 Walter Bright wrote: > Nikolay Ivchenkov wrote: >> in the standard? I don't see. So if your interpretation would be >> correct, how exactly the bounds of a template should be determined? > > It doesn't matter as long as it correctly parses the rest of the file, and > diagnoses template definition errors when the template definition is > instantiated. I don't see any conflict, and believe that interpretation is > in conformance with the Standard. For your interpretation to be correct, > we have to agree that the examples in the Standard are invalid, and have > to impute extra conditions into "if no valid specialization can be > generated", etc. > > If the Standard means something, it should come out and say it rather than > relying on such, especially something as straightforward as this should > be. It already does, as Nikolay pointed out in great detail. How is "if no valid specialization can be generated for a template definition..." not clearly stating that all the text following applies only to template definitions, and not to any other random sequence of tokens? I think the Standard just has a wrong example, but clear normative text that seems to render your compiler non-conforming. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 9 Aug 2010 11:24 Johannes Schaub (litb) wrote: > Walter Bright wrote: > >> Nikolay Ivchenkov wrote: >>> in the standard? I don't see. So if your interpretation would be >>> correct, how exactly the bounds of a template should be determined? >> It doesn't matter as long as it correctly parses the rest of the file, and >> diagnoses template definition errors when the template definition is >> instantiated. I don't see any conflict, and believe that interpretation is >> in conformance with the Standard. For your interpretation to be correct, >> we have to agree that the examples in the Standard are invalid, and have >> to impute extra conditions into "if no valid specialization can be >> generated", etc. >> >> If the Standard means something, it should come out and say it rather than >> relying on such, especially something as straightforward as this should >> be. > > It already does, as Nikolay pointed out in great detail. How is "if no valid > specialization can be generated for a template definition..." not clearly > stating that all the text following applies only to template definitions, > and not to any other random sequence of tokens? That is a good point. > I think the Standard just has a wrong example, but clear normative text that seems to render your > compiler non-conforming. Perhaps. I should do more reading on this. Even so, it's irrelevant to generating a working program from source text, as I mentioned. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nikolay Ivchenkov on 9 Aug 2010 11:25 On 8 Aug, 07:03, Walter Bright <newshou...(a)digitalmars.com> wrote: > Nikolay Ivchenkov wrote: > > in the standard? I don't see. So if your interpretation would be > > correct, how exactly the bounds of a template should be determined? > > It doesn't matter as long as it correctly parses the rest of the file What is the rest of the file? You can't determine it without applying the syntactic rules. > For your interpretation to be correct, we have to agree that the examples in the Standard > are invalid, Yes. > and have to impute extra conditions into "if no valid specialization can be generated", No. "If no valid specialization can be generated for a template definition..." already refers to a template definition, not to an arbitrary sequence of tokens. A template definition is a template- declaration whose declaration (see the syntax of template-declaration) defines a function, a class, or a static data member - see 14/1. The syntax of declarations is defined in the clause 7. If you or compiler can't prove that some sequence of tokens is a template-declaration then you/compiler can't prove that it is a template definition for which no diagnostic is required. Is it so difficult to understand this? > etc. What's this? > If the Standard means something, it should come out and say it The standard contains a formal description of requirements for implementations. If you can't understand a consequences of a correct formal description, that's your problem. > Furthermore, I don't see any *point* to the Standard requiring a diagnostic on this. That's for people who like early diagnostics for errors. Though, this approach has disadvantages. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 10 Aug 2010 05:29 Nikolay Ivchenkov wrote: > On 8 Aug, 07:03, Walter Bright <newshou...(a)digitalmars.com> wrote: >> If the Standard means something, it should come out and say it > > The standard contains a formal description of requirements for > implementations. If you can't understand a consequences of a correct > formal description, that's your problem. It isn't just my problem. Even the examples in the Standard are incorrect, so obviously plenty of language lawyers are misunderstanding it. Furthermore, any non-trivial Standard contains mistakes. Trying to figure out the consequences of low level stuff on higher order stuff can produce unintended higher level behavior, hence it is quite reasonable to spell out the intended higher order behavior in an example or in a footnote. Such can save much agony not only for compiler implementors, but users as well. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Johannes Schaub (litb) on 11 Aug 2010 16:36
Walter Bright wrote: > Nikolay Ivchenkov wrote: >> On 8 Aug, 07:03, Walter Bright <newshou...(a)digitalmars.com> wrote: >>> If the Standard means something, it should come out and say it >> >> The standard contains a formal description of requirements for >> implementations. If you can't understand a consequences of a correct >> formal description, that's your problem. > > It isn't just my problem. Even the examples in the Standard are incorrect, so > obviously plenty of language lawyers are misunderstanding it. > > Furthermore, any non-trivial Standard contains mistakes. Trying to figure out > the consequences of low level stuff on higher order stuff can produce unintended > higher level behavior, hence it is quite reasonable to spell out the intended > higher order behavior in an example or in a footnote. Such can save much agony > not only for compiler implementors, but users as well. > Actually, the '97 drafts have different wording. It's interesting to see how it evolved. It read "Knowing which names are type names allows the syntax of every template definition to be checked. A diagnostic shall be issued for a syntactically ill-formed template definition. [Note: that means that a diagnostic must be issued even if the template is never instantiated. ..." And it has the same example with the "+" and says a diagnostic shall be generated. Now, it seems the standard's body just took this paragraph and reworded it to allow accepting "syntactically ill-formed template definitions", whatever that might be. :) Apparently, people are very open to what can be left without diagnostics - your compiler for instance seems to accept a TU solely consisting of "%+*!^~" without emitting a diagnostic. I always wanted a compiler that doesn't moan all that much at me, great! -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |