From: Stefan R. <sr...@ma...> - 2003-03-12 14:54:26
|
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 |