Mail Archives: djgpp/1999/07/13/15:16:07
Siemel Naran wrote:
> > Actually, what I'm going to do is accept any standard cast as an operator:
> >operator int (*)() ();
> >
> >This isn't syntactically correct, but it should never arrise and it means I
> >don't have to make another type parser.
> Don't accept incorrect code. This might screw some people up who will use
> the construct, and when they move to another parse, they're in trouble.
> Better to say that you won't accept this construct because you're not sure
> if its legal, and people using your parser will be forced to use another
> construct that you know is legal and portable. And besides, you're
> discouraging them from using operator functions, and that's very good.
The parser that I'm working on does compile the code, it's is used as an aid in
a development environment (currently only SetEdit, but will support Emacs soon, and
RHIDE when new versions come [I haven't checked v4.1.7, maybe it has the sLisp that
I need]). It displays information about your code and can do variable-name
completion as well as listing the contents of a struct/union/simple class. It is
only designed to work with compilable code and thus is allowed to accept a superset
of C/C++.
- Raw text -