|Re: Define an attribute typed with a class without the default constructor [message #1795428 is a reply to message #1795371]
||Fri, 21 September 2018 17:44
| Ernesto Posse
Registered: March 2011
The first question is more of a C++ question than a Papyrus-RT question. Whenever you create a passive class (i.e. a non-capsule), by default it will not generate a default constructor, so, according to C++ semantics, it will have an implicitly declared default constructor. See . So if some capsule (say Capsule1) has an attribute (say 'a') typed by such class (say Class1), when the capsule is instantiated, it will automatically call Class1's implicitly declared default constructor:|
class Capsule_Capsule1 : public UMLRTCapsule
Capsule_Capsule1( const UMLRTCapsuleClass * cd, UMLRTSlot * st, const UMLRTCommsPort * * border, const UMLRTCommsPort * * internal, bool isStat );
Class1 a; // (1)
static const UMLRTObject_field fields;
When Capsule1 is created, space for attribute 'a' declared in line (1) is automatically allocated inside the space for the capsule, and Class1's default constructor (implicit or not) will be called. And this is recursive of course. That's just the standard C++ semantics of constructors. (C++ != Java).
If you need to initialize a's own attributes, then you can do it in Capsule1's initial transition's action.
Alternatively, you can apply the "PassiveClassProperties" stereotype to the class (Class1) and in the stereotype's properties, set "generateDefaultConstructor" to true (although that is the default). You can also control how to generate other things, like the copy constructor, the assignment operator, the equality operator, insertion and extraction operators, etc. With "generateDefaultConstructor" to true, you can then customize the body of the generated explicit default constructor.
Note however, that this works for passive classes only and not for capsules: you cannot override the capsule constructor, and this is by design, because the generated code must ensure that some things are initialized for capsules, calling the RTS's UMLRTCapsule's constructor, and setting certain internal attributes. If the user was allowed to customize this, we could not guarantee anything about the capsule's behaviour, or even its structure. Furthermore, we do not allow things such as assignment, and operations that would allow capsule serialization (copy constructor, insertion/extraction), etc. because the semantics of UML-RT doesn't define if this should be possible at all.
Powered by FUDForum
. Page generated in 0.08916 seconds