Le 23/08/2011 00:27, Topcased user list where issues are discussed a
écrit :
I also miss the C primitive types on the project. Formerly, one could
add them to the model, now when you want to import primitive types, it
only shows UML primitive types, ECore and Java types. Where did the C
primitive types go?
Generation of C Primitive types from the Topcased menu "generate" or
"import" primitive type is not a feature of the component.
In a successfully reverse of the code, the C Primitive types are
automatically generated from the code.
Is the C2UML the same as the UML2EC?
Nope, this is another component.
I don't know the discrepancies with the C2UML and UML2C one.
* how mature is the code generation, what does it all generate?
For our usage the generated code is expected to be identical (modulo
comments generation and declaration order) to the reversed code.
(Ok this should be accomplished only if your code is successfully
reversed first !)
The C compiler shall compile equally the reversed and the generated
code.
As I wrote above, it did not.
My original post was about that I tried to reverse engineer a simple
Hello World, and the generated main function was not correctly RE'ed.
The final generation of that UML model therefore generated the main
function wrong again.
The problem is related to the type of argv.
int main(int argc, char* argv[]) --> main(argc:int, argv char*[]) :
int --> int main(int argc, char*[] argv)
-----------
Well... i'm not a C specialist, i'll will see that with my colleagues
and try to understand that problem.
I've tried to RE and GEN on that and it seems to be a bug.
Could you please fill in a bug for the "C to UML" category ? here:
http://gforge.enseeiht.fr/tracker/?func=add&group_id=52&atid=109
Well, now I try again to RE a simple C99 program:
---------------------------------------------------------------
[...]
7) In the Outline, I select the main-class and select "Generate C
code" and ... nothing happens.
This is also a bug if you are using Topcased 5.0.0. My fault !
Due to some... how could i say ... humm... tricky behaviour with the
acceleo builder at build time on the Topcased forge, some part of the
UML2C component where not packaged into the plugin.
Someone warn me about that few months ago but.. hey... other projects...
holidays...
So i've reimported the missing part in the component source repository
and maybe that night the nightly build could deliver us a fully packaged
plugin.
You could try to install the new version from the nigthly build Topcased
5.0.0 update site :
http://topcased-mm.gforge.enseeiht.fr/indigo/nightlybuilds/
8) But, when I select the test_c.uml Model in the Project Explorer, I
get in it's Context Menu "Code generator"->"Generate UML2EC".
But, oh well, that generates stuff under Model as in the attached zip
file.
Just to show a short example of the created code:
Double Main_test(Main* const self, Double a, Double b)
{
Double result;
{
return a * b;
}
return result;
}
That looks sick. sorry.
I'm sure, I'm doing something fundamentally wrong. But in 7) nothing
gets generated, and in 8) it looks wierd, and I guess the UML2EC is a
different generation plugin the C2UML maintained by you.
Maybe the guys from the UML2EC componentcould provide us more
information on that generation ?
I'm sorry but I can't answer for that, you're right : this is not
handled by the UML2C component.
I assume, that the whole RE-process is based on the AST index of CDT?
There are some major problems with CDT's indexer:
a) It has major problems with "multi-stage" inclusion of headers
e.g.
--------------------------------
XYZ.h
#ifdef XYZ_PRE_INC_H
/* .. some defines etc. STAGE_1 .. */
#endif
#ifdef XYZ_POST_INC_H
/* .. some defines/declarations etc. STAGE_2 .. */
#endif
--------------------------------
--------------------------------
XYZ.c
#define XYZ_PRE_INC_H
#include "xyz.h"
/* .. some stuff after pre_inc but before post_inc .. */
#define XYZ_POST_INC_H
#include "xyz.h"
/* .. some more stuff in the C file, now after all has been
defined/declared */
--------------------------------
This happens e.g. with OSEK.
Also, the indexer usually does not index/parse an header twice afaik.
That also might cause problems in the parsing of different translation
units (i guess).
b) The indexer has major problems with asm functions.
e.g.
__asm static void AnAsmFunc(void)
{
}
The problems lie in the __asm (or asm or whatever non-C-standard)
keyword, which embedded compilers provide. The second problem lies in
the asm instructions itself.
Thanks, i will look on that : the RE is based on AST, and we have other
problems with AST. Like specific declaration which are not brink back by
the AST and more problematic stuff that has disabled the possibility to
get a full synchronisation between CDT editors and Topcased UML.
I hope that this answer will help you to carry out a successful
reverse. If it's not the case, maybe direct mail exchange could be
done to provide me more data, let me know.
The problem is, I can't provide you much sources, since that is
commercial code.
Ok so, we will solve it without your code !
--
Fabien Toral
CS Systèmes d'Information
+33 5 67 69 68 10
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/cgi-bin/mailman/listinfo/topcased-users
