C code generation for [inout] method parameter

[OwenInCanada]

Hi all,

I'm not sure if this is a bug, because I am experimenting with C code generation for the first time in EA.  (I use build 832.)

Parameter 'a' of a method 'polish' in class 'Class1' is defined as Type 'float' with Kind 'inout'. The problem is that the generated code for the function signature is 'float a'; I was expecting 'float* a'.

In more detail. When I change the parameter Kind from 'in' to 'inout', I see in the UML diagram that part of the method signature changes from 'float' to 'float*'. But when I generate that class to C, the result is always 'float', never 'float*' in both .h and .c files.

This UML signature
+ polish (this: Class1*, [inout] a: float, b: boolean): void

results in this generated .h code
void Class1_polish(Class1* this, float a, boolean b  = false);

If I manually create c and h files with float* in the signature, and then synchronize code with model, the resulting parameter is describe as a parameter of Kind 'in' with Type 'float*'.

In C preferences the Reference Parameter Style is 'Pointer (*)'.

Very odd. Am I missing something?

Regards,

Owen

[OwenInCanada]

I registered this with Sparx as a bug.

[«Midnight»]

Just to be sure, what settings do you have on the Tools | Options | Objects dialog, in the Feature reference indicator section?

[OwenInCanada]

Per your suggestion

Tools | Options | Objects  in the Feature reference indicator section shows

Highlight references is selected.
Reference char(s) is *
Suffix is selected.

regards,

Owen

[«Midnight»]

What about importing a correct hand-created class into an empty model? How does EA render it? [Remember to check tagged values.] What happens if you then generate the class to a new directory? Does it round trip correctly, or produce the above-mentioned flaw?

[OwenInCanada]

Hi David,

Thanks for your input on this.

The project that I built this in was a new project with just a UML class diagram requested from the initial dialog. When you do that, the class diagram is populated with a few example classes. My first experiments were on one of those example classes. Then I repeated my experiment on a new class created in the existing class diagram of that project. Same result.  Do you think my approach was sufficiently 'tabula rasa' to make the case?

Regards,

Owen

[«Midnight»]

I'm not quite sure what you're saying Owen. [You are not being unclear. It is just that I was not in the room when you did the experiment, and I think I'm missing some context.]

What I meant was to create a C program using your favorite development tool, entirely without EA. Make sure to use the construct(s) you are interested in. Then import the code into EA, to a pristine package; I suggest using an empty project.

Then, before doing anything else, examine the resulting elements in EA. Can you see the anything in EA that shows how it handles your construct(s)?

David

[OwenInCanada]

Sparx Support has responded as follows

Hello Owen,

Code engineering of C/C++ does not currently use the parameter kind during generation, or set it during reverse engineering.

We also do not recommend modifying the code templates to generate inout or out parameters as pointer or references unless you are only generating the full file each time.  When templates are modified to change the type this causes issues with forward synchronization and reverse engineering.

The only modelling choice to support pointers and references on parameters types for C/C++ is to include the reference type in the parameter type as is done by EA reverse engineering.

We have recorded the following feature request to use the parameter kind to generate parameters of reference type.

Issue ID: 07050883
Description: C/C++ code engineering doesn't use parameter kind (inout,
out) for reference parameters

Best Regards,

Practically that means that for correct code generation, I must specify my [inout] parameter as type float*. A curious side-effect is that the signature appears in the UML diagram as "+myMethod( float** )".

If I choose to use [in] with float*, the UML diagram will look correct, and the code will generate correctly. However, I will have used [in] where the fact of the matter is [inout]; does anyone know if that difference has any broader implications in the project?

Regards,

Owen

[OwenInCanada]

(I have asked Sparx that last question and will report back here.)