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

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

Hi Stefan,

On Wed, 12 Mar 2003, Stefan Reuther wrote:

> Hello,
>
> 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. You are
working on Fiasco project, right? Are your sources open?

> I found some C++ constructs which OpenC++ does not handle:
>
> - "if (declaration)" is not supported, neither is "while
>   (declaration)" nor "switch(declaration)". I have appended a
>   patch which adds that.
>
>   What is your general position about changing the parse tree
>   like this? Will that break people's programs or is that not a
>   problem?
>
> - "explicit" is not supported, but works, sort-of. "explicit" is
>   only allowed for constructors, and OpenC++ thinks that "explicit"
>   is the return type :-)
>
> - wide characters (L"klingon sentence here"). I've seen there is
>   a patch on SF which adds that.
>
> - "namespace A = B"
>
> - type-specifiers in non-canonical order are not accepted. For
>   example, "unsigned const long typedef int a" is legal C++,
>   but OpenC++ doesn't grok it. I'm unsure how that problem can
>   be solved minimally-invasive, and whether anyone cares about it.
>
> - function-try-blocks are not accepted.
>     a::a() try : mem_init() { } catch(...) { }
>
> In addition, some parse tree nodes lose information about which
> production was applied. For example, the types "unsigned int"
> and "::name" both turn into two-element lists [unsigned int] and
> [:: name], although the first one contains two type-specifiers
> while the second one contains one. I'm unsure whether that's a
> problem worth fixing, but it caused me some headaches when I
> wanted to analyze such trees.

I find the answer to this question important to the whole project, so I post
it in a separate e-mail.

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

>
> 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).
>
> OpenC++ usually parses this as the first form. Okay, I have no
> problem with OpenC++ mis-parsing things; I know it can't do
> better with that little knowledge it has. The problem here is
> that a parse problem affects its parent node, not just its
> child nodes (i.e. "(name)(1,2)" is either a function call or a
> cast of a comma expression. OpenC++ parses it as the latter but
> it is quite simple to fix that up.) Well, any helpful hints on
> that topic are appreciated.

I do not see any solution within parser itself. You have to know
the local environment to be able to do anything.

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.

> 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...
>
> - compound expressions ("({ if (x) .... })")
>
> - extended literals, gcc and C99 form
>   ("return (div_t) { 1, 0 };", "div_t x = { quot:3 };" resp.
>   "div_t x = { .quot = 3 }")
>
> - some keywords: restrict, asm, ...
>
> - typeof

I do not see any problems with letting those in, but perhaps under
a switch.

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

> Thank you for reading until here,

"I have made this letter longer than usual, because I lack time
to make it short." [Blaise Pascal]

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