[Opencxx-users] Re: [opencxx] some OpenC++ experience

[Stefan R. <sr...@ma...>]

Hello,

On Thu, Mar 13, 2003 at 01:48:52PM +0800, Grzegorz Jakacki wrote:
> On Wed, 12 Mar 2003, Stefan Reuther wrote:
> > I have been writing a program which takes an OpenC++ parse tree,
> > and translates it into a more regular output, i.e., user-defined
> > operators are turned into function calls, overload resolution
> > being done, etc... I have used OpenC++ only as a parser library
> > (I'm working with Michael Hohmuth).
> 
> That's a pity that you do not implement it in OpenC++ itself.

The decision was to not change OpenC++ for the moment, and do
everything from the outside. This is advantageous from a
modularity point-of-view, but some of "my" code is a bit more
complicated than it could be. For example, as far as I can tell,
OpenC++'s symbol management doesn't do everything we need (like
overloading functions, "int stat()" vs "struct stat", ...; but
feel free to prove me wrong :-), so the solutions would be
either to change OpenC++, or to implement our own symbol table.
We decided to pick the latter choice, and leave the former as an
option for the future.

> You are working on Fiasco project, right? Are your sources open?

VFiasco, right. Sources are not yet open, because we did not yet
package them up nicely, and because the project is far from
complete. Other than that, there's no problem.

> > OpenC++ also does not recognize di- and trigraphs, nor does it
> > support replacement keywords (i.e. "and_eq" instead of "&="). I
> > think these are better in a preprocessor.
> 
> I do not quite understand where is the problem here. OpenC++ works on
> preproc output, so it has no chance to see trigraps&co, right?

gcc's preprocessor doesn't do digraphs ("<%" instead of "{"). It
also doesn't do replacement keywords, but at least these can be
worked around using some #defines, like C99 does it. I think
there are some subtle gotchas in these, but I would just declare
that these things are out of OpenC++'s scope (I don't care
whether "<%" stringifies as "<%" or "{"). And, honestly, I've
never seen anyone use them.

> > Another problem which I found quite hard to solve: take an
> > expression like this: "(name) + x * y". Depending upon whether
> > the "name" is a type or a variable, this either means
> >    ((name) +x) * y
> > (cast +x, then multiply) or
> >    (name) + (x * y)
> > (multply, then add).
[...]
> The honest solution would be to have node type that makes it
> obvious, that parser does not know what it is. Further analysis
> would change the node to one or another form, based on the
> relevant identifiers bindings. I am not sure if this scheme
> is currently implementable without seriously compromising backward
> compatibility.

Okay, I had some similar things in mind. For compatibility, the
"Walker" could have a routine "TranslateAmbiguousCast" or
somesuch, whose default implementation calls
"TranslateCastExpr", "TranslatePrefixExpr" and
"TranslateInfixExpr".

Other than that, my (implicit) question was how many people
would cry when I change the parse tree somehow :-) At least, the
addition of "typeid" broke one of our regression tests. I think,
static_cast & co should have their own PtreeCxxStyleCast node,
which would probably change someone else's tests. Addition of
new productions wouldn't break immediately, but someone who
implements their own Walker might accidentially miss some nodes.
That problem could at least be solved by making an abstract
Walker base class where all the TranslateFooBar functions are
pure virtual.

> > The program which we finally want to run through the OpenC++
> > parser is an operating system kernel. Kernel hackers tend to use
> > gcc extensions a lot. What is your opinion on adding these to
> > OpenC++ (i.e., if I made a patch for them, would it make it
> > into OpenC++?). I'm talking about...
[...]
> 
> I do not see any problems with letting those in, but perhaps under
> a switch.

Okay.

> > - maybe some __attribute__ should be handled? OTOH, it can
> >   simply be #defined out.
> 
> This one I would leave out at the moment, especially if you do not have
> clear requirement for it. Again, if you need it, go ahead and put
> it under the switch.

Maybe this can be solved more generally, as a parameterized user
keyword. If I recall correctly, such a thing is on the wishlist?
(haven't yet digged through all of Michael's archive)


  Stefan