Re: Compiling C++ Templates as opposed to Preprocessing them.

On Jul 27, 3:06 am, Seima Rao <seima...@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?


I'm unsure what definitions of compiling and preprocessing you're
using here.


This is a logic paradox if the C++ standard definitions are used;
preprocessing and translating to IR are distinct stages (stage 4 is
preprocessing, the next to last stage would include translation to IR
as a detail for either compilation or interpretation. The latest
draft C++0X is publicly available at openstd.org , see 2.2 for
details.) That is, when compiling C++, C++ templates are *required*
to be compiled; preprocessing has already happened before templates
can be syntactically recognized.


So, let's assume non-standard definitions of compiling and
preprocessing that let the question make sense, and determine what
those definitions are later.


> 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.


At the source code level, said operator already exists: the .
operator, and its close relative ->, do just fine. A foolproof way to
write this (assuming T::i is static, const, or mutable) would be


template<class T>
void
foo(const T &t)
{
      t.i; // #1
}


For template member functions, triggering dependent name lookup often
requires using this-> .


I'm not particularly familiar with how the major compilers handle
representing the . and -> operators. As MSVC++ (non-compliantly for
all C++ standards whatsoever) doesn't even syntax-check templates
until it tries to instantiate them, it's particularly hard to see why
MSVC++ would need a separate representation for . and -> operators in
template code, and non-template code.


> ...
>
> What I want to know is the following:
>
> 1) Has C++ been defined to accomodate compilation of templates?


As mentioned above, give a specific non-standard definition of
preprocessing and compilation, that actually permits preprocessing C++
templates.


> 2) Is name resolution unambiguously doable in template scopes
> so that IRs that represent templates dont have to worry about
> it at all?


Assuming some sort of two-phase name lookup (this excludes the major
compiler MSVC++), the intermediate IR for a template that references
global variables will have to at least handle the difference in name
lookup rules between namespaces and static members of structs/
classes. I don't have specific links on hand, but you might try
working through online back issues of the Dr. Dobbs journal as that's
where I've read the most detailed explanation of the practical issues.


D reportedly has specific restrictions that make this possible (in
most use cases), by rejecting or breaking valid C++ source code.

Return to the comp.compilers page.
Search the comp.compilers archives again.