The C++ code generator is a plug-out directly written in C++ (the C++ code generator does not generate itself !).
The generated sources follows the definition made in BOUML at the artifact / class / operation / relation / attribute / extra member levels.
When the code generation is applied on a artifact associated to several classes, the code generation is made for all these classes. Nevertheless the C++ code generator produce first the code in memory and update the appropriate files only when it is necessary, to not change the last write date of the files for nothing. Depending on the toggle verbose code generation of the global menu Languages the code generator is verbose or not.
The C++ code generator plug-out may be called on :
a class : in this case the code generation is in fact applied on the class's artifact, then on all the classes associated to this artifact
a artifact : in this case the code generation is in fact applied on all the classes associated to the artifact
a class view : the code generation will be applied on all the sub classes, then on all the artifacts associated to these classes
a deployment view : the code generation is applied on all the sub artifacts
a package (may be the project itself) : the code generation will be applied on all the sub class views and deployment views, then on all their sub classes and artifacts.
When the C++ code generator is ask through the Tools menu, it is applied on the project, then on all the artifacts.
The name of the generated files depend on the artifact name, the extension depend on the language and is fixed for each by the generations settings (see below), the directory where the files are generated may be set in each package containing directly or indirectly the artifact (see generation directory).
The C++ definition of a artifact is set through the C++ header and C++ source tabs of the artifact dialog.
The code generation depend on the stereotype of the artifact :
text : the C++ definition of the artifact is produced without changes, the name of the generated file is the name of the artifact, including the extension.
source : see below.
else nothing is generated for the artifact.
The generated file name is the artifact's name with the extension specified in the first C++ tab of the generations settings :
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${NAME} produce the artifact name capitalized, ${Name} produce the artifact name with the first letter capitalized, ${nAME} produce the artifact name forced in lowercase, at least ${name} produce the artifact name without modification.
${comment} is replaced by the artifact description adding //
${description} is replaced by the artifact description without adding //
${includes} is replaced by the automatically generated #include and using forms, it is also a good place to add your #include and using forms, when the ones produced by the code generator are not sufficient. To limit the included files number and to not produce circular #include, the C++ code generator does not produce an #include to define a type only used by pointer (*) or reference (&) or place between <> in a template form. The C++ code generator does not look at in the operations body, only the operation's profiles, relations and attributes, classes inheritances etc ... are used to compute the needed #include list. You can also use dependencies between classes to add #include, and to choose to place them in the header of the source file editing the dependency tab C++. ${includes} and ${all_includes} are exclusive.
Note : the generation settings allows to choose between four ways to produce #include :
without path : ask for the C++ code generator to generate the #include without relative or absolute path
with absolute path : ask for the C++ code generator to generate the absolute path of the automatically included files.
with relative path : ask for the C++ code generator to generate the relative path of the automatically included files, relative to the file containing the #include
with root relative path : ask for the C++ code generator to generate the relative path of the automatically included files, relative to the directory specified by the generation settings
${all_includes} is replaced by all the automatically generated #include and using forms, it is also a good place to add your #include and using forms, when the ones produced by the code generator are not sufficient. In this case the code generator doesn't produce declarations in the header file nor #include in the source file, except the ones added by you. ${all_includes} and ${includes} are exclusive.
${declarations} is replaced by the class declarations when the #include form is not produced, it is also a good place to add your declarations, when the ones produced by the code generator are not sufficient. Produce nothing if ${all_includes} is used.
${namespace} is replaced by the name of the current namespace (an empty string out of a namespace), dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined. ${NAMESPACE} does the same but focing characters in upper case.
${namespace_start} is replaced by the namespace xx { forms, dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined.
${definition} is replaced by the definition of the classes and extra artifact definitions associated to the artifact.
${namespace_end} is replaced by the } forms, dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the artifact, if not found for the deployment view containing the artifact, if not found in the package containing the deployment view etc ...
When inline force include in header is set the types referenced in the profile of the inline operations produce includes in the header, else the code generator doesn't take care if there are inline operations to compute dependencies
The generated file name is the artifact's name with the extension specified in the first C++ tab of the generations settings.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${NAME} produce the artifact name capitalized, ${Name} produce the artifact name with the first letter capitalized, ${nAME} produce the artifact name forced in lowercase, at least ${name} produce the artifact name without modification.
${comment} is replaced by the description of the artifact adding //
${description} is replaced by the artifact description without adding //
${includes} if ${all_includes} is not used in the header definition, it is replaced by the automatically generated #include and using forms, corresponding to the declaration generated in the header file. If ${all_includes} is used in the header definition, it is replaced by the #include of the header. It is also a good place to add your #include and using forms.
${namespace} is replaced by the name of the current namespace (an empty string out of a namespace), dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined. ${NAMESPACE} does the same but focing characters in upper case.
${namespace_start} is replaced by the namespace xx { forms, dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined.
${members} is replaced by the non inline members of the classes and extra artifact definitions associated to the artifact.
${namespace_end} is replaced by the } forms, dependent on the namespace specifications associated to the package containing the deployment view where the artifact is defined.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the artifact, if not found for the deployment view containing the artifact, if not found in the package containing the deployment view etc ...
The C++ definition of a class is set through the Uml, Parametrized, Instantiate and C++ tabs of the class dialog.
A C++ type definition may be a class, a struct, an union, an enum, a class enum, a template or a template typedef, depending on the stereotype and its translation in C++ (see generation settings).
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${comment} is replaced by the description of the class adding //
${description} is replaced by the class description without adding //
${template} produce a template declaration in case the class is a template class
${name} is replaced by the class's name
${inherit} is replaced by the class inheritance, with the special case associated to the template typedefs
${members} is replaced by the code generated for all the class's members (relations, attributes, operations and extra members) following the browser order.
${items} only for the enums, is replaced by the enum's items
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the class, if not found for the container of the class (an other class of a class view) etc ...
In the special case where the class is declared external, its C++ type declaration must contains at least one line indicating how the name of the class is generated, the other lines will be added in the header file of the components referencing the class. By default the first line only contain ${name} meaning that the name is produced unchanged, the only allowed keywords are ${name}, ${Name} and ${NAME}. For instance you want to define the external class string and you want to automatically generate #include <string> followed by using namespace std; you just have to create the class string, to set it external in C++ and to have the declaration form :
${name}
#include <string>
using namespace std;
If you don't want to use the namespace and ask to write std::string the declaration must be :
std::${name}
#include <string>
The C++ definition of an operation is set through the Uml and C++ tabs of the operation dialog.
The indentation of the first line of the declaration/definition give the indentation added to the visibility specification in the class definition for all the operation declaration/definition (except for the pre-processor forms beginning by # whose are placed at the beginning of the line).
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${comment} is replaced by the description of the operation adding //
${description} is replaced by the operation description without adding //
${static} produce static when the operation is a class operation (see the UML tab)
${const} produce const when the operation is const
${volatile} produce volatile when the operation is volatile
${friend} produce friend when the operation is friend
${virtual} produce virtual when the oprration is virtual
${inline} produce inline when the operation is inline
${type} is replaced by the returned value type (see the UML tab)
${multiplicity} is replaced by the multiplicity of the return type (see the UML tab), a priori used in a comment
${name} is replaced by the operation's name
${class} is replaced by the name of the class containing the operation.
${(} and ${)} produce ( and ), but there are also a mark for BOUML to find the parameters list
${abstract} produce the string = 0 when the operation is abstract (see the UML tab)
${staticnl} produce a line break when the operation is static, else an empty string.
${t<n>}, ${p<n>} and ${v<n>} produce the type, name and default value of each parameter (count from 0), this allows you to remove a parameter, add type modifiers etc ...
${m<n>} produce the multiplicity of each parameter (count from 0), a priori used in a comment
${throw} is replaced by the form throw (...) when at least an exception is defined in the UML tab. It is also possible to produce throw() when there is no exception depending on the generation settings.
${body} is replaced by the body of the operation, this macro may also be replaced by the body itself (BOUML use this way for the get and set operations associated to a relation/attribute). The usage of ${body} has a great advantage : when you hit Default definition or From declaration the body is not cleared ! At least BOUML share the declaration and definition forms of the operations (and other objects) to minimize the needed memory size, ${body} help for this ! The indentation of the keyword ${body} is added at the beginning of each line except the ones starting by a '#' or when the previous one ends by '\'.
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the operation, if not found for the class containing the operation etc ...
A template operation is defined with an empty declaration (allowing Bouml to detect this case) and placing the actuals between ${class} and :: in the declaration part.
If the toggle preserve operations's body is set through the Languages menu, the generators do not modify the body of the operations protected by dedicated delimiters. This means that for them the body definition set through BOUML is not used. The first time you generate the code with the toggle set, because the delimiters are not yet present in the generated code, the operation's body will be updated depending on their definition under BOUML. After, while the toggle is set and the delimiters present, the bodies will not change, allowing you to modify them out of BOUML.
Notes :
In case the file containing a body definition is not consistent with the artifact under BOUML, the body will be regenerated by the code generation, using its definition under the model. Of course an operations becoming inline or stopping to be inline is not a problem.
When you import a project, the body of the imported operations must be the right one in the imported model. The preserved bodies of the imported operations will not be find because the identifier of an operation used to mark its body changes during the import.
The bodies under the model are not updated by the code generation, use roundtrip body for that
Only the operations using the keyword ${body} may have a preserved body.
The only modification you can do in the lines containing the delimiters is the indent.
The toggle is saved in the file associated to the project, be sure the save is done when you change this toggle !
The C++ definition of an attribute is set through the Uml and C++ tabs of the attribute dialog.
The indentation of the first line of the definition give the indentation added to the visibility specification in the class definition for all the attribute definition (except for the pre-processor commands beginning by # whose are placed at the beginning of the line).
An attribute may be a standard attribute or the item of an enumeration.
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${comment} is replaced by the description of the attribute adding //
${description} is replaced by the attribute description without adding //
${static} produce static when the attribute is a class attribute (see the UML tab)
${mutable} produce mutable when the attribute is mutable
${volatile} produce volatile when the attribute is volatile
${thread_local} produce an empty string when the check box thread_local is not checked, else produce thread_local
${const} produce const when the attribute is const (see the UML tab) or constexpr when the check box constexpr is checked in the C++ tab
${type} is replaced by the type of the attribute (see the UML tab)
${stereotype} is replaced by the translation in C++ of the relation's stereotype (see the UML tab)
${multiplicity} is replaced by the multiplicity of the relation (see the UML tab), must be used in case the multiplicity is a vector or array dimensioning ([ and ] are added when they are not present).
${name} is replaced by the attribute's name (see the UML tab)
${value} is replaced by the initial value of the static attribute in the definition part generated in the source file (see the UML tab), ${value} and ${h_value} are exclusive
${h_value} is replaced by the initial value of the static attribute in the declaration part generated in the header file (see the UML tab), ${value} and ${h_value} are exclusive
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the attribute, if not found for the class containing the attribute etc ...
The macros known by the C++ code generator are :
${comment} is replaced by the description of the item adding //
${description} is replaced by the item description without adding //
${name} is replaced by the item's name (see the UML tab)
${value} is replaced by the value of the item (see the UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the attribute, if not found for the class containing the attribute etc ...
The C++ definition of a relation is set through the Uml and C++ tabs of the relation dialog.
The indentation of the first line of the definition give the indentation added to the visibility specification in the class definition for all the relation definition (except for the pre-processor commands beginning by # whose are placed at the beginning of the line).
In BOUML the generated code is obtained by the substitution of macros in a text, the macros known by the C++ code generator are :
${comment} is replaced by the description of the relation adding //
${description} is replaced by the relation description without adding //
${static} produce static when the relation is a class relation (see the UML tab)
${const} produce const when the relation is read-only (see the UML tab) or constexpr when the check box constexpr is checked in the C++ tab
${type} is replaced by the class pointed by the relation (see the UML tab)
${name} is replaced by the relation's role name (see the UML tab)
${inverse_name} is replaced by the name of the inverse role (see the UML tab)
${value} is replaced by the initial value of the static relation in the definition part generated in the source file (see the UML tab), ${value} and ${h_value} are exclusive
${h_value} is replaced by the initial value of the static relation in the declaration part generated in the header file (see the UML tab), ${value} and ${h_value} are exclusive
${thread_local} produce an empty string when the check box thread_local is not checked, else produce thread_local
${mutable} produce mutable when the relation is mutable
${volatile} produce volatile when the relation is volatile
${stereotype} is replaced by the translation in C++ of the relation's stereotype (see the UML tab)
${multiplicity} is replaced by the multiplicity of the relation (see the UML tab), must be used in case the multiplicity is a vector or array dimensioning ([ and ] are added when they are not present).
${association} is replaced by the association class (see UML tab)
@{xyz} is replaced by the user property value in case xyz is the key of this property. The property if searched first for the relation, if not found for the class containing the relation etc ...
A dependency having the stereotype friend produce a C++ friend declaration of the pointed class.
With an other stereotype the dependency may produce an #include of the artifact associated to the target class, and you can choose to place this #include in the header or source file by editing the dependency usingn the tab C++.
The class inheritance are managed at the class level.
${type} is replaced by the name of the inherited class more the actuals if the generated class instantiate a template.
The C++ definition of an extra member is set through the C++ tabs of the extra member dialog.
No macros.
Previous : profile
Next : C++ reverse