Re: [boost] py_cpp and ILU?

From: Jan Dries (jdries_at_[hidden])
Date: 2000-10-16 10:56:37

Thomas Matelich wrote:
> 
> > Well, maybe, but there are surely many existing parsers out there already in
> > C/C++ using YACC and BISON. I think you'll find a BISON-based parser in the
> > Doxygen sources.
> 
> I know virtually nothing about parsing but I've seen a couple of things.
> ANTLR(www.antlr.org) is a Grammar Thingy, rewritten from PCCTS.  It seems like
> they're saying the have a C++ grammar at
> http://www.empathy.com/pccts/download.html, but I could be wrong, I didn't
> download it.
> 

If you look for a C++ parser/grammar on the net, there are two that you
will sooner or later come across, and that most other efforts you will
find are based on/derived from: the Roskind-grammar and this
PCCTS-thing. The problem with both is that they are way out of sync with
the C++ standard. I just downloaded from the pccts-link above, to see
where they stand today (last time I checked was early 1999). Following
you find an excerpt from their to-do list.
It's already an admirable effort to put together what they have. But for
me (and others I would assume) a C++ parser is of little use if it
doesn't understand as much of the language as my usual compiler does.

Jan

Excerpt of PCCTS C++ parser to-do:

Parser -- General
-----------------
1)  friend declarations
2)  Operator names
3)  Function overloading
4)  Complete expressions
5)  Types of expressions.  Note that in general this requires overload
resolution.
6)  sizeof expressions and types except for class/enum types. Size is
compiler-specific and should be designed to be easily overridden.
7)  sizeof expressions and types that are enums. Size is
compiler-specific and should be designed to be easily overridden.
8)  sizeof expressions and types that are class types- this means
getting class size right, which in turn means constructing an AST for
the declarations, processing all the base classes, and constructing the
virtual symbol table.  Size/alignment behavior is compiler-specific and
should be designed to be easily overridden.
9)  Namespaces
10)  Override panic() so that it doesn't exit.
11)  Make  optor rule support const pointers like
operator A * const * ();
(perhaps it should just have an abstract_declarator?)
12)  Support "mutable" keyword
13)  In CPPTypePointerToMember::FormatName(), and possibly elsewhere, we
need to get a qualified class name, in case the class pointed to is a
subclass of some other class.  This should follow the lead of how a
class formats its name.
14)  Support constant cast expressions in expr_cast by checking that the
type is a built-in or a const built-in.  For now, things are OK, but
some expressions may evaluate as int instead of float or vice-versa.
15)  Support unnamed bitfields and zero-length (forces alignment or
padding of next bitfield).

Parser - Platform-specific
--------------------------
1)  Handle calling conventions in declarator_opt_abstract (this is done
in XDEF)
2)  Implement the syntax for __try, __except, __finally, __leave in
MSVC++.
3)  Integrate changes to __declspec() placement from XDEF work.  This
involves changes to linkage_specification,
compiler_specific_calling_convention, compiler_specific_storage_class,
compiler_specific_glop, declaration_specifiers, declarator.  Note also
that this causes an additional StorageClass argument to be passed around
in many rules.

Parser -- Templates
-------------------
1)  Function templates
2)  Function overloading with template functions considered
3)  Class template partial specializations
4)  Deal with point of instantiation issues including restoring the
template declaration scope environment..
5)  Handle explicit instantiation request.
6)  In a templated class definition, the unspecialized name of the class
is equivalent to the specialized name, for example:
   template<class T> class A {
      A<T>* glarp();  // means A<T>*
      A* foo();       // also means A<T>*
   };