First C++ parser commit and type bug

2005-03-08

With the upcoming 0.18 release of ArgoUML, I looked into the issues reported and fixed by Daniele Tamino, in order to verify the fixes. It is all working fine and therefore many of the issues are now verified.

I think that I will check tomorrow a way to commit my current work for reveng in a branch... DONE Sent also an e-mail of thanks to Yolanda.

2005-03-04

The quadratic.i test file can't be taken as made available from the original ANTLR C++ grammar (the one for C++ output). It contains pre-processor lines, which in the TestCppGrammar test case aren't removed before handing it to the lexer. It isn't a problem. I removed these lines with a simple python script and I'm now debugging the grammar with this modified file. It contains some problems, which I think I will handle by debugging the grammar in additional test cases with just the needed code snippets to make it fail.

2005-02-25

The parser must really be built for debug to enable debugging! This parser isn't just my class, it is the antlr.Parser class! So, I'm going to use just the ANTLR generation options for tracing: -traceParser and -traceLexer. It is working, but, I'm going to start with the SimpleClass.cpp test first because the quadratic.i example from the ANTLR C++ grammar is way too complicated to start with.

The grammar works! :-)) It parsed SimpleClass.cpp as soon as I fixed it (removed the boolean)! I must test with quadratic.i, since previously the Ant target was failing because I wasn't copying the files to the build dir 8-!

New Bug: C++ generator is generating code with java types.

I've noticed a new bug in the C++ generator. ArgoUML enables selection of some built-in types according to the java language. One of these is the boolean, which is generated as boolean instead of bool. I bet this is happening for other types as well...

What should be happening is that ArgoUML enables selection of the standard UML types:

• Boolean – it does enable the java.lang.Boolean, but, this still is java specific.
• Integer – same as for Boolean, i.e., java.lang.Integer
• ... all the types are java!!! No UML types?!

I must create an issue for this... Actually two, one for the global ArgoUML to enable UML types by default and another for the C++ module to give warnings when java specific types are used and to translate these types to C++ types. It should also enable the use of specific C++ types, adding them, just as java does. This might be done with a XMI file made available to users for importing or by some option, which make available the use of either UML types, java types, C++ types or some other...

Another possible addition is to have a critic that warns users about the possibility of using java types in non-java specific models. Maybe having a model nature as a tag would be a nice thing that would disable such critic to be turned on. This model nature could later be extended so that only generic rules and specific language rules to be turned on. This might be applied also to packages etc.