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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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.

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.

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.

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

- maybe some __attribute__ should be handled? OTOH, it can
  simply be #defined out.

Thank you for reading until here,
  Stefan

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

opencxx-users