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

[Grzegorz J. <ja...@he...>]

On Thu, 13 Mar 2003, Stefan Reuther wrote:

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

There is brand new preprocessor based on Spirit parser, you may want to
have a look at:

    http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=comp.compilers&selm=03-03-046%40comp.compilers

however I am not sure if it handles trigraphs.

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

The problem is that occ client should be isolated from this detail.
Somebody using Walker should not care about it, it should be taken care of
by the framework.

I think there is a problem now, since there is no islation between syntax
tree that OpenC++ is working on and syntax three that is exposed to the
clients.

I have been working on this for some time and I think I have a couple of
idas on how to provide isolation here without runtime overhead, but I have
not run those ideas through too many persons yet. Perhaps this is a good
time and good place to do it. I will try to prepare a write-up on weekend
and post it here. I am not sure, if it will be immediately applicable and
what are exact backward compatibility issues on that, but maybe people
here will help figuring this out.

> Other than that, my (implicit) question was how many people
> would cry when I change the parse tree somehow :-)

Just wait for a week to see.

> At least, the
> addition of "typeid" broke one of our regression tests.

This is precisely why I would like the isolation.

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

Right. However this involves problems with all the code that instantiates
Walker --- it has to be fixed by hand, better yet switched to
Factory-based solution.

> Maybe this can be solved more generally, as a parameterized user
> keyword.

Why not.

> If I recall correctly, such a thing is on the wishlist?
> (haven't yet digged through all of Michael's archive)

Unfortunately I do not maintain wishlist, so I cannot verify.

Best regards
Grzegorz

##################################################################
# Grzegorz Jakacki                       Huada Electronic Design #
# Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
# tel. +86-10-64365577 x2074               Beijing 100015, China #
# Copyright (C) 2002 Grzegorz Jakacki, HED. All Rights Reserved. #
##################################################################