| Re: [etrice-dev] Fwd: Status of cpp code generator (by Peter Karlitschek) |
|
Hi Peter, good to hear you are already so far with the C++ generator! I'll try to answer your questions: - building attribute initializer lists: in cpp I don't want to create instances of data classes on the heap, but instead I would like to initialize those attributes in the constructor. -> would be good to get some generic support herehave a look at the Java generator. There we have attribute initialization in the constructor /org.eclipse.etrice.generator.java/src/org/eclipse/etrice/generator/java/gen/ActorClassGen.xtend, line 117ff The attributeInitialization Xtend-method is Java specific right now. You might want to copy and modify it and see later whether we can sort of unify this for C++ and Java - building the state machine code: in cpp I have to split up the generated code into .h and .cpp file, for example I need the member function declarations in the header and the implementation in the code. This is currently not supported by the generic generator -> I think we need support here similar to operation-generation functionswe currently already have this split for C. We achieved this for operations using two distinct methods in the ProcedureHelpers: operationsDeclaration and operationsImplementation The generic state machine generator produces a number of implementation functions which have to be declared in the private part of the class definition though. To make these available you could add a method to the /org.eclipse.etrice.generator/src/org/eclipse/etrice/generator/generic/GenericStateMachineGenerator.xtend which generates the method declarations, e.g. def genStateMachineMethodDeclarations(ExpandedActorClass xpac) - Message pooling: efficient allocation scheme for Messages is still neededsure. But for the beginning just keep it simple (as in C where we currently just use a fixed message size) - Threading: Question is which library to base it onto. My favorite would be to use boost and later switch to C++11 threadswe should have a generic interface which shields us from the actual implementation. This would be located (similar to C) in a common/platform part. We need threads, a synchronization object (semaphore) and a timer giving a (reliable and accurate) system time. Then we should have a generic platform implementation (again similar to C) which should use the posix interface (and thus works with MinGW or on *nix systems) - Unittests: For the runtime and for the generator itself. On which test framework should the cpp-runtime tests be based.please use the etUnit framework we created as part of the C runtime library. It is very simple (see the runtime.c.tests for usage examples) and general enough for our purposes. It produces a simple ASCII text file which can be converted using our etunit.converter into the xunit xml format. For high level tests of the code generators we recently introduced target language independent models located in generator.common.tests. They are used by both, generator.java.tests and generator.c.tests. In the language dependent part there are Ant scripts which copy the appropriate models, compile and link all sources, execute the tests and convert and copy the results. The two tests we currently have should also work for C++. You can use the generator.c.tests as a template to create generator.cpp.tests and adjust the Ant script. You could push your code to Gerrit (for an explanation how to use it see http://wiki.eclipse.org/ETrice/Development/Repository#Gerrit). Then I could have a look at it. I'm really excited to see it! -Henrik Am 28.09.2012 13:09, schrieb Henrik
Rentz-Reichert:
this message was meant for etrice-dev@xxxxxxxxxxx - so I just forward it... |
