Compiling C++ Templates as opposed to Preprocessing them.
in [C++]
|
Prev: basic concatenation question
Next: type casting issue
From: Nikolay Ivchenkov on 6 Aug 2010 19:09 Nikolay Ivchenkov wrote: > potential-statement-seq: > potential-statement-seq opt { potential-statement-seq opt } > not-a-brace-seq Correction: potential-statement-seq: potential-statement-seq-lhs-seq not-a-brace-seq potential-statement-seq-lhs-seq not-a-brace-seq potential-statement-seq-lhs-seq: potential-statement-seq-lhs-seq opt potential-statement-seq- lhs potential-statement-seq-lhs: not-a-brace-seq opt { potential-statement-seq opt } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: CornedBee on 7 Aug 2010 10:20 On Aug 5, 8:28 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > CornedBee wrote: > > > A conforming compiler will compile this program to print "Template". VC > > ++ compiled it to print "Plain". > > Digital Mars C++ compiles it and prints "Template", yet uses token caching. > I get it, your implementation uses token caching and works. Stop being so defensive ;) > > If you have a better idea, I'd be interested in hearing about it. > > Just keep track of the source locations of each definition in the symbol table. > You probably do that already for the symbolic debug info. Ah, so you filter the by location? Yeah, I can see how that is possible, although it doesn't sound too efficient to me. (But then, comparing source locations for absolute position is something that is inefficient in Clang's implementation, but needn't be in any other.) Sebastian -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 7 Aug 2010 12:03 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. I should add that the C++0x Concepts proposal did specifically require that diagnostics be generated even without instantiations - I requested that this requirement be removed, and it was, and I thank the Committee members for their indulgence of my request. Furthermore, I don't see any *point* to the Standard requiring a diagnostic on this. It's not a problem that needs fixing. It's purely a QoI issue, and the Standard should not involve itself with that. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 7 Aug 2010 12:02 {This article seems to be merely a quote of the original article and it is thus rejected from comp.lang.c++.moderated. -mod/dk} Nikolay Ivchenkov wrote: > On 6 Aug, 07:30, Walter Bright <newshou...(a)digitalmars.com> wrote: >> Nikolay Ivchenkov wrote: >>> On 5 Aug, 06:15, Walter Bright <newshou...(a)digitalmars.com> wrote: >>>> Nikolay Ivchenkov wrote: >>>>> On 4 Aug, 08:30, Walter Bright <newshou...(a)digitalmars.com> wrote: >>>>>> My reading of C++98 was that the compiler was not required to issue a diagnostic >>>>>> for a malformed definition if it was never instantiated. >>>>> What's the malformed definition? >>>> One that doesn't follow the grammar. >>>>> (I want to see normative criteria if >>>>> they exist). For example, can we consider the following sequence of >>>>> tokens >>>>> %+*!^~ >>>>> as a malformed template definition (according to your interpretation)? >>>> Yes. >> [...] >> >>> There shall be standard criteria for determining which option is >>> right. Can you show these criteria? >> Consider this quote from C++98 14.6.7 which I believe overrides the quote from >> the introduction: >> >> "Knowing which names are type names allows the syntax of every template >> definition to be checked. > It allows to distinguish template definitions from any other sequences > of tokens. >> If no >> valid specialization can be generated for a template definition, and that >> template is not instantiated, the template definition is illformed, >> no diagnostic required. > We may apply this rule only to a sequence of tokens that can be > recognized as a template definition according to syntactic rules. A > template definition can be semantically incorrect, but every template > definition is syntactically correct _by definition_ (there are no > criteria to distinguish template definitions from any other sequences > of tokens other than syntactic rules). >> This suggests that if the template is never instantiated, errors in it do not >> have to be diagnosed. > That's right only for semantic errors. >> BTW, the token collection scheme for templates counts the braces. > Look at the grammar of C++. Do you see something like > template-declaration: > export opt template < template-parameter-list > potential- > declaration > potential-declaration: > potential-function-declaration > potential-class-declaration > potential-static-data-member-definition > potential-function-declaration: > simple-declaration > potential-function-definition > template-declaration > potential-function-definition: > decl-specifier-seq opt declarator p-ctor-initializer opt potential- > function-body > decl-specifier-seq opt declarator potential-function-try-block > potential-function-body: > { potential-statement-seq opt } > potential-statement-seq: > potential-statement-seq opt { potential-statement-seq opt } > not-a-brace-seq > not-a-brace-seq: > not-a-brace-seq opt not-a-brace > not-a-brace: > token > (where not-a-brace is any token except { and }) > in the standard? I don't see. So if your interpretation would be > correct, how exactly the bounds of a template should be determined? >> Your example >> won't compile with DMC++. The template definition "parser" does just enough to >> correctly find the end of the definition. > If your interpretation would be correct, the end of this template > should be strictly defined, because it affects whether the diagnostic > is required. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 8 Aug 2010 06:48
CornedBee wrote: > On Aug 5, 8:28 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: >> CornedBee wrote: >> >>> A conforming compiler will compile this program to print "Template". VC >>> ++ compiled it to print "Plain". >> Digital Mars C++ compiles it and prints "Template", yet uses token caching. >> > > I get it, your implementation uses token caching and works. Stop being > so defensive ;) Read on... >>> If you have a better idea, I'd be interested in hearing about it. >> Just keep track of the source locations of each definition in the symbol table. >> You probably do that already for the symbolic debug info. > > Ah, so you filter the by location? Yeah, I can see how that is > possible, although it doesn't sound too efficient to me. Now you see why I sound a bit defensive. First it can't work, then when I show it does, it can't work very well :-) BTW, it works very well. Digital Mars C++ is very fast at compiling, far faster than any other C++ compiler. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |