Eclipse Community Forums: Papyrus » C++ Code Generation and variable multiplicity

Help

Home

Home » Modeling » Papyrus » C++ Code Generation and variable multiplicity

Show: Today's Messages :: Show Polls :: Message Navigator

C++ Code Generation and variable multiplicity [message #1803898]

Wed, 13 March 2019 11:02

Yoann Farré

Messages: 235
Registered: November 2017

Senior Member

Hello everyone,

I'm trying to use variables with a multiplicity which is undefined (more than 1) and generate C++ code.
If the multiplicity field is set to 0..* , the code generator set an array. It's fine if the multiplicity is known and defined (for instance 3), but if 0..* is set, the code cannot compile.

As in C++, tables have fixed size, I propose that in the case where the multiplicity is set to *, the property would be generated as std::vector.

For example, if I defined a property like this in the model :

MyType prop[0..*]

The code result could be:

std::vector<MyType> prop;

Currently, the generated code cannot be compiled :

MyType prop[];

I know that I can create an external type which uses std::vector to type the property but I think this is a lack for the multiplicity management of a variable. Could you give your opinion and maybe other ideas ?

Regards.

Yoann.

Report message to a moderator

Re: C++ Code Generation and variable multiplicity [message #1803902 is a reply to message #1803898]

Wed, 13 March 2019 11:37

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

It could be done as you say, but ...

Arrays can be allocated on the stack so they have a simple lifetime. They cannot grow.

Vectors have reallocatable memory on the heap, so you need to have a runtime and code generation policy that supports a heap, fragmentation and memory allocation exceptions. Possible but hard. The solution is commonly called Java.

Regards

Ed Willink

Report message to a moderator

Re: C++ Code Generation and variable multiplicity [message #1803964 is a reply to message #1803902]

Thu, 14 March 2019 13:25

Yoann Farré

Messages: 235
Registered: November 2017

Senior Member

Hi,

Thank you for your feedback. Unfortunately Java code generation is not an adequate solution for my use case.

I suppose "std::list" (or similar classes) will give the same answer. Is there some plans to take care of * multiplicity in the C++ code generator? Maybe with a stereotype to specify the class std::list or std::vector?

Thanks in advance.

Regards.

Yoann.

Report message to a moderator

Re: C++ Code Generation and variable multiplicity [message #1804011 is a reply to message #1803964]

Fri, 15 March 2019 16:38

Ansgar Radermacher

Messages: 461
Registered: March 2011
Location: Paris Saclay, France

Senior Member

Hi Yoann,

I agree that some options for dealing with unspecified multiplicities are needed. The currently generated code works for method declarations (void f(MyType par[]) compiles) but not for attribute declarations. A low level option would be to declare a pointer, in other situations, std::list or std::vector would be more appropriate. As there is more than one way to do it, the generator needs to be configurable, but the configuration option must be stored within the model (since body code depends on it). I would prefer a stereotype on a package that defines a mapping of multiplicity elements instead of a stereotype on each parameter or property declaration, since this would favour an inconsistent use within a project - do you think that there is a need to use different mappings at different places?

Ansgar

Report message to a moderator

Re: C++ Code Generation and variable multiplicity [message #1804092 is a reply to message #1804011]

Mon, 18 March 2019 08:32

Yoann Farré

Messages: 235
Registered: November 2017

Senior Member

Hi Ansgar,

Thanks for your reply. I agree that the configuration option should be stored in the model. I agree that it would be more appropriate to have a stereotype on a package than stereotypes on each property/parameter.

I think that a default mapping through a stereotype on an owner package (or the model package) would be sufficient (for my use case at least).

Yoann.

Report message to a moderator