Related articles |
---|
Any in-depth documents of how to implement template semantics in a par jiangbin@hotmail.com (Jiang Bin) (2004-09-13) |
Re: Any in-depth documents of how to implement template semantics in a sgganesh@gmail.com (2004-10-02) |
From: | sgganesh@gmail.com (Ganesh) |
Newsgroups: | comp.compilers |
Date: | 2 Oct 2004 01:23:20 -0400 |
Organization: | http://groups.google.com |
References: | 04-09-097 |
Keywords: | C++ |
Posted-Date: | 02 Oct 2004 01:23:20 EDT |
Getting the semantics of C++ templates in compiler can be very
difficult. Unfortunately, not many documents are available that
describe the problems in detail (for example, difficulties in parsing
templates, and compexities introduced by typename and template
kewords).
Template implementation models are described in the following paper:
http://osl.iu.edu/~tveldhui/papers/2000/tmpw00/
The Daveed Vandevoorde's book "C++ Templates" (Addison-Wesley)
describes many of the implementation details which might be of help.
The problem you are describing here is handled by C++ compilers in
different ways. For example, a compiler might use a token "playback"
technique for reparsing the tokens at later stage, do "actions" and
"substitutions" as the template needs to be "fully instantiated" etc.
> I find there is
> still a problem, "pos_type" is used in the body of "basic_ostream", and it
> is defined in the base "basic_ios"....
When the corresponding template gets instantiated, the "actions" and
"subtitutions" would be done, so pos_type will be a "non-dependent"
type by the time basic_ios gets instantiated.
One point you are missing is that you are trying to do the
instantiation of template in one-stretch. This approach doesn't work
out well in practice: you would need much sophistication to parse,
resolve and instantiate templates (these three typically done by
separate components).
-Ganesh
"Jiang Bin" <jiangbin@hotmail.com> wrote
> HiŁ¬
> I am developing a C++ parser based on John's PCCTS-based C++ Parser, and
> have encountered some difficulty in implementing the template semantics.
> Currently the parser can do some basically template parsing, but the method
> used will fail when more complicated template semantics are concerned, for
> example:
> =========================================================================
> template<class _E>
> struct char_traits {
> typedef int pos_type;
> };
>
> template<class _E, class _Tr = char_traits<_E> >
> class basic_ostream;
>
> template<class _E, class _Tr = char_traits<_E> >
> class basic_ios {
> public:
> typedef basic_ostream<_E, _Tr> _Myos;
> ^^^^^^^^^^^^^^^^^^^^^^^
> typedef _Tr::pos_type pos_type;
> };
>
> template<class _E, class _Tr = char_traits<_E> >
> class basic_ostream : virtual public basic_ios<_E, _Tr> {
> ^^^^^^^^^^^^^^^^^^^
> public:
> pos_type tellp() {}
> };
>
> typedef basic_ios<char, char_traits<char> > xxx;
>
> =========================================================================
> this code is grab from VC6.0 STL headers.
> the main template parsing method used in the parser is save the token list
> of a template defintion, and when the template is used, a sub parser will
> invoked to reparse of the saved token list. That should be OK for many
> cases, but in the example above, when the last basic_ios<char,
> char_traits<char> > is instantiated, template "basic_ios" will be reparsed,
> consequently template "basic_ostream" will be repared, because basic_ios<_E,
> _Tr> is a base of "basic_ostream", then again
> "basic_ios" will be reparsed, thus leading to a infinite recursive
> reparsing.
> Yet I can do something to stop this, such as stop reparsing a template when
> it is already instantiated or when it is being instantiated. I find there is
> still a problem, "pos_type" is used in the body of "basic_ostream", and it
> is defined in the base "basic_ios"....
> I only get some basic knowledge about template parsing from books, so I ask
> is there any in-depth references about implementing template senmantics in a
> C++ compiler or front end?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.