Compiling C++ Templates as opposed to Preprocessing them.
in [C++]
|
Prev: basic concatenation question
Next: type casting issue
From: Seima Rao on 30 Jul 2010 23:34 Hi, Can readers of this forum advise on whether it would be fruitful to consider compiling C++ templates to IR instead of preprocessing them? Consider the following snippet: template<class T> void foo(const T &t) { T::i; // #1 } Since the compiler cannot tell if `i' is a static member of `T', an extra operator needs to be introduced in the IR so that the `::' operator can be mapped to it. This operator would have no use in a non-generic scope, therefore, that operator is there merely to represent templates in the IR. I am sure professional compiler writers would have (many) non-trivial issues to tell. What I want to know is the following: 1) Has C++ been defined to accomodate compilation of templates? 2) Is name resolution unambiguously doable in template scopes so that IRs that represent templates dont have to worry about it at all? Sincerely, Seima Rao. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: CornedBee on 31 Jul 2010 23:32 On Jul 31, 7:34 am, Seima Rao <seima...(a)gmail.com> wrote: > Hi, > > Can readers of this forum advise on whether it would be > fruitful to consider compiling C++ templates to > IR instead of preprocessing them? This is a question without an answer, really, because it makes assumptions about the way compilers work that, as far as I can understand your question, are simply wrong. So let me start out by describing how templates are processed by the compiler. GCC and Clang (I cannot really talk about the others) first preprocess the source (as any other) and lex and parse it. When they encounter a template, they will build an AST for it, just as they would do for any other source code. The thing is that this AST contains some nodes that carry some things that only appear in templates. For example, the type of an expression might be dependent. I am pretty sure, from observing its behaviour, that MSVC caches the token stream instead of building an AST, but that's not a good approach: there are various bugs that can be traced to this implementation choice. Anyway, when a template is instantiated, the AST for it is duplicated, but with the template parameters filled in. The resulting template instantiation is just like a normal function or class. In particular, code generation doesn't really treat them differently. Now I believe you're asking whether the compiler could, instead of instantiating a template, generate code where a type can be substituted in at runtime? The answer is no. There is too much semantic validation that has to be done when instantiating a template, which includes name lookup, overload resolution, and more. This cannot be deferred until runtime. First of all, template instantiation could fail, and you really don't want such failures to result in runtime errors. You want them at compile time. Second, preserving all the information necessary for runtime template instantiation means you might as well carry the whole program source code with you and recompile it on demand. In other words, embed a complete C++ interpreter in your program. So while in theory, this might be doable, it's simply not practical. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 31 Jul 2010 23:48 On Jul 31, 3:34 pm, Seima Rao <seima...(a)gmail.com> wrote: > Consider the following snippet: > > template<class T> > void > foo(const T &t) > { > T::i; // #1 > } > > Since the compiler cannot tell if `i' is a static member of > `T', > an extra operator needs to be introduced in the IR so that > the `::' operator can be mapped to it. This operator would > have no use in a non-generic scope, therefore, that operator > is there merely to represent templates in the IR. > > I am sure professional compiler writers would have > (many) non-trivial issues to tell. The AST of a C++ frontend is the IR you're looking for. Whether you can make it simpler and more low-level or not, I don't know. > > What I want to know is the following: > > 1) Has C++ been defined to accomodate compilation of > templates? Typically, templates are directly compiled to low-level code by the C+ + frontend. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 31 Jul 2010 23:48 Seima Rao wrote: > Can readers of this forum advise on whether it would be > fruitful to consider compiling C++ templates to > IR instead of preprocessing them? Frankly, precompiling them is a waste of time and effort, in my not-so-humble opinion. The Digital Mars C++ compiler stores template definitions as a sequence of tokens. At instantiation time, it does the syntactic and semantic analysis in one go. The Standard allows precompiling them into some syntactical intermediate form, and there are some crutches in the syntax to allow this to work. It's my understanding that this is how all the other C++ compilers handle it. The advantage of this approach is that some syntactical errors can be diagnosed before instantiating the template. The disadvantage is it's significantly more complex to implement. The Standard allows for either method. The D programming language has complete separation of syntax from semantics, and so the template definitions are converted to and stored as syntax trees. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seima Rao on 1 Aug 2010 08:53
> > the source (as any other) and lex and parse it. When they encounter a > template, they will build an AST for it, just as they would do for any > other source code. The thing is that this AST contains some nodes that > carry some things that only appear in templates. The IR(AST as is cited by you) has extra node types just for templates, if I understand you correctly? > > Now I believe you're asking whether the compiler could, instead of > instantiating a template, generate code where a type can be > substituted in at runtime? The answer is no. You assumed incorrectly. What I am interested in is the two scenarios that a compiler has to contend with: 1) template declaration 2) template instantiation Your reply seems to suggest that compilers piggyback on preprocessing technology(aka macro substitution) to get template instantations to work admittedly in a transparent fashion to the rest of the toolchain. Any one with suggestions for compiling templates only during declaration and skipping name lookup and other sundries during instantiation? [C++ makes it impossible, but still...] Sincerely, Seima Rao. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |