diff --git a/usrguide/apiguide/1-introduction.adoc b/usrguide/apiguide/1-introduction.adoc
index 60756626951d572ba69aa27a79598e67224444d6..3838e6a8b9c943093057a89ec2ad81aa5c599cd1 100644
--- a/usrguide/apiguide/1-introduction.adoc
+++ b/usrguide/apiguide/1-introduction.adoc
@@ -2,7 +2,7 @@
 
 == Overview
 
-This document describes the TITAN API on C\++ level. It is intended for users who write test port implementation, external function implementation in language C++ and want to use the available resources of TITAN.
+This document describes the TITAN API on C\++ level. It is intended for users who write test port implementation, external function implementation in language {cpp} and want to use the available resources of TITAN.
 
 Detailed information can be found on the following topics:
 
@@ -10,13 +10,13 @@ Detailed information can be found on the following topics:
 
 * built-in encoding and decoding functions;
 
-* TTCN-3 data mapping to C++ constructs;
+* TTCN-3 data mapping to {cpp} constructs;
 
 * troubleshooting for common TTCN-3 related issues and problems.
 
 == Target Groups
 
-This document is intended for advanced users of the TITAN API on C++ level.
+This document is intended for advanced users of the TITAN API on {cpp} level.
 
 == Typographical Conventions
 
diff --git a/usrguide/apiguide/2-test_ports.adoc b/usrguide/apiguide/2-test_ports.adoc
index 462a0bea1fed07b662c1bc3f983d2919810fa3d4..76cbd09754008945243d681d5446d3491828f269 100644
--- a/usrguide/apiguide/2-test_ports.adoc
+++ b/usrguide/apiguide/2-test_ports.adoc
@@ -2,21 +2,21 @@
 :table-number: 0
 :toc:
 
-The C++ source code generated by the Compiler is protocol independent, that is, it does not contain any device specific operations. To provide the connection between the executable test suite and SUT, that is, the physical interface of the test equipmentfootnote:[The test equipment not necessarily requires a special hardware; it can even be a simple PC with an Ethernet interface.], a so-called Test Port is needed.
+The {cpp} source code generated by the Compiler is protocol independent, that is, it does not contain any device specific operations. To provide the connection between the executable test suite and SUT, that is, the physical interface of the test equipmentfootnote:[The test equipment not necessarily requires a special hardware; it can even be a simple PC with an Ethernet interface.], a so-called Test Port is needed.
 
-The Test Port is a software library written in C++ language, which is linked to the executable test program. It maps the device specific operations to function calls specified in an API. This chapter describes the Test Port API in details.
+The Test Port is a software library written in {cpp} language, which is linked to the executable test program. It maps the device specific operations to function calls specified in an API. This chapter describes the Test Port API in details.
 
 == Generating the Skeleton
 
 The functions of Test Ports must be written by the user who knows the interface between the executable test suite and the test equipment. In order to make this development easier, the Compiler can generate Test Port skeletons. A Test Port belongs to one certain TTCNâ€“3 port type, so the skeleton is generated based on port type definitions.
 
-A Test Port consists of two parts. One part is generated automatically by the Compiler, and it is put into the generated C++ code. The user has nothing to do with this part.
+A Test Port consists of two parts. One part is generated automatically by the Compiler, and it is put into the generated {cpp} code. The user has nothing to do with this part.
 
-The other part is a C\++ class, which is written mainly by the user. This class can be found in a separate C++ header and source file (their suffixes are `.hh` and `.cc`, respectively). The names of the source files and the C++ class are identical to the name of the port type. Please note that the name mapping rules described in <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> also apply to these class and file names.
+The other part is a C\++ class, which is written mainly by the user. This class can be found in a separate {cpp} header and source file (their suffixes are `.hh` and `.cc`, respectively). The names of the source files and the {cpp} class are identical to the name of the port type. Please note that the name mapping rules described in <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc#mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> also apply to these class and file names.
 
 During the translation, when the Compiler encounters a port type definition and the `*â€“t*` command line switch is used, it checks whether the header and source files of Test Port exist in its working directory. If none of them can be found there, the compiler generates the skeleton header and source files for the corresponding test port automatically. This means, once you have generated (and possibly modified) a skeleton, it will never be overwritten. If you want to re-generate the skeleton, you must rename or remove the existing one.
 
-If the list of message types/signatures of a TTCN-3 port type changes, the list of the Test Port class member functions also needs to change. If the Test Port skeleton has been generated, it will not be modified, resulting in build errors (C++ compile errors like "cannot declare variable of abstract type"/"virtual functions are pure", or linker errors). In this case, the Test Port skeleton files should be renamed/moved, the skeleton generated, and any user-written code should be copied back into the newly generated source files.
+If the list of message types/signatures of a TTCN-3 port type changes, the list of the Test Port class member functions also needs to change. If the Test Port skeleton has been generated, it will not be modified, resulting in build errors ({cpp} compile errors like "cannot declare variable of abstract type"/"virtual functions are pure", or linker errors). In this case, the Test Port skeleton files should be renamed/moved, the skeleton generated, and any user-written code should be copied back into the newly generated source files.
 
 If you have defined a TTCNâ€“3 port type that you intend to use for internal communication only (that is, for sending and receiving messages between TTCNâ€“3 test components), you do not need to generate and compile an empty Test Port skeleton for that port type. Adding the attribute with `{extension "internal"}` to the port type definition in the TTCNâ€“3 module disables the generation and use of a Test Port for the port type.
 
@@ -558,7 +558,7 @@ incoming_message(const CHARSTRING& incoming_par);
 
 Receiving operations on procedure based ports is similar to receiving messages on message based ports. The difference is that there are different overloaded incoming functions for call, reply and raise operations called `incoming_call`, `incoming_reply` and `incoming_exception`, respectively. The event handler (when called) must recognize the type of operation on receiving and call one of these functions accordingly with one of the internal representations of the signature (see <<5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc #additional-non-standard-functions, Additional Non-Standard Functions>>).
 
-In the examplefootnote:[In the example the signatures were defined in a different TTCNâ€“3 module named MyModule2, as a consequence all types defined in that module must be prefixed with the C++ namespace name of that module.] the class `MyProcedurePort_BASE` has the following member functions for incoming operations:
+In the examplefootnote:[In the example the signatures were defined in a different TTCNâ€“3 module named MyModule2, as a consequence all types defined in that module must be prefixed with the {cpp} namespace name of that module.] the class `MyProcedurePort_BASE` has the following member functions for incoming operations:
 [source]
 ----
 incoming_call(const MyModule2::inProc_call& incoming_par);
@@ -689,7 +689,7 @@ This section summarizes only the differences from the normal Test Port API:
 
 * The Test Port header file must not include the generated header file of the corresponding TTCNâ€“3 module. The common header file of the Base Library called TTCN3.hh shall be included instead. The source file of the Test Port may include any header file without restriction.
 
-* The member functions of the Test Port may refer to C++ classes that are generated from user-defined message types and signatures. To avoid compilation failures the declarations of the referenced classes must be added to the beginning of the header file. At the moment the Test Port skeleton generator has a limitation that it cannot collect the class declarations from the port type, so they must be added manually. Please note that if a message type or signature is imported from another module the corresponding class declaration must be put into the appropriate namespace.
+* The member functions of the Test Port may refer to {cpp} classes that are generated from user-defined message types and signatures. To avoid compilation failures the declarations of the referenced classes must be added to the beginning of the header file. At the moment the Test Port skeleton generator has a limitation that it cannot collect the class declarations from the port type, so they must be added manually. Please note that if a message type or signature is imported from another module the corresponding class declaration must be put into the appropriate namespace.
 
 The following example shows the generated Test Port skeleton of a provider port type.
 
@@ -880,7 +880,7 @@ void MyPortType::log(const char *fmt, ...)
 
 === Error Handling
 
-None of the Test Port member functions have return value like a status code. If a function returns normally, the run-time environment assumes that it has performed its task successfully. The handling of run-time errors is done in a special way, using C++ exceptions. This simplifies the program code because the return values do not have to be checked everywhere and dynamically created complex error messages can be used if necessary.
+None of the Test Port member functions have return value like a status code. If a function returns normally, the run-time environment assumes that it has performed its task successfully. The handling of run-time errors is done in a special way, using {cpp} exceptions. This simplifies the program code because the return values do not have to be checked everywhere and dynamically created complex error messages can be used if necessary.
 
 If any kind of fatal error is encountered anywhere in the Test Port, the following function should be called:
 [source, subs="+quotes"]
diff --git a/usrguide/apiguide/3-logger_plug-ins.adoc b/usrguide/apiguide/3-logger_plug-ins.adoc
index ac1fab3ac47d0aebea0b2761f9308b1a49352afa..1f7aaf476a65fd404098953d9397679f98e70618 100644
--- a/usrguide/apiguide/3-logger_plug-ins.adoc
+++ b/usrguide/apiguide/3-logger_plug-ins.adoc
@@ -30,7 +30,7 @@ The generated, runtime specific (load-test or function-test) header file `TitanL
 
 #endif
 ----
-Unfortunately, the `dlopen()` API is a C API, not a C\++ API, but each logger plug-in is a class, which needs to be instantiated. To resolve this, the logger plug-ins are always instantiated and destroyed through C factory functions. These functions are mandatory for all logger plug-ins and they must follow C-style linkage rules. Otherwise, the function names would be mangled by the C++ compiler, using its own, implementation dependent mangling mechanism, and `dlsym()` and such functions would not be able to locate the correct symbol in the SOs of the logger plug-ins. These functions look pretty simple:
+Unfortunately, the `dlopen()` API is a C API, not a C\++ API, but each logger plug-in is a class, which needs to be instantiated. To resolve this, the logger plug-ins are always instantiated and destroyed through C factory functions. These functions are mandatory for all logger plug-ins and they must follow C-style linkage rules. Otherwise, the function names would be mangled by the {cpp} compiler, using its own, implementation dependent mangling mechanism, and `dlsym()` and such functions would not be able to locate the correct symbol in the SOs of the logger plug-ins. These functions look pretty simple:
 [source]
 ----
 #ifdef __cplusplus
@@ -79,7 +79,7 @@ void log(const TitanLoggerApi::TitanLogEvent& event, bool
 
 The first parameter event is the event itself, the second parameter `log_buffered` indicates, whether the event is coming from an internal buffer or not, `separate_file` and `use_emergency_mask` are configuration options for emergency logging. The `use_emergency_mask` flag indicates that the given event is an emergency event and should be handled in a special way by the plug-ins, the `separate_file` flag indicates that all the emergency events should be handled separately (for example written into a separate file). For more details on emergency logging please check link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[Programmer's Technical Reference]. In this function, the plug-in can handle the log events individually depending on the eventâ€™s type (that is, the alternative selected in the union `event.logEvent().choice()).`
 
-`TitanLoggerApi::TitanLogEvent` is a generated type defined in TitanLoggerApi.xsd, which can be found in `${TTCN3_DIR}/include`. This file contains all the necessary type definitions a logger plug-in should be aware of. The corresponding header files generated from this XSD file can be found in `${TTCN3_DIR}/include/{RT1/RT2}`. The mapping between TTCN-3 types and C\++ types is defined in link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCNâ€“3 Data Types to C++ Constructs].
+`TitanLoggerApi::TitanLogEvent` is a generated type defined in TitanLoggerApi.xsd, which can be found in `${TTCN3_DIR}/include`. This file contains all the necessary type definitions a logger plug-in should be aware of. The corresponding header files generated from this XSD file can be found in `${TTCN3_DIR}/include/{RT1/RT2}`. The mapping between TTCN-3 types and C\++ types is defined in link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCNâ€“3 Data Types to {cpp} Constructs].
 //The mapping between XSD and TTCN-3 types is defined in *Error! Reference source not found.*
 
 == Execution
diff --git a/usrguide/apiguide/4-encoding_and_decoding.adoc b/usrguide/apiguide/4-encoding_and_decoding.adoc
index eb2e664fcdeb36bb3dc011541f37c29eaa7813a7..925046c0a408f4cdfeddf90f6ac9654cfbb1b726 100644
--- a/usrguide/apiguide/4-encoding_and_decoding.adoc
+++ b/usrguide/apiguide/4-encoding_and_decoding.adoc
@@ -351,7 +351,7 @@ When a compound type is only used internally or it is never RAW encoded/decoded
 [[api-0]]
 === API
 
-The C++ Application Programming Interface for RAW encoding and decoding is described in the following. It can be used for example in test port implementation, in external function implementation.
+The {cpp} Application Programming Interface for RAW encoding and decoding is described in the following. It can be used for example in test port implementation, in external function implementation.
 
 [[encoding-0]]
 ==== Encoding
diff --git a/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc b/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc
index 850e6dd2f6b8ac4e4d0731558e297f157d209fd1..597086695437dff095ab1f5c91b0c5c48ed44449 100644
--- a/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc
+++ b/usrguide/apiguide/5-mapping_ttcn3_data_types_to_c++_constructs.adoc
@@ -1,22 +1,22 @@
 [[mapping-ttcn-3-data-types-to-c-constructs]]
-= Mapping TTCNâ€“3 Data Types to C++ Constructs
+= Mapping TTCNâ€“3 Data Types to {cpp} Constructs
 :table-number: 7
 :toc:
 
-The TTCNâ€“3 language elements of the test suite are individually mapped into more or less equivalent C\++ constructs. The data types are mapped to C++ classes, the test cases become C++ functions, and so on. In order to write a Test Port, it is inevitable to be familiar with the internal representation format of TTCNâ€“3 data types and values. This section gives an overview about the data types and their equivalent C++ constructs.
+The TTCNâ€“3 language elements of the test suite are individually mapped into more or less equivalent C\++ constructs. The data types are mapped to {cpp} classes, the test cases become {cpp} functions, and so on. In order to write a Test Port, it is inevitable to be familiar with the internal representation format of TTCNâ€“3 data types and values. This section gives an overview about the data types and their equivalent {cpp} constructs.
 
 [[mapping-of-names-and-identifiers]]
 == Mapping of Names and Identifiers
 
-In order to identify the TTCNâ€“3 language elements in the generated C\++ program properly, the names of test suite are translated to C++ identifiers according to the following simple rules.
+In order to identify the TTCNâ€“3 language elements in the generated C\++ program properly, the names of test suite are translated to {cpp} identifiers according to the following simple rules.
 
-If the TTCNâ€“3 identifier does not contain any underscore (_) character, its equivalent C\++ identifier will be the same. For example, the TTCNâ€“3 variable `MyVar` will be translated to a C++ variable called `MyVar`.
+If the TTCNâ€“3 identifier does not contain any underscore (_) character, its equivalent C\++ identifier will be the same. For example, the TTCNâ€“3 variable `MyVar` will be translated to a {cpp} variable called `MyVar`.
 
-If the TTCNâ€“3 identifier contains one or more underscore characters, each underscore character will be duplicated in the C\++ identifier. So the TTCNâ€“3 identifier `My_Long_Name` will be mapped to a C++ identifier called `My\__Long__Name`.
+If the TTCNâ€“3 identifier contains one or more underscore characters, each underscore character will be duplicated in the C\++ identifier. So the TTCNâ€“3 identifier `My_Long_Name` will be mapped to a {cpp} identifier called `My\__Long__Name`.
 
-The idea behind this name mapping is that we may freely use the C\++ identifiers containing one underscore character in the generated code and in the Test Ports as well. Otherwise name clashes can always happen because the name space of TTCNâ€“3 and C++ is identical. Furthermore, the generated C\++ language elements fulfill the condition that the scope of a translated C++ identifier is identical as the scope of the original TTCNâ€“3 identifier.
+The idea behind this name mapping is that we may freely use the C\++ identifiers containing one underscore character in the generated code and in the Test Ports as well. Otherwise name clashes can always happen because the name space of TTCNâ€“3 and {cpp} is identical. Furthermore, the generated C\++ language elements fulfill the condition that the scope of a translated {cpp} identifier is identical as the scope of the original TTCNâ€“3 identifier.
 
-The identifiers that are keywords of C or C\++ but not keywords in TTCNâ€“3 are mapped to themselves, but a single underscore character is appended at the end (for example `typedef` becomes `typedef_`). The same rule applies to the all-uppercase identifiers that are used in the Base Library: identifier `INTEGER` in TTCNâ€“3 becomes `INTEGER_` in C++, `TRUE` footnote:[The built-in `verdict` and `boolean` constants in TTCNâ€“3 shall be written with all lowercase letters, such as true or pass. Although previous compiler versions have accepted `TRUE` or `PASS` as well, these words are treated by the compiler as regular identifiers as specified in the standard.] is mapped to `TRUE_`, etc.
+The identifiers that are keywords of C or C\++ but not keywords in TTCNâ€“3 are mapped to themselves, but a single underscore character is appended at the end (for example `typedef` becomes `typedef_`). The same rule applies to the all-uppercase identifiers that are used in the Base Library: identifier `INTEGER` in TTCNâ€“3 becomes `INTEGER_` in {cpp}, `TRUE` footnote:[The built-in `verdict` and `boolean` constants in TTCNâ€“3 shall be written with all lowercase letters, such as true or pass. Although previous compiler versions have accepted `TRUE` or `PASS` as well, these words are treated by the compiler as regular identifiers as specified in the standard.] is mapped to `TRUE_`, etc.
 
 Here is the complete list (in alphabetical order) of the identifiers that are handled in such special way:asm, auto, bitand, bitor, bool, break, case, class, compl, continue, delete, double, enum, explicit, export, friend, inline, int, ischosen, long, main, mutable, namespace, new, operator, private, protected, public, register, short, signed, static, stderr, stdin, stdout, struct, switch, this, throw, try, typedef, typeid, typename, unsigned, using, virtual, void, volatile, ADDRESS, BITSTRING, BOOLEAN, CHAR, CHARSTRING, COMPONENT, DEFAULT, ERROR, FAIL, FALSE, FLOAT, HEXSTRING, INCONC, INTEGER, NONE, OBJID, OCTETSTRING, PASS, PORT, TIMER, TRUE, VERDICTTYPE.
 
@@ -28,16 +28,16 @@ WARNING: By default, from version 1.2.pl0 the compiler does NOT duplicate the un
 
 == Namespaces
 
-The compiler generates a C++ namespace for every TTCNâ€“3 and ASN.1 module. All C++ definitions that belong to the module (including Test Port classes and external functions) are placed in that namespace. The name of the namespace is derived from the module identifier according to the rules described in <<mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
+The compiler generates a {cpp} namespace for every TTCNâ€“3 and ASN.1 module. All {cpp} definitions that belong to the module (including Test Port classes and external functions) are placed in that namespace. The name of the namespace is derived from the module identifier according to the rules described in <<mapping-of-names-and-identifiers, Mapping of Names and Identifiers>>.
 
 The definitions of the TTCNâ€“3 Base Library do not use any namespace.
 
-When accessing a C\++ entity that belongs to a different module than the referring Test Port or external function is in the reference has to be prefixed with the namespace of the referenced module. For example, to access the C++ class that realizes type `MyType` defined in `MyModule1` from a Test Port that belongs to module `MyModule2` the reference shall be written as `MyModule1::MyType`.
+When accessing a C\++ entity that belongs to a different module than the referring Test Port or external function is in the reference has to be prefixed with the namespace of the referenced module. For example, to access the {cpp} class that realizes type `MyType` defined in `MyModule1` from a Test Port that belongs to module `MyModule2` the reference shall be written as `MyModule1::MyType`.
 
 [[predefined-ttcn-3-data-types]]
 == Predefined TTCNâ€“3 Data Types
 
-There are some basic data types in TTCNâ€“3 that have no equivalent data types in language C/C\++ (for example bitstring, verdicttype). Other types have C++ equivalent, but the TTCNâ€“3 executor must know whether a variable has a valid value or not because sending an unbound value must result in a dynamic test case error. Thus, in the TTCNâ€“3 Base Library all basic data types of TTCNâ€“3 were implemented as C++ classes. This section describes the member functions of these classes.
+There are some basic data types in TTCNâ€“3 that have no equivalent data types in language C/C\++ (for example bitstring, verdicttype). Other types have {cpp} equivalent, but the TTCNâ€“3 executor must know whether a variable has a valid value or not because sending an unbound value must result in a dynamic test case error. Thus, in the TTCNâ€“3 Base Library all basic data types of TTCNâ€“3 were implemented as {cpp} classes. This section describes the member functions of these classes.
 
 === `Integer`
 
@@ -96,7 +96,7 @@ The class `INTEGER` has the following public member functions:
 
 The comparison, arithmetic and shifting operators are also available as global functions for that case when the left side is `int` and the right side is `INTEGER`. Using the value of an unbound variable for anything will cause dynamic test case error.
 
-The casting operator `int()` is applicable only to `INTEGER` objects holding a signed value with at most 31 useful bits, since in C/C++ the native `int` type is 32-bit large including the sign bit. Casting an `INTEGER` object holding a bigger (for example a 32-bit unsigned) value will result in run-time error.
+The casting operator `int()` is applicable only to `INTEGER` objects holding a signed value with at most 31 useful bits, since in C/{cpp} the native `int` type is 32-bit large including the sign bit. Casting an `INTEGER` object holding a bigger (for example a 32-bit unsigned) value will result in run-time error.
 
 Please note that if the value stored in an `INTEGER` object is too big (that is, it cannot be represented as a `long long int`) the value returned by `get_long_long_val()` will contain only the lowest `sizeof(long long int)` bytes of the original value. Another way to obtain a value of a number having more useful bits than 31 is to convert the INTEGER object to its string representation using the `int2str()` predefined function. Then the string value can be converted to any native integer type using the `sscanf()` library function or such. The following example demonstrates a common scenario:
 [source]
@@ -298,7 +298,7 @@ void TTCN_Runtime::setverdict(const VERDICTTYPE&);
 verdicttype TTCN_Runtime::getverdict();
 ----
 
-These functions are the C\++ equivalents of TTCNâ€“3 `setverdict` and `getverdict` operations. Use them only if your Test Port or C++ function encounters a low-level failure, but it can continue its normal operation (that is, error recovery is not necessary).
+These functions are the C\++ equivalents of TTCNâ€“3 `setverdict` and `getverdict` operations. Use them only if your Test Port or {cpp} function encounters a low-level failure, but it can continue its normal operation (that is, error recovery is not necessary).
 
 Other operators (global functions):
 [source]
@@ -311,7 +311,7 @@ boolean operator!=(verdicttype par_value,
 
 === `Bitstring`
 
-The equivalent C++ class of TTCNâ€“3 type `bitstring` is called `BITSTRING`. The bits of the bit string are stored in an array of unsigned characters. In order to reduce the wasted memory space the bits are packed together, so each character contains eight bits. The first character contains the first eight bits of the bit string; the second byte contains the bits from the 9th up to the 16th, and so on. The first bit of the bit string is the LSB of the first character; the second bit is the second least significant bit of the first character, and so on. The character array is not terminated with a `NUL` character and if the length of the bit string is not a multiple of eight, the unused bits of the last character can contain any value. So the length of the bit string must be always given.
+The equivalent {cpp} class of TTCNâ€“3 type `bitstring` is called `BITSTRING`. The bits of the bit string are stored in an array of unsigned characters. In order to reduce the wasted memory space the bits are packed together, so each character contains eight bits. The first character contains the first eight bits of the bit string; the second byte contains the bits from the 9th up to the 16th, and so on. The first bit of the bit string is the LSB of the first character; the second bit is the second least significant bit of the first character, and so on. The character array is not terminated with a `NUL` character and if the length of the bit string is not a multiple of eight, the unused bits of the last character can contain any value. So the length of the bit string must be always given.
 
 The class `BITSTRING` has the following public member functions:
 
@@ -345,24 +345,24 @@ and pointer to character array.
 |const BITSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
 |const BITSTRING_ELEMENT operator[](const INTEGER&) const |
 .8+^.^|_Bitwise operators_
-|BITSTRING operator~() const |C++ equivalent of operator not4b. (bitwise negation)
-|BITSTRING operator&(const BITSTRING&) const |C++ equivalent of operator
+|BITSTRING operator~() const |{cpp} equivalent of operator not4b. (bitwise negation)
+|BITSTRING operator&(const BITSTRING&) const |{cpp} equivalent of operator
 and4b. (bitwise and)
 |BITSTRING operator&(const BITSTRING_ELEMENT&) const |
-|BITSTRING operator|(const BITSTRING&) const |C++ equivalent of operator
+|BITSTRING operator|(const BITSTRING&) const |{cpp} equivalent of operator
 or4b. (bitwise or)
 |BITSTRING operator|(const BITSTRING_ELEMENT&) const |
-|BITSTRING operatorË†(const BITSTRING&) const |C++ equivalent of operator
+|BITSTRING operatorË†(const BITSTRING&) const |{cpp} equivalent of operator
 xor4b. (bitwise xor)
 |BITSTRING operator^(const BITSTRING_ELEMENT&) const |
 .8+^.^|_Shifting and rotating operators_
-|BITSTRING operator<<(int) const |C++ equivalent of operator
+|BITSTRING operator<<(int) const |{cpp} equivalent of operator
 |BITSTRING operator<<(const INTEGER&) const |<<.(shift left)
-|BITSTRING operator>>(int) const |C++ equivalent of operator
+|BITSTRING operator>>(int) const |{cpp} equivalent of operator
 |BITSTRING operator>>(const INTEGER&) const |>>. (shift right)
-|BITSTRING operator<<=(int) const |C++ equivalent of operator
+|BITSTRING operator<<=(int) const |{cpp} equivalent of operator
 |BITSTRING operator<<=(const INTEGER&) const |< @. (rotate left)
-|BITSTRING operator>>=(int) const |C++ equivalent of operator
+|BITSTRING operator>>=(int) const |{cpp} equivalent of operator
 |BITSTRING operator>>=(const INTEGER&) const |@ >. (rotate right)
 ^.^|_Casting operator_
 |operator const unsigned char*() const |Returns a pointer to the character array.
@@ -379,7 +379,7 @@ Using the value of an unbound `BITSTRING` variable for anything will cause dynam
 
 ==== `Bitstring element`
 
-The C++ class `BITSTRING_ELEMENT` is the equivalent of the TTCN-3 `bitstring`â€™s element type (the result of indexing a `bitstring` value). The class does not store the actual bit, only a reference to the original `BITSTRING` object, an index value and a bound flag.
+The {cpp} class `BITSTRING_ELEMENT` is the equivalent of the TTCN-3 `bitstring`â€™s element type (the result of indexing a `bitstring` value). The class does not store the actual bit, only a reference to the original `BITSTRING` object, an index value and a bound flag.
 
 Note: changing the value of the `BITSTRING_ELEMENT` (through the assignment operator) changes the referenced bit in the original `bitstring` object.
 
@@ -404,14 +404,14 @@ The class `BITSTRING_ELEMENT` has the following public member functions:
 |BITSTRING operator+(const BITSTRING&) const |Concatenates a bitstring element with a bitstring, or two bitstring elements.
 |BITSTRING operator+(const BITSTRING_ELEMENT&) const |
 .8+^.^|_Bitwise operators_
-|BITSTRING operator~() const |C++ equivalent of operator not4b. (bitwise negation)
-|BITSTRING operator&(const BITSTRING&) const |C++ equivalent of operator
+|BITSTRING operator~() const |{cpp} equivalent of operator not4b. (bitwise negation)
+|BITSTRING operator&(const BITSTRING&) const |{cpp} equivalent of operator
 and4b. (bitwise and)
 |BITSTRING operator&(const BITSTRING_ELEMENT&) const  |
-|BITSTRING operator|(const BITSTRING&) const  | C++ equivalent of operator
+|BITSTRING operator|(const BITSTRING&) const  | {cpp} equivalent of operator
 or4b. (bitwise or)
 |BITSTRING operator|(const BITSTRING_ELEMENT&) const  |
-|BITSTRING operatorË†(const BITSTRING&) const | C++ equivalent of operator
+|BITSTRING operatorË†(const BITSTRING&) const | {cpp} equivalent of operator
 xor4b. (bitwise xor)
 |BITSTRING operatorË†(const BITSTRING_ELEMENT&) const |
 .4+^.^|_Other member functions_
@@ -425,7 +425,7 @@ Using the value of an unbound `BITSTRING_ELEMENT` variable for anything will cau
 
 === `Hexstring`
 
-The equivalent C++ class of TTCNâ€“3 type `hexstring` is called `HEXSTRING`. The hexadecimal digits (nibbles) are stored in an array of unsigned characters. In order to reduce the wasted memory space two nibbles are packed into one character. The first character contains the first two nibbles of the `hexstring`, the second byte contains the third and fourth nibbles, and so on. The hexadecimal digits at odd (first, third, fifth, etc.) positions occupy the lower 4 bits in the characters; the even ones use the upper 4 bits. The character array is never terminated with a `NUL` character, so the length must be always given with the pointer. If the `hexstring` has odd length the unused upper 4 bits of the last character may contain any value.
+The equivalent {cpp} class of TTCNâ€“3 type `hexstring` is called `HEXSTRING`. The hexadecimal digits (nibbles) are stored in an array of unsigned characters. In order to reduce the wasted memory space two nibbles are packed into one character. The first character contains the first two nibbles of the `hexstring`, the second byte contains the third and fourth nibbles, and so on. The hexadecimal digits at odd (first, third, fifth, etc.) positions occupy the lower 4 bits in the characters; the even ones use the upper 4 bits. The character array is never terminated with a `NUL` character, so the length must be always given with the pointer. If the `hexstring` has odd length the unused upper 4 bits of the last character may contain any value.
 
 The class `HEXSTRING` has the following public member functions:
 
@@ -458,24 +458,24 @@ The class `HEXSTRING` has the following public member functions:
 |const HEXSTRING_ELEMENT operator[](int) const |
 |const HEXSTRING_ELEMENT operator[](const INTEGER&) const |
 .8+^.^|_Bitwise operators_
-|HEXSTRING operator~() const  |C++ equivalent of operator not4b. (bitwise negation)
-|HEXSTRING operator&(const HEXSTRING&) const  |C++ equivalent of operator
+|HEXSTRING operator~() const  |{cpp} equivalent of operator not4b. (bitwise negation)
+|HEXSTRING operator&(const HEXSTRING&) const  |{cpp} equivalent of operator
 and4b. (bitwise and)
 |HEXSTRING operator&(const HEXSTRING_ELEMENT&) const  |
-|HEXSTRING operator|(const HEXSTRING&) const  |C++ equivalent of operator
+|HEXSTRING operator|(const HEXSTRING&) const  |{cpp} equivalent of operator
 or4b. (bitwise or)
 |HEXSTRING operator|(const HEXSTRING_ELEMENT&) const  |
-|HEXSTRING operatorË†(const HEXSTRING&) const  |C++ equivalent of operator
+|HEXSTRING operatorË†(const HEXSTRING&) const  |{cpp} equivalent of operator
 xor4b. (bitwise xor)
 |HEXSTRING operator^(const HEXSTRING_ELEMENT&) const  |
 .8+^.^|_Shifting and rotating operators_
-|HEXSTRING operator<<(int) const  |C++ equivalent of operator
+|HEXSTRING operator<<(int) const  |{cpp} equivalent of operator
 |HEXSTRING operator<<(const INTEGER&) const  |<<.(shift left)
-|HEXSTRING operator>>(int) const  |C++ equivalent of operator
+|HEXSTRING operator>>(int) const  |{cpp} equivalent of operator
 |HEXSTRING operator>>(const INTEGER&) const  |>>. (shift right)
-|HEXSTRING operator<<=(int) const  |C++ equivalent of operator
+|HEXSTRING operator<<=(int) const  |{cpp} equivalent of operator
 |HEXSTRING operator<<=(const INTEGER&) const  |< @. (rotate left)
-|HEXSTRING operator>>=(int) const |C++ equivalent of operator
+|HEXSTRING operator>>=(int) const |{cpp} equivalent of operator
 |HEXSTRING operator>>=(const INTEGER&) const  |@ >. (rotate right)
 ^.^|_Casting operator_
 |operator const unsigned char*() const |Returns a pointer to the character array. The pointer might be NULL if the length is 0.
@@ -490,7 +490,7 @@ Using the value of an unbound `HEXSTRING` variable for anything will cause a dyn
 
 ==== `Hexstring` element
 
-The C++ class `HEXSTRING_ELEMENT` is the equivalent of the TTCN-3 `hexstring`â€™s element type (the result of indexing a `hexstring` value). The class does not store the actual hexadecimal digit (nibble), only a reference to the original HEXSTRING object, an index value and a bound flag.
+The {cpp} class `HEXSTRING_ELEMENT` is the equivalent of the TTCN-3 `hexstring`â€™s element type (the result of indexing a `hexstring` value). The class does not store the actual hexadecimal digit (nibble), only a reference to the original HEXSTRING object, an index value and a bound flag.
 
 Note: changing the value of the `HEXSTRING_ELEMENT` (through the assignment operator) changes the referenced nibble in the original `hexstring` object.
 
@@ -515,14 +515,14 @@ The class `HEXSTRING_ELEMENT` has the following public member functions:
 |HEXSTRING operator+(const HEXSTRING&) const  |Concatenates a hexstring element with a hexstring, or two hexstring elements.
 |HEXSTRING operator+(const HEXSTRING_ELEMENT&) const |
 .8+^.^|_Bitwise operators_
-|HEXSTRING operator~() const  |C++ equivalent of operator not4b. (bitwise negation)
-|HEXSTRING operator&(const HEXSTRING&) const |C++ equivalent of operator
+|HEXSTRING operator~() const  |{cpp} equivalent of operator not4b. (bitwise negation)
+|HEXSTRING operator&(const HEXSTRING&) const |{cpp} equivalent of operator
 and4b. (bitwise and)
 |HEXSTRING operator&(const HEXSTRING_ELEMENT&) const  |
-|HEXSTRING operator|(const HEXSTRING&) const  |C++ equivalent of operator
+|HEXSTRING operator|(const HEXSTRING&) const  |{cpp} equivalent of operator
 or4b. (bitwise or)
 |HEXSTRING operator|(const HEXSTRING_ELEMENT&) const  |
-|HEXSTRING operatorË†(const HEXSTRING&) const |C++ equivalent of operator
+|HEXSTRING operatorË†(const HEXSTRING&) const |{cpp} equivalent of operator
 xor4b. (bitwise xor)
 |HEXSTRING operatorË†(const HEXSTRING_ELEMENT&) const |
 .3+^.^|_Other member functions_
@@ -536,7 +536,7 @@ Using the value of an unbound `HEXSTRING_ELEMENT` variable for anything will cau
 
 === `Octetstring`
 
-The equivalent C++ class of TTCNâ€“3 type `octetstring` is called `OCTETSTRING`. The octets are stored in an array of unsigned characters. Each character contains one octet; the first character is the first octet of the string. The character array is not terminated by a `NUL` character, so the length of the octet string must be always given.
+The equivalent {cpp} class of TTCNâ€“3 type `octetstring` is called `OCTETSTRING`. The octets are stored in an array of unsigned characters. Each character contains one octet; the first character is the first octet of the string. The character array is not terminated by a `NUL` character, so the length of the octet string must be always given.
 
 The class `OCTETSTRING` has the following public member functions:
 
@@ -571,24 +571,24 @@ The class `OCTETSTRING` has the following public member functions:
 |const OCTETSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
 |const OCTETSTRING_ELEMENT operator[](const INTEGER&) const |
 .8+^.^|_Bitwise operators_
-|OCTETSTRING operatorËœ() const  |C++ equivalent of operator not4b.(bitwise negation)
-|OCTETSTRING operator&(const OCTETSTRING&) const |C++ equivalent of operator and4b.
+|OCTETSTRING operatorËœ() const  |{cpp} equivalent of operator not4b.(bitwise negation)
+|OCTETSTRING operator&(const OCTETSTRING&) const |{cpp} equivalent of operator and4b.
 (bitwise and)
 |OCTETSTRING operator&(const OCTETSTRING_ELEMENT&) const |
-|OCTETSTRING operator|(const OCTETSTRING&) const  |C++ equivalent of operator or4b.
+|OCTETSTRING operator|(const OCTETSTRING&) const  |{cpp} equivalent of operator or4b.
 (bitwise or)
 |OCTETSTRING operator|(const OCTETSTRING_ELEMENT&) const |
-|OCTETSTRING operatorË†(const OCTETSTRING&) const |C++ equivalent of operator xor4b.
+|OCTETSTRING operatorË†(const OCTETSTRING&) const |{cpp} equivalent of operator xor4b.
 (bitwise xor)
 |OCTETSTRING operator^(const OCTETSTRING_ELEMENT&) const |
 .8+^.^|_Shifting and rotating operators_
-|OCTETSTRING operator<<(int) const |C++ equivalent of operator <<.
+|OCTETSTRING operator<<(int) const |{cpp} equivalent of operator <<.
 |OCTETSTRING operator<<(const INTEGER&) const |(shift left)
-|OCTETSTRING operator>>(int) const  |C++ equivalent of operator >>.
+|OCTETSTRING operator>>(int) const  |{cpp} equivalent of operator >>.
 |OCTETSTRING operator>>(const INTEGER&) const  |(shift right)
-|OCTETSTRING operator<<=(int) const  |C++ equivalent of operator < @.
+|OCTETSTRING operator<<=(int) const  |{cpp} equivalent of operator < @.
 |OCTETSTRING operator<<=(const INTEGER&) const  |(rotate left)
-|OCTETSTRING operator>>=(int) const  |C++ equivalent of operator @ >.
+|OCTETSTRING operator>>=(int) const  |{cpp} equivalent of operator @ >.
 |OCTETSTRING operator>>=(const INTEGER&) const  |(rotate right)
 ^.^|_Casting operator_
 |operator const unsigned char*() const |Returns a pointer to the character array. The pointer might be NULL if the length is 0.
@@ -605,7 +605,7 @@ Using the value of an unbound `OCTETSTRING` variable for anything will cause dyn
 
 ==== `Octetstring` element
 
-The C++ class `OCTETSTRING_ELEMENT` is the equivalent of the TTCN-3 `octetstring`â€™s element type (the result of indexing an `octetstring` value). The class does not store the actual octet, only a reference to the original OCTETSTRING object, an index value and a bound flag.
+The {cpp} class `OCTETSTRING_ELEMENT` is the equivalent of the TTCN-3 `octetstring`â€™s element type (the result of indexing an `octetstring` value). The class does not store the actual octet, only a reference to the original OCTETSTRING object, an index value and a bound flag.
 
 Note: changing the value of the OCTETSTRING_ELEMENT (through the assignment operator) changes the referenced octet in the original `octetstring` object.
 
@@ -630,14 +630,14 @@ The class `OCTETSTRING_ELEMENT` has the following public member functions:
 | OCTETSTRING operator+(const OCTETSTRING&) const |Concatenates an octetstring element with an octetstring, or two octetstring elements.
 | OCTETSTRING operator+(const OCTETSTRING_ELEMENT&) const |
 .8+^.^|_Bitwise operators_
-|OCTETSTRING operator~() const |C++ equivalent of operator (bitwise negation)
-|OCTETSTRING operator&(const OCTETSTRING&) const |C++ equivalent of operator
+|OCTETSTRING operator~() const |{cpp} equivalent of operator (bitwise negation)
+|OCTETSTRING operator&(const OCTETSTRING&) const |{cpp} equivalent of operator
 and4b. (bitwise and)
 |OCTETSTRING operator&(const OCTETSTRING_ELEMENT&) const  |
-|HEXSTRING operator|(const OCTETSTRING&) const  | C++ equivalent of operator
+|HEXSTRING operator|(const OCTETSTRING&) const  | {cpp} equivalent of operator
 or4b. (bitwise or)
 |OCTETSTRING operator|(const OCTETSTRING_ELEMENT&) const  |
-|OCTETSTRING operatorË†(const OCTETSTRING&) const |C++ equivalent of operator
+|OCTETSTRING operatorË†(const OCTETSTRING&) const |{cpp} equivalent of operator
 xor4b. (bitwise xor)
 |OCTETSTRING operatorË†(const OCTETSTRING_ELEMENT&) const |
 .3+^.^|_Other member functions_
@@ -654,12 +654,12 @@ Using the value of an unbound `OCTETSTRING_ELEMENT` variable for anything will c
 
 The `char` type, which has been removed from the TTCNâ€“3 standard, is no longer supported by the run-time environment. The compiler substitutes all occurrences of `char` type with type `charstring` automatically.
 
-To provide partial backward compatibility for older Test Ports that might have used the type `char`, `CHAR` is a typedef alias to class `CHARSTRING` in C++.
+To provide partial backward compatibility for older Test Ports that might have used the type `char`, `CHAR` is a typedef alias to class `CHARSTRING` in {cpp}.
 
 [[Charstring]]
 === `Charstring`
 
-The equivalent C++ class of TTCNâ€“3 type `charstring` is called `CHARSTRING`. The characters are stored in a `NUL` character terminated array; thus, giving the length in the constructor and other operations is optional.
+The equivalent {cpp} class of TTCNâ€“3 type `charstring` is called `CHARSTRING`. The characters are stored in a `NUL` character terminated array; thus, giving the length in the constructor and other operations is optional.
 
 The class `CHARSTRING` has the following public member functions:
 
@@ -707,9 +707,9 @@ The class `CHARSTRING` has the following public member functions:
 |const CHARSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
 |const CHARSTRING_ELEMENT operator[](const INTEGER&) const |
 .4+^.^|_Rotating operators_
-|CHARSTRING operator<<=(int) const |C++ equivalent of operator < @.(rotate left)
+|CHARSTRING operator<<=(int) const |{cpp} equivalent of operator < @.(rotate left)
 |CHARSTRING operator<<=(const INTEGER&) const |
-|CHARSTRING operator>>=(int) const  |C++ equivalent of operator @ >.
+|CHARSTRING operator>>=(int) const  |{cpp} equivalent of operator @ >.
 (rotate right)
 |CHARSTRING operator>>=(const INTEGER&) const |
 ^.^|_Casting operator_
@@ -748,7 +748,7 @@ CHARSTRING operator+(const char* string_value,
 
 ==== `Charstring` element
 
-The C++ class `CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `charstring`â€™s element type (the result of indexing a `charstring` value). The class does not store the actual character, only a reference to the original CHARSTRING object, an index value and a bound flag.
+The {cpp} class `CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `charstring`â€™s element type (the result of indexing a `charstring` value). The class does not store the actual character, only a reference to the original CHARSTRING object, an index value and a bound flag.
 
 Note: changing the value of the `CHARSTRING_ELEMENT` (through the assignment operator) changes the referenced character in the original `charstring` object.
 
@@ -809,7 +809,7 @@ In case of single-octet characters, which can be also given in TTCNâ€“3 charstri
 
 Except when performing encoding or decoding, the run-time environment does not check whether the quadruples used in the following API represent valid character positions according to <<7-references.adoc#_8,[8]>>. Moreover, if ASN.1 multi-octet character string values are used, it is not verified whether the elements of such strings are permitted characters of the corresponding string type.
 
-The C++ equivalent of TTCNâ€“3 type `universal charstring` is implemented in class `UNIVERSAL_CHARSTRING`. The characters of the string are stored in an array of structure `universal_char`. The array returned by the casting operator is not terminated with a special character, thus, the length of the string must be always considered when doing operations with the array. The length of the string, which can be obtained by using member function `lengthof()`, is measured in characters (quadruples) and not bytes.
+The {cpp} equivalent of TTCNâ€“3 type `universal charstring` is implemented in class `UNIVERSAL_CHARSTRING`. The characters of the string are stored in an array of structure `universal_char`. The array returned by the casting operator is not terminated with a special character, thus, the length of the string must be always considered when doing operations with the array. The length of the string, which can be obtained by using member function `lengthof()`, is measured in characters (quadruples) and not bytes.
 
 For the more convenient usage the strings containing only single-octet characters can also be used with class `UNIVERSAL_CHARSTRING`. Therefore some polymorphic member functions and operators have variants that take `const char*` as argument. In these member functions the characters of the `NUL` character terminated string are implicitly converted to quadruples with group, plane and row fields set to zero. `NULL` pointer as argument means the empty string for these functions.
 
@@ -867,9 +867,9 @@ single-octet string.
 |const UNIVERSAL_CHARSTRING_ELEMENT operator[](int) const |Gives read-only access to the given element.
 |const UNIVERSAL_CHARSTRING_ELEMENT operator[](const INTEGER&) const |
 .4+^.^|_Rotating operators_
-|UNIVERSAL_CHARSTRING operator<<=(int) const |C++ equivalent of operator < @(rotate left).
+|UNIVERSAL_CHARSTRING operator<<=(int) const |{cpp} equivalent of operator < @(rotate left).
 |UNIVERSAL_CHARSTRING operator<<=(const INTEGER&) const |
-|UNIVERSAL_CHARSTRING operator>>=(int) const |C++ equivalent of operator @ >
+|UNIVERSAL_CHARSTRING operator>>=(int) const |{cpp} equivalent of operator @ >
 (rotate right).
 |UNIVERSAL_CHARSTRING operator>>=(const INTEGER&) const |
 ^.^|_Casting operator_
@@ -932,7 +932,7 @@ UNIVERSAL_CHARSTRING operator+(const char* string_value,
 
 ==== `Universal charstring` element
 
-The C++ class `UNIVERSAL_CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `universal charstring`â€™s element type (the result of indexing a `universal charstring` value). The class does not store the actual character, only a reference to the original `UNIVERSAL_CHARSTRING` object, an index value and a bound flag.
+The {cpp} class `UNIVERSAL_CHARSTRING_ELEMENT` is the equivalent of the TTCN-3 `universal charstring`â€™s element type (the result of indexing a `universal charstring` value). The class does not store the actual character, only a reference to the original `UNIVERSAL_CHARSTRING` object, an index value and a bound flag.
 
 Note: changing the value of the `UNIVERSAL_CHARSTRING_ELEMENT` (through the assignment operator) changes the referenced character in the original `universal charstring` object.
 
@@ -1022,7 +1022,7 @@ Using the value of an unbound `OBJID` variable for anything will cause dynamic t
 
 TTCNâ€“3 variables the types of which are defined as component types are used for storing component references to PTCs. The internal representation of component references are test tool dependent, our test executor handles them as small integer numbers.
 
-All TTCNâ€“3 component types are mapped to the same C++ class, which is called COMPONENT, using `typedef` aliases. We also use an ancillary C type called `component`, which is defined as an alias for `int`:
+All TTCNâ€“3 component types are mapped to the same {cpp} class, which is called COMPONENT, using `typedef` aliases. We also use an ancillary C type called `component`, which is defined as an alias for `int`:
 [source, subs="+quotes"]
 typedef int component;
 
@@ -1083,9 +1083,9 @@ boolean operator!=(component component_value,
 [[empty-types]]
 === Empty Types
 
-Empty `record` and `set` types are not real built-in types in TTCNâ€“3, but the C++ realization of these types also differs from regular records or sets. The empty types are almost identical to each other, only their names are different. That is why we treat them as predefined types.
+Empty `record` and `set` types are not real built-in types in TTCNâ€“3, but the {cpp} realization of these types also differs from regular records or sets. The empty types are almost identical to each other, only their names are different. That is why we treat them as predefined types.
 
-Each empty type is defined in a C\++ class, which is generated by the compiler. Using separate classes enables us to differentiate among them in C++ type polymorphism. For example, several empty types can be defined as incoming or outgoing types on the same TTCNâ€“3 port type.
+Each empty type is defined in a C\++ class, which is generated by the compiler. Using separate classes enables us to differentiate among them in {cpp} type polymorphism. For example, several empty types can be defined as incoming or outgoing types on the same TTCNâ€“3 port type.
 
 Let us consider the following TTCNâ€“3 type definition as an example:
 [source, subs="+quotes"]
@@ -1097,7 +1097,7 @@ enum null type {NULL VALUE };
 
 The only possible value stands for the TTCNâ€“3 empty record or array value (that is for "{}"), which is the only possible value of TTCNâ€“3 type `Dummy`. Note that this type and value is also used in the definition of `record` of and `set of` type construct.
 
-The generated C++ class `Dummy` will have the following member functions:
+The generated {cpp} class `Dummy` will have the following member functions:
 
 .Public member functions of the class `Dummy`
 
@@ -1136,11 +1136,11 @@ boolean operator!=(null_type null_value, const Dummy& other_value);// Not equal
 
 == Compound Data Types
 
-The user-defined compound data types are implemented in C++ classes. These classes are generated by the compiler according to type definitions. In contrast with the basic types, these classes can be found in the generated code.
+The user-defined compound data types are implemented in {cpp} classes. These classes are generated by the compiler according to type definitions. In contrast with the basic types, these classes can be found in the generated code.
 
 === Record and Set Type Constructs
 
-The TTCNâ€“3 type constructs `record` and `set` are mapped in an identical way to C\++. There will be a C++ class for each record type in the generated code. This class builds up the record from its fields.footnote:[This section deals with the record and set types that have at least one field. See <<empty-types, Empty Types>> for the C++ mapping of empty record and set types.] The fields can be either basic or compound types.
+The TTCNâ€“3 type constructs `record` and `set` are mapped in an identical way to C\++. There will be a {cpp} class for each record type in the generated code. This class builds up the record from its fields.footnote:[This section deals with the record and set types that have at least one field. See <<empty-types, Empty Types>> for the {cpp} mapping of empty record and set types.] The fields can be either basic or compound types.
 
 Let us consider the following example type definition. The types `t1` and `t2` can be arbitrary.
 [source]
@@ -1192,7 +1192,7 @@ type record t3 {
 }
 ----
 
-The optional fields are implemented using a C++ template class called `OPTIONAL` that creates an optional value from any type. In the definition of the generated class `t3` the type `t2` will be replaced by `OPTIONAL<t2>` everywhere and anything else will not be changed.
+The optional fields are implemented using a {cpp} template class called `OPTIONAL` that creates an optional value from any type. In the definition of the generated class `t3` the type `t2` will be replaced by `OPTIONAL<t2>` everywhere and anything else will not be changed.
 
 The instantiated template class `OPTIONAL<t2>` will have the following member functions:
 
@@ -1246,7 +1246,7 @@ Using the value of an unbound optional field for anything will also cause dynami
 
 === Union Type Construct
 
-The TTCNâ€“3 type construct union is implemented in a C++ class for each union type in the generated code. This class may contain any, but exactly one of its fields. The fields can be either basic or compound types or even identical types.
+The TTCNâ€“3 type construct union is implemented in a {cpp} class for each union type in the generated code. This class may contain any, but exactly one of its fields. The fields can be either basic or compound types or even identical types.
 
 Let us consider the following example type definition. The types `t1` and `t2` can be arbitrary.
 [source]
@@ -1296,13 +1296,13 @@ Using the value of an unbound `union` variable for anything will cause dynamic t
 
 ==== The anytype
 
-The TTCN-3 anytype is implemented as a C\++ class named anytype. The class is generated only if an actual anytype access is present in the module. It has the same interface as any other C++ class generated for a union, with a few differences:
+The TTCN-3 anytype is implemented as a C\++ class named anytype. The class is generated only if an actual anytype access is present in the module. It has the same interface as any other {cpp} class generated for a union, with a few differences:
 
 If a field is a built-in type or the address type, the name used in `union_selection_type` is the name of the runtime class implementing the type (usually the name of the type in all uppercase).
 
 If a field is a user-defined type, the mapping rules in <<mapping-of-names-and-identifiers, Mapping of Names and Identifiers>> above apply.
 
-The names of field accessor functions are prefixed with AT_. This is necessary, because otherwise the accessor function looks like a constructor to C++.
+The names of field accessor functions are prefixed with AT_. This is necessary, because otherwise the accessor function looks like a constructor to {cpp}.
 
 For example, for the following module
 [source]
@@ -1333,13 +1333,13 @@ CHARSTRING& AT_CHARSTRING();
 
 === Record of Type Construct
 
-The TTCNâ€“3 type construct `record` of makes a variable length sequence from one given type. This construct is implemented as a C++ class.
+The TTCNâ€“3 type construct `record` of makes a variable length sequence from one given type. This construct is implemented as a {cpp} class.
 
 Let us consider the following example type definition. The type t1 can be arbitrary.
 [source, subs=+quotes]
 type record of t1 t2;
 
-This definition will be translated to a C++ class that will be called t2.
+This definition will be translated to a {cpp} class that will be called t2.
 
 There is an `enum` type called `null_type` defined in the Base Library that has only one possible value. NULL_VALUE stands for the empty `"record of"` value, that is, for {}.
 
@@ -1370,9 +1370,9 @@ Class `t2` will have the following public member functions:
 |const t1& operator[](int) const |Gives read-only access to the given element. Index overflow causes dynamic test case error.
 |const t1& opetator[](const INTEGER&) const |
 .4+^.^|_Rotating operators_
-|t2 operator<<=(int) |C++ equivalent of operator <@. (rotate left)
+|t2 operator<<=(int) |{cpp} equivalent of operator <@. (rotate left)
 |t2 operator<<=(const INTEGER&) |
-|t2 operator>>=(int) |C++ equivalent of operator @>. (rotate right)
+|t2 operator>>=(int) |{cpp} equivalent of operator @>. (rotate right)
 |t2 operator>>=(const INTEGER&) |
 ^.^|_Concatenation operator_
 |t2 operator+(const t2&) const |Concatenates two arrays.
@@ -1399,13 +1399,13 @@ boolean operator!=(null_type null_value, const t2& other_value); // Not equal
 
 ==== Pre-generated `record of` and `set of` constructs
 
-The C\++ classes for the `record of` and `set of` constructs of most predefined TTCN-3 types are pre-generated and part of the TITAN runtime. Only a type alias (C++ `typedef`) is generated for instances of these types declared in TTCN-3 and ASN.1 modules. There is a class with regular memory allocation and one with optimized memory allocation pre-generated for each type. These classes are located in the `PreGenRecordOf` namespace.
+The C\++ classes for the `record of` and `set of` constructs of most predefined TTCN-3 types are pre-generated and part of the TITAN runtime. Only a type alias ({cpp} `typedef`) is generated for instances of these types declared in TTCN-3 and ASN.1 modules. There is a class with regular memory allocation and one with optimized memory allocation pre-generated for each type. These classes are located in the `PreGenRecordOf` namespace.
 
 .Pre-generated classes for `record of`/`set of` predefined types
 
 [width="100%",cols="50%,50%",options="header",]
 |====================================================================================================================================
-|C++ class name |Equivalent type in TTCN-3
+|{cpp} class name |Equivalent type in TTCN-3
 |`PREGEN\__RECORD__OF__BOOLEAN` |`record of boolean`
 |`PREGEN\__RECORD__OF__INTEGER` |`record of integer`
 |`PREGEN\__RECORD__OF__FLOAT` |`record of float`
@@ -1446,15 +1446,15 @@ The `set of` construct of TTCNâ€“3 is implemented similarly to `record of`. The
 
 In the internal implementation only the equality operator differs. Unlike in `record of`, it considers the unordered property of the `set of` type construct, that is, it returns `TRUE` if it is able to find exactly one pair for each element.
 
-The index is a unique identifier for a `set of` element because the C++ class does not reorder the elements when a new element is added or an element is modified. The copy constructor also keeps the original order of elements.
+The index is a unique identifier for a `set of` element because the {cpp} class does not reorder the elements when a new element is added or an element is modified. The copy constructor also keeps the original order of elements.
 
 === Enumerated Types
 
-The TTCNâ€“3 `enumerated` type construct is implemented as a C++ class with an embedded enum type.
+The TTCNâ€“3 `enumerated` type construct is implemented as a {cpp} class with an embedded enum type.
 [source, subs="+quotes"]
 type enumerated Day { Monday (1), Tuesday, Wednesday (3) };
 
-The example above will result in the following, very similar C `enum` type definition which is embedded in the C++ class `Day`:
+The example above will result in the following, very similar C `enum` type definition which is embedded in the {cpp} class `Day`:
 [source, subs="+quotes"]
 
 enum enum_type { Monday = 1, Tuesday = 0, Wednesday = 3,
@@ -1462,7 +1462,7 @@ enum enum_type { Monday = 1, Tuesday = 0, Wednesday = 3,
 
 The automatic assignment of numeric values is done according to the standard. Note that there are two extra enumerated values in C, which stand for the unknown and unbound values. They are used in the conversion functions described below. The compiler assigns the smallest two non-negative integer numbers that are not used by the user-defined enumerated values to the unknown and unbound values.
 
-When using the C `enum` type and its values from user code the names must be prefixed with the C++ class name. The `enum` type in the above example can be referenced with `Day::enum_type`, its values can be accessed as `Day::Monday, Day::Tuesday`, and so on.
+When using the C `enum` type and its values from user code the names must be prefixed with the {cpp} class name. The `enum` type in the above example can be referenced with `Day::enum_type`, its values can be accessed as `Day::Monday, Day::Tuesday`, and so on.
 
 The class `Day` will have the following public member functions:
 
@@ -1518,7 +1518,7 @@ The static member function `Day::enum_to_str` converts the given parameter of ty
 
 The function `Day::str_to_enum` does the conversion in the reverse direction. It converts the symbolic enumerated identifier represented by a C character string back to the `Day::enum_type` equivalent. It returns the value `Day::UNKNOWN_VALUE` if the input string is not the equivalent of any of the possible values in the enumerated type. The behavior of this function is undefined if the input parameter does not point to an addressable memory area.
 
-In the above two functions the strings are treated case sensitive and they shall not contain any whitespace or other characters that are not part of the enumerated value. In case of ASN.1 `ENUMERATED` types the strings used by `enum_to_str`, `str_to_enum` and log represent the TTCNâ€“3 view of the enumerated value, that is, the hyphenation characters are mapped to a single underscore character. For example, if an ASN.1 enumerated type has a value with name `my-enum-value` and numeric value 2, the function `enum_to_str` will return the string `"my_enum_value"` if the input parameter equals to 2. Of course, its C++ equivalent will be `my_enum_value` with numeric value 2.
+In the above two functions the strings are treated case sensitive and they shall not contain any whitespace or other characters that are not part of the enumerated value. In case of ASN.1 `ENUMERATED` types the strings used by `enum_to_str`, `str_to_enum` and log represent the TTCNâ€“3 view of the enumerated value, that is, the hyphenation characters are mapped to a single underscore character. For example, if an ASN.1 enumerated type has a value with name `my-enum-value` and numeric value 2, the function `enum_to_str` will return the string `"my_enum_value"` if the input parameter equals to 2. Of course, its {cpp} equivalent will be `my_enum_value` with numeric value 2.
 
 Static member function `Day::is_valid_enum` returns the Boolean value `TRUE` if there is a defined enumerated value having numeric value equal to the `int` parameter and `FALSE` otherwise.
 
@@ -1541,15 +1541,15 @@ Using the value of an unbound enumerated variable for anything will cause dynami
 
 === The `address` Type
 
-The special TTCNâ€“3 data type `address` is represented in C\++ as if it was a regular data type. The name of the equivalent C++ class is `ADDRESS`. If it is an alias to another (either built-in or user-defined) type then a C++ `typedef` is used.
+The special TTCNâ€“3 data type `address` is represented in C\++ as if it was a regular data type. The name of the equivalent {cpp} class is `ADDRESS`. If it is an alias to another (either built-in or user-defined) type then a {cpp} `typedef` is used.
 
 == Predefined Functions
 
-Annex C of link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.05.01_60/es_20187301v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards] and Annex B of link:https://pdfs.semanticscholar.org/33b5/877c85f7fd4f35c7f58c39121358c3652966.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCNâ€“3 European Telecommunications] define a couple of predefined functions. Most of them perform conversion between the built-in types of TTCNâ€“3. In our test executor these functions are implemented in the Base Library in C++ language. They are available not only in TTCNâ€“3 , but they can be called directly from Test Ports as well.
+Annex C of link:https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.05.01_60/es_20187301v040501p.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 1: Core Language European Telecommunications Standards] and Annex B of link:https://pdfs.semanticscholar.org/33b5/877c85f7fd4f35c7f58c39121358c3652966.pdf[Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3. Part 7: Using ASN.1 with TTCNâ€“3 European Telecommunications] define a couple of predefined functions. Most of them perform conversion between the built-in types of TTCNâ€“3. In our test executor these functions are implemented in the Base Library in {cpp} language. They are available not only in TTCNâ€“3 , but they can be called directly from Test Ports as well.
 
 The prototypes for these functions can be found in `*$TTCN3_DIR/include/Addfunc.hh*`, but for easier navigation we list them also in the present document.
 
-The majority of these functions have more than one polymorphic version: when appropriate, one of them takes literal (built-in) C\++ types as arguments instead of the objects of equivalent C++ classes. For instance, if the incoming argument is stored in an `int` variable in your C++ code, you should not construct a temporary object of class `INTEGER` because passing an `int` is faster and produces smaller binary code. Similarly, the returned type is also literal when it is possible.
+The majority of these functions have more than one polymorphic version: when appropriate, one of them takes literal (built-in) C\++ types as arguments instead of the objects of equivalent {cpp} classes. For instance, if the incoming argument is stored in an `int` variable in your {cpp} code, you should not construct a temporary object of class `INTEGER` because passing an `int` is faster and produces smaller binary code. Similarly, the returned type is also literal when it is possible.
 
 === `Integer` to character
 
@@ -1632,14 +1632,14 @@ extern CHARSTRING int2str(const INTEGER& value);
 ----
 === Length of string Type
 
-This function is built into the equivalent C++ classes of all TTCNâ€“3 string types:
+This function is built into the equivalent {cpp} classes of all TTCNâ€“3 string types:
 [source]
 ----
 int <any_string_type>::lengthof() const;
 ----
 === Number of elements in a structured type
 
-This function is built into the C++ template classes of `record of` and `set of` types:
+This function is built into the {cpp} template classes of `record of` and `set of` types:
 [source]
 ----
 int <any_record_of_or_set_of_type>::size_of() const;
@@ -1648,14 +1648,14 @@ This function is currently not implemented for `record` and `set` types.
 
 === The `IsPresent` Function
 
-This function is built into the wrapper C++ template class `OPTIONAL`:
+This function is built into the wrapper {cpp} template class `OPTIONAL`:
 [source]
 ----
 boolean <any_optional_field>::ispresent() const;
 ----
 === The `IsChosen` Function
 
-These functions are built into the equivalent C++ classes of TTCNâ€“3 union types:
+These functions are built into the equivalent {cpp} classes of TTCNâ€“3 union types:
 [source]
 ----
 boolean <union_type>::ischosen(
@@ -1935,6 +1935,6 @@ The class representing the exceptions of a signature (remote procedure) is simil
 |`void log() const` |Puts the contents of the exception into the log.
 |===================================================================================================================================================================================================================================
 
-If an exception type is a user-defined type the field name will be constructed from the C\++ namespace name of the module that the exception type resides in and the name of the C++ class that realizes the exception type. The two identifiers are glued together using a single underscore character. Please note that the namespace name is always present in the identifiers, even if the exception type is defined in the same module as the signature.
+If an exception type is a user-defined type the field name will be constructed from the C\++ namespace name of the module that the exception type resides in and the name of the {cpp} class that realizes the exception type. The two identifiers are glued together using a single underscore character. Please note that the namespace name is always present in the identifiers, even if the exception type is defined in the same module as the signature.
 
 For example, if exception type `My_Record` is defined in module `My_Module` the respective field access functions will be named as `My\__Module_My__Record_field` and the associated enum value will be `MyProc_exception::ALT_My__Module_My__Record`.
diff --git a/usrguide/apiguide/6-tips_&_troubleshooting.adoc b/usrguide/apiguide/6-tips_&_troubleshooting.adoc
index 4fda65ec898667e6a64e36f2cefc0538e12d63c4..47c4106ab608474957b618f81b8ca1d3a6d1eda4 100644
--- a/usrguide/apiguide/6-tips_&_troubleshooting.adoc
+++ b/usrguide/apiguide/6-tips_&_troubleshooting.adoc
@@ -5,34 +5,34 @@
 Information not fitting in any of the previous chapters is given in this chapter.
 
 [[migrating-existing-c-code-to-the-naming-rules-of-version-1-7]]
-== Migrating Existing C++ Code to the Naming Rules of Version 1.7
+== Migrating Existing {cpp} Code to the Naming Rules of Version 1.7
 
-When using the new naming rulesfootnote:[The new naming rules are used by default; the naming rules can be changed using the compiler command line switch -N.] the compiler generates a C\++ namespace for each TTCNâ€“3 and ASN.1 module. The name of the namespace corresponds to the module. The generated C++ entities of a module are all placed in its namespace; therefore all the test port or protocol module code must use these namespaces.
+When using the new naming rulesfootnote:[The new naming rules are used by default; the naming rules can be changed using the compiler command line switch -N.] the compiler generates a C\++ namespace for each TTCNâ€“3 and ASN.1 module. The name of the namespace corresponds to the module. The generated {cpp} entities of a module are all placed in its namespace; therefore all the test port or protocol module code must use these namespaces.
 
-Rules to follow when writing C++ code:
+Rules to follow when writing {cpp} code:
 
-* When referencing an entity located in a different module its C++ name has to be prefixed with the namespace name of that module.
+* When referencing an entity located in a different module its {cpp} name has to be prefixed with the namespace name of that module.
 
 * A test port class must be placed into the namespace of its module.
 
 * Encoding and decoding functions must be placed into the namespace of the TTCNâ€“3 module in which the external function was defined.
 
-* All C\++ entities have to be placed into namespace. An exception to this may be C++ entities used only locally; these are defined with the keyword `static`.
+* All C\++ entities have to be placed into namespace. An exception to this may be {cpp} entities used only locally; these are defined with the keyword `static`.
 
-* For convenience the `using namespace` directive can be used in C++ source files. It is forbidden to use this directive in header files!
+* For convenience the `using namespace` directive can be used in {cpp} source files. It is forbidden to use this directive in header files!
 
-* C++ enum types are placed in the scope of their value class; enum types have to be prefixed by the C++ name of the value class.footnote:[The enum hack option has become obsolete with the new naming rules.]
+* {cpp} enum types are placed in the scope of their value class; enum types have to be prefixed by the {cpp} name of the value class.footnote:[The enum hack option has become obsolete with the new naming rules.]
 
 [[using-external-c-functions-in-ttcn-3-test-suites]]
-== Using External C++ Functions in TTCNâ€“3 Test Suites
+== Using External {cpp} Functions in TTCNâ€“3 Test Suites
 
-Sometimes standard library functionsfootnote:[C language functions cannot be called directly from TTCNâ€“3; you need at least a wrapper function for them.] are called in the test suite or there is a need for efficiently implemented "bit-crunching" functions in the TTCNâ€“3 ATS. In these cases functions to be called from the test suite can be developed in C++.
+Sometimes standard library functionsfootnote:[C language functions cannot be called directly from TTCNâ€“3; you need at least a wrapper function for them.] are called in the test suite or there is a need for efficiently implemented "bit-crunching" functions in the TTCNâ€“3 ATS. In these cases functions to be called from the test suite can be developed in {cpp}.
 
-There are the standard library functions as well as other libraries in the C++ functions. The logging and error handling facilities of the run-time environment are also available as in case of Test Ports.
+There are the standard library functions as well as other libraries in the {cpp} functions. The logging and error handling facilities of the run-time environment are also available as in case of Test Ports.
 
-Since version 1.4.pl1 the semantic analyzer of the compiler checks the import statements thoroughly. Therefore one cannot use the virtual C++ modules as before: C++ functions must be defined as external functions to be accessible from TTCNâ€“3 modules.
+Since version 1.4.pl1 the semantic analyzer of the compiler checks the import statements thoroughly. Therefore one cannot use the virtual {cpp} modules as before: {cpp} functions must be defined as external functions to be accessible from TTCNâ€“3 modules.
 
-For example, the following definitions make two C++ functions accessible from TTCNâ€“3 module `MyModule` and from any other module that imports `MyModule`.
+For example, the following definitions make two {cpp} functions accessible from TTCNâ€“3 module `MyModule` and from any other module that imports `MyModule`.
 
 [[example-ttcn-3-module-mymodule-ttcn]]
 === Example TTCNâ€“3 Module (MyModule.ttcn)
@@ -49,7 +49,7 @@ module MyModule {
 }
 ----
 
-The compiler will translate those external function definitions to C++ function prototypes in the generated header file `MyModule.hh`:
+The compiler will translate those external function definitions to {cpp} function prototypes in the generated header file `MyModule.hh`:
 
 [source]
 ----
@@ -59,17 +59,17 @@ The compiler will translate those external function definitions to C++ function
 [...]
 ----
 
-Both pre-defined and user-defined TTCNâ€“3 data types can be used as parameters and/or return types of the C\++ functions. The detailed description of the equivalent C++ classes as well as the name mapping rules are described in chapter <<4-encoding_and_decoding.adoc#xml-encoding-xer,XML Encoding (XER)>>.
+Both pre-defined and user-defined TTCNâ€“3 data types can be used as parameters and/or return types of the C\++ functions. The detailed description of the equivalent {cpp} classes as well as the name mapping rules are described in chapter <<4-encoding_and_decoding.adoc#xml-encoding-xer,XML Encoding (XER)>>.
 
 Using templates as formal parameters in external functions is possible, but not recommended because the API of the classes realizing templates is not documented and subject to change without notice.
 
-The formal parameters of external TTCNâ€“3 functions are mapped to C++ function parameters according to the following table:
+The formal parameters of external TTCNâ€“3 functions are mapped to {cpp} function parameters according to the following table:
 
-.TTCNâ€“3 formal parameters and their C++ equivalents
+.TTCNâ€“3 formal parameters and their {cpp} equivalents
 
 [cols=",",options="header",]
 |==============================================
-|TTCNâ€“3 formal parameter |Its C++ equivalent
+|TTCNâ€“3 formal parameter |Its {cpp} equivalent
 |`[in] MyType myPar` |`const MyType& myPar`
 |`out MyType myPar` |`MyType& myPar`
 |`inout MyType myPar` |`MyType& myPar`
@@ -78,11 +78,11 @@ The formal parameters of external TTCNâ€“3 functions are mapped to C++ function
 
 NOTE: In versions 1.6.pl3 and earlier the in keyword had an extra meaning in formal parameter lists. According to the TTCNâ€“3 standard the parameter definitions `MyType myPar` and in `MyType myPar` are totally equivalent, but the earlier versions of the compiler distinguished them. Unless the keyword `in` was present the compiler passed the parameter by value (involving a copy constructor call) instead of using a const reference. That is why it was recommended to use an explicit in keyword in parameter lists of external functions.
 
-Due to the strictness of the TTCNâ€“3 semantic analyzer one cannot use C/C++ data types with external functions as formal parameters or return types, only TTCNâ€“3 and ASN.1 data types are allowed. Similarly, one cannot use pointers as parameters or return values because they have no equivalents in TTCNâ€“3 .
+Due to the strictness of the TTCNâ€“3 semantic analyzer one cannot use C/{cpp} data types with external functions as formal parameters or return types, only TTCNâ€“3 and ASN.1 data types are allowed. Similarly, one cannot use pointers as parameters or return values because they have no equivalents in TTCNâ€“3 .
 
-The external functions can be implemented in one or more C\++ source files. The generated header file that contains the prototypes of the external functions shall be included into each C++ source file. This file makes accessible all built-in data types, the user-defined types of the corresponding TTCNâ€“3 module and all available services of the run-time environment (logging, error handling, etc.).
+The external functions can be implemented in one or more C\++ source files. The generated header file that contains the prototypes of the external functions shall be included into each {cpp} source file. This file makes accessible all built-in data types, the user-defined types of the corresponding TTCNâ€“3 module and all available services of the run-time environment (logging, error handling, etc.).
 
-The name, return type and the parameters of the implemented C++ functions must match exactly the generated function prototypes or the compilation will fail. The generated function prototype is in the namespace of the module, therefore the implementation of the function has to be placed in that namespace, too.
+The name, return type and the parameters of the implemented {cpp} functions must match exactly the generated function prototypes or the compilation will fail. The generated function prototype is in the namespace of the module, therefore the implementation of the function has to be placed in that namespace, too.
 [[logging-in-test-ports-or-external-functions]]
 == Logging in Test Ports or External Functions
 
@@ -168,7 +168,7 @@ static void TTCN_Logger::OS_error();
 
 ==== log
 
-The C++ classes of predefined and compound data types are equipped with a member function called `log`. This function puts the actual value of the variable at the end of current buffer. Unbound variables and fields are denoted by the symbol `<unbound>`. The contents of TTCNâ€“3 value objects can be logged only in buffered mode.
+The {cpp} classes of predefined and compound data types are equipped with a member function called `log`. This function puts the actual value of the variable at the end of current buffer. Unbound variables and fields are denoted by the symbol `<unbound>`. The contents of TTCNâ€“3 value objects can be logged only in buffered mode.
 [source, subs="+quotes"]
 void <any TTCN-3 type>::log() const;
 
@@ -201,7 +201,7 @@ Differences between the formats:
 
 The "-" symbol is the NotUsedSymbol which can be used inside compound values, but when logging an unbound value which is not inside a record or record of the TTCN-3 output format of the logger is actually not a legal TTCN-3 value/template because a value or template cannot be set to be unbound. Thus this output format can be copy-pasted from a log file into a ttcn-3 file or to a module parameter value in a configuration file only if it semantically makes sense.
 
-The C++ API extensions to change the logging format: +
+The {cpp} API extensions to change the logging format: +
 A new enum type for the format in TTCN_Logger class:+
 `enum data_log_format_t { LF_LEGACY, LF_TTCN }`; +
 Static functions to get/set the format globally: +
@@ -238,7 +238,7 @@ The above code fragment will produce three lines in the log in the following ord
 `second message`
 `first message`
 
-If the code calls a C++ function that might throw an exception while the logger has an active event buffer care must be taken that event is properly finished during stack unwinding. Otherwise the stack of the logger and the call stack of the program will get out of sync. The following example illustrates the proper usage of buffered mode with exceptions:
+If the code calls a {cpp} function that might throw an exception while the logger has an active event buffer care must be taken that event is properly finished during stack unwinding. Otherwise the stack of the logger and the call stack of the program will get out of sync. The following example illustrates the proper usage of buffered mode with exceptions:
 [source]
 ----
 TTCN_Logger::begin_event(TTCN_DEBUG);
@@ -261,7 +261,7 @@ If a fatal error is encountered in the Test Port, you should call the function `
 [source, subs="+quotes"]
 void TTCN_error(const char *fmt, â€¦);
 
-The parameter `fmt` contains the reason of the error in a NUL terminated character string in the format of a `printf` format string. If necessary, additional values should be passed to `TTCN_error` as specified in the format string. The error handling in the executable test program is implemented using C++ exceptions so the function `TTCN_error` never returns; instead, it throws an exception. The exception value contains an instance of the empty class called `TC_Error`. This exception is normally caught at the end of each test case and module control part. After logging the reason `TTCN_Logger::OS error()` is called. Finally, the verdict is set to error and the test executor performs an error recovery, so it continues the execution with the next test case.
+The parameter `fmt` contains the reason of the error in a NUL terminated character string in the format of a `printf` format string. If necessary, additional values should be passed to `TTCN_error` as specified in the format string. The error handling in the executable test program is implemented using {cpp} exceptions so the function `TTCN_error` never returns; instead, it throws an exception. The exception value contains an instance of the empty class called `TC_Error`. This exception is normally caught at the end of each test case and module control part. After logging the reason `TTCN_Logger::OS error()` is called. Finally, the verdict is set to error and the test executor performs an error recovery, so it continues the execution with the next test case.
 
 It is not recommended to use own error recovery combined with the default method (that is, catching this exception).
 
@@ -271,11 +271,11 @@ The UNIX signals may interrupt the normal execution of programs. This may happen
 
 In the executable test program there are system calls not only in the Base Library, but in Test Ports as well. Since the other Test Ports that you are using may have been written by many developers, one cannot be sure that they are prepared to the effects of signals. So it is recommended to avoid using signals in Test Ports.
 
-== Mixing C and C++ Modules
+== Mixing C and {cpp} Modules
 
-Modules written in C language may be used in the Test Ports. In this case the C header files must be included into the Test Port source code and the object files of the C module must be linked to the executable. Using a C compiler to compile the C modules may lead to errors when linking the modules together. This is because the C and C\++ compilers use different rules for mapping function names to symbol names of the object file to avoid name clashes caused by the C++ polymorphism. There are two possible solutions to solve this problem:
+Modules written in C language may be used in the Test Ports. In this case the C header files must be included into the Test Port source code and the object files of the C module must be linked to the executable. Using a C compiler to compile the C modules may lead to errors when linking the modules together. This is because the C and C\++ compilers use different rules for mapping function names to symbol names of the object file to avoid name clashes caused by the {cpp} polymorphism. There are two possible solutions to solve this problem:
 
-1.  Use the same C++ compiler to compile all of your source code (including C modules).
+1.  Use the same {cpp} compiler to compile all of your source code (including C modules).
 2.  If the first one is impossible (when using a third party software that is available in binary format only), the definitions of the C header file must be put into an `extern "C"` block like this.
 [source]
 ----
@@ -290,4 +290,4 @@ extern "C" {
 #endif
 ----
 
-The latter solution does not work with all C\++ compilers; it was tested on GNU C++ compiler only.
+The latter solution does not work with all C\++ compilers; it was tested on GNU {cpp} compiler only.
diff --git a/usrguide/apiguide/README.adoc b/usrguide/apiguide/README.adoc
index 4a9454f4a040c6f809f4c5e00551d7577d1e9858..eddf5057c8fe672f1d06cf91e88f97db33c7bd50 100644
--- a/usrguide/apiguide/README.adoc
+++ b/usrguide/apiguide/README.adoc
@@ -20,7 +20,7 @@ endif::[]
 
 *Abstract*
 
-This document describes detailed information on the TITAN Application Programming Interface (API) on C++ level, advanced TTCNâ€“3 programming, and background information on the TITAN TTCNâ€“3 Test Executor project.
+This document describes detailed information on the TITAN Application Programming Interface (API) on {cpp} level, advanced TTCNâ€“3 programming, and background information on the TITAN TTCNâ€“3 Test Executor project.
 
 *Copyright*
 
@@ -39,7 +39,7 @@ ifdef::env-github,backend-html5[]
 * link:2-test_ports.adoc[Test Ports]
 * link:3-logger_plug-ins.adoc[Logger Plug-ins]
 * link:4-encoding_and_decoding.adoc[Encoding and Decoding]
-* link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCNâ€“3 Data Types to C++ Constructs]
+* link:5-mapping_ttcn3_data_types_to_c+\+_constructs.adoc[Mapping TTCNâ€“3 Data Types to {cpp} Constructs]
 * link:6-tips_&_troubleshooting.adoc[Tips & Troubleshooting]
 * link:7-references.adoc[References]
 * link:8-abbreviations.adoc[Abbreviations]
diff --git a/usrguide/installationguide/installationguide.adoc b/usrguide/installationguide/installationguide.adoc
index ed0b2edef5707855519511fdd535cab377fd9ab8..057c4ae5d2aebd380909cdc060459cc89fa7dccb 100644
--- a/usrguide/installationguide/installationguide.adoc
+++ b/usrguide/installationguide/installationguide.adoc
@@ -149,11 +149,11 @@ Download the Titan package for your platform, OS and GCC version from the provid
 
 * For users outside Ericsson: https://projects.eclipse.org/projects/tools.titan/downloads. This version is licensed under the Eclipse Public License.
 
-A binary distribution, suitable for the used operating system (Solaris, Linux, FreeBSD), and for a C++ compiler, in a tar-gzip archive will be received. For Windowsfootnote:[For using TITAN on Windows platforms, installing the Cygwin programming environment is required see chapter 1.5 Installing Prerequisites on Cygwin (on Windows)] users there is no pre-built version, but compiling the open-source version is possible.
+A binary distribution, suitable for the used operating system (Solaris, Linux, FreeBSD), and for a {cpp} compiler, in a tar-gzip archive will be received. For Windowsfootnote:[For using TITAN on Windows platforms, installing the Cygwin programming environment is required see chapter 1.5 Installing Prerequisites on Cygwin (on Windows)] users there is no pre-built version, but compiling the open-source version is possible.
 
-WARNING: the version of C++ compiler used is important. If the version difference between the systemâ€™s compiler and the compiler that the basic TTCNâ€“3 library was built with is large enough, the linking of executable test suites will fail with strange error messages. The reason is the different mapping of C++ class and (polymorphic) member function names into linker symbols. For example, this problem persists between versions 2.8.x and 2.95.x of GCC. Different C++ compilers (e.g.Â Sun Workshop and GCC) are, of course, totally incompatible. The solution for this problem is to use nearly the same version of the C++ compiler as the binary package was built with.
+WARNING: the version of {cpp} compiler used is important. If the version difference between the systemâ€™s compiler and the compiler that the basic TTCNâ€“3 library was built with is large enough, the linking of executable test suites will fail with strange error messages. The reason is the different mapping of {cpp} class and (polymorphic) member function names into linker symbols. For example, this problem persists between versions 2.8.x and 2.95.x of GCC. Different {cpp} compilers (e.g.Â Sun Workshop and GCC) are, of course, totally incompatible. The solution for this problem is to use nearly the same version of the {cpp} compiler as the binary package was built with.
 
-Binaries for other operating systems or C++ compilers are available only on request.
+Binaries for other operating systems or {cpp} compilers are available only on request.
 
 == Installing the Package
 
@@ -169,16 +169,16 @@ or +
 The following sub-directories are created:
 
 * `bin` contains the executable programs: The Compiler, the Makefile Generator, the Main Controller for parallel test execution and two log formatter utilities.
-* `etc` contains a demo license key, which enables to use the parser parts of the Compiler by any user on any host, that is, without C++ code generation. The installation can be tested with this demo key until the personalized license key is received.
-* `include` contains the C+/+ header files needed to compile the generated C++ code.
-* `lib` contains the pre-compiled Base Library for use with the generated C++ code both for single and parallel mode in static and dynamic linkingfootnote:[Note that not all platforms support dynamic linking.] formats.
+* `etc` contains a demo license key, which enables to use the parser parts of the Compiler by any user on any host, that is, without {cpp} code generation. The installation can be tested with this demo key until the personalized license key is received.
+* `include` contains the C+/+ header files needed to compile the generated {cpp} code.
+* `lib` contains the pre-compiled Base Library for use with the generated {cpp} code both for single and parallel mode in static and dynamic linkingfootnote:[Note that not all platforms support dynamic linking.] formats.
 * `man` contains UNIX manual pages (for the Compiler and the Makefile Generator).
 * `demo` contains a simple TTCNâ€“3 test suite ("Hello, world!") together with a sample test port and a compiled executable.
 * `doc` contains this documentation in PostScript and PDF formats.
 
 To complete the TITAN TTCNâ€“3 Test Executor installation, some environmental variables should be set and the login script should be modified.
 
-NOTE: The C++ source code generated by this version (patch level) of Compiler is not compatible with older versions of TTCNâ€“3 Base Library and vice versa.footnote:[Sometimes even the linking fails; but a successful linking does not mean that everything is correct at all.]If upgrading TITAN from an older version, all modules of existing test suites must be re-translated with the new compiler in order to make them running with the new libraries.
+NOTE: The {cpp} source code generated by this version (patch level) of Compiler is not compatible with older versions of TTCNâ€“3 Base Library and vice versa.footnote:[Sometimes even the linking fails; but a successful linking does not mean that everything is correct at all.]If upgrading TITAN from an older version, all modules of existing test suites must be re-translated with the new compiler in order to make them running with the new libraries.
 
 It is recommended to make a backup copy of the older version of the distribution. There are some minor incompatibilities in the compilerâ€™s grammar that may cause many syntax errors in TTCNâ€“3 modules that were translated correctly with earlier versions.
 
@@ -195,8 +195,8 @@ Currently it is experimental to use TITAN with clang on Ubuntu operating system.
 
 There are some important notes about using clang with TITAN:
 
-* The C++ source code generated and TITAN must be compiled with the same version of clang. See section 2.2 note.
-* Makefiles of TTCN-3 projects must be modified by hand(replace *CXX = g++* with *CXX = clang++3.8*). Or regenerated using *makefilegen*, to use clang compiler. TITANâ€™s *makefilegen* can detect if it was compiled with clang and will generate makefiles with clang as default C++ compiler.
+* The {cpp} source code generated and TITAN must be compiled with the same version of clang. See section 2.2 note.
+* Makefiles of TTCN-3 projects must be modified by hand(replace *CXX = g++* with *CXX = clang++3.8*). Or regenerated using *makefilegen*, to use clang compiler. TITANâ€™s *makefilegen* can detect if it was compiled with clang and will generate makefiles with clang as default {cpp} compiler.
 * Required clang version is *3.8*.
 
 = Building Titan from source code
diff --git a/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
index 5be86a222180871ebd67d95da0a06333b893ee7d..680872f2da8c2e27d25e8c3ba8d22e929174e560 100644
--- a/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
+++ b/usrguide/referenceguide/10-code_coverage_of_ttcn-3_modules.adoc
@@ -2,7 +2,7 @@
 
 Note: the feature described here is deprecated; please use instead the coverage tool described in <<4-ttcn3_language_extensions.adoc#profiling-and-code-coverage, Profiling and code coverage>>.
 
-The TTCN-3 compiler is able to instrument the generated C/C++ code for a set of TTCN-3 modules (= or files) to generate code coverage information during runtime. To enable this feature the `-K file` option needs to be used. For convenience this option is available for `ttcn3_makefilegen` as well. Itâ€™s possible to generate code coverage information only for a given set of TTCN-3 modules listed on the command line. In that case the set of files in `file` needs to be a subset of the files listed on the command line. If `file` contains a file which is not listed on the command line an error will be issued.
+The TTCN-3 compiler is able to instrument the generated C/{cpp} code for a set of TTCN-3 modules (= or files) to generate code coverage information during runtime. To enable this feature the `-K file` option needs to be used. For convenience this option is available for `ttcn3_makefilegen` as well. Itâ€™s possible to generate code coverage information only for a given set of TTCN-3 modules listed on the command line. In that case the set of files in `file` needs to be a subset of the files listed on the command line. If `file` contains a file which is not listed on the command line an error will be issued.
 
 == Generating Code Coverage
 
diff --git a/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
index 8929682a13fb668645a5b5ef5197b92fa3231630..b45bdf293b67bca9fc62c9c6c88eb7b328b89036 100644
--- a/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
+++ b/usrguide/referenceguide/11-the_ttcn-3_debugger.adoc
@@ -4,7 +4,7 @@
 
 The TTCN-3 debugger is a feature in TITAN, which allows the user to pause (halt) the execution of a TTCN-3 program and print (or in some cases overwrite) information about the current state of the program.
 
-The compiler option `â€“n` activates the debugger and augments the generated C++ code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
+The compiler option `â€“n` activates the debugger and augments the generated {cpp} code to store debug information and to allow the addition of breakpoints at runtime. For convenience this option is available for `ttcn3_makefilegen` as well.
 
 == Gathered information
 
diff --git a/usrguide/referenceguide/12-tips_&_troubleshooting.adoc b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
index bc3463da85d57d9129a6d4bebd17d5f306581124..d17eada4f9b5d55d390862d6864b3e918ebc5fa0 100644
--- a/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
+++ b/usrguide/referenceguide/12-tips_&_troubleshooting.adoc
@@ -13,7 +13,7 @@ The type aliasing is implemented in the test executor, but it translates this TT
 
 `typedef MyType MyAlternativeName;`
 
-The limitation of the C typedef is that the C\++ compiler cannot distinguish between the original and alias name in polymorphism (i.e.Â the identically named functions with parameter type `MyType` and `MyAlternativeName` are treated as same). That is, if you define a port type that allows the sending or receiving both of the original and aliased type, the generated C++ code cannot be compiled because the Test Port class contains two identical send/receive function.
+The limitation of the C typedef is that the C\++ compiler cannot distinguish between the original and alias name in polymorphism (i.e.Â the identically named functions with parameter type `MyType` and `MyAlternativeName` are treated as same). That is, if you define a port type that allows the sending or receiving both of the original and aliased type, the generated {cpp} code cannot be compiled because the Test Port class contains two identical send/receive function.
 
 As a work-around to this problem you can repeat the definition of the original type using the alternative name instead of type aliasing. In this case two differently named, but identical classes will be generated and the polymorphism problem will not occur.
 
@@ -42,7 +42,7 @@ NOTE: This feature, as preprocessors in general, should be avoided if not absolu
 
 Tips for the `Makefile` generated using the option `-p:`
 
-* All the options for the C precompiler can be specified using the variable `CPPFLAGS_TTCN3`. Do not confuse it with the variable `CPPFLAGS`, which is used on the generated C++ code. If standard TTCN-3 output is needed the flag `-P` has to be added manually to the variable `CPPFLAGS_TTCN3`. The resulting `ttcn` files can be compiled with any TTCN-3 compiler (if other special language extensions are not used). Globally used preprocessor symbols can be defined here with the option `-D`. For example to compile the debug version of a project a `DEBUG` symbol can be specified with `-DDEBUG`.
+* All the options for the C precompiler can be specified using the variable `CPPFLAGS_TTCN3`. Do not confuse it with the variable `CPPFLAGS`, which is used on the generated {cpp} code. If standard TTCN-3 output is needed the flag `-P` has to be added manually to the variable `CPPFLAGS_TTCN3`. The resulting `ttcn` files can be compiled with any TTCN-3 compiler (if other special language extensions are not used). Globally used preprocessor symbols can be defined here with the option `-D`. For example to compile the debug version of a project a `DEBUG` symbol can be specified with `-DDEBUG`.
 
 * Files which are included in the `.ttcnpp` source files (with `#include`) and do not need to be translated can be specified in the `TTCN3_INCLUDES` variable. These files will be checked for modification when the `.ttcnpp` files are processed by `make`; any modification will trigger preprocessing of all the `.ttcnpp` files and the recompilation of the affected modules. If the suffix of a file is `.ttcnin` the Makefile Generator will add it to `TTCN3_INCLUDES`; in all other cases the file has to be added manually.
 
@@ -251,9 +251,9 @@ with { extension "prototype (convert) decode(XER:XER_EXTENDED)" }
 }
 ----
 
-The "prototype (convert)" attribute instructs the compiler to generate a C++ implementation for each of the external functions (see section 4.22.4 above). This permits the use of the encoding/decoding functions directly from TTCN-3 code.
+The "prototype (convert)" attribute instructs the compiler to generate a {cpp} implementation for each of the external functions (see section 4.22.4 above). This permits the use of the encoding/decoding functions directly from TTCN-3 code.
 
-In case more sophisticated processing is required (or some form of pre/postprocessing), the encoder/decoder functions can be reimplemented in C++. The basic functionality provided by the compiler can be used as a starting point.
+In case more sophisticated processing is required (or some form of pre/postprocessing), the encoder/decoder functions can be reimplemented in {cpp}. The basic functionality provided by the compiler can be used as a starting point.
 
 NOTE: In this case all the ``with'' attributes in the example above must be removed from the external function declaration (otherwise the compiler will generate the functions again with the same signature and duplicate symbol errors will appear at link time).
 
diff --git a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
index 1b1299654ab1b77cbdb308794574e5fb4723bf41..b05d298619e743e362186f025cc33c304f36da45 100644
--- a/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
+++ b/usrguide/referenceguide/2-ttcn-3_limitations_in_this_version.adoc
@@ -3,7 +3,7 @@
 
 The present Test Executor is an implementation of TTCNâ€“3 Core Language standard (<<13-references.adoc#_1, [1]>>) with support of ASN.1 (<<13-references.adoc#_3, [3]>>). However, the following TTCNâ€“3 language constructs are not supported in the current version of the Test Executor. When applicable, the relevant clause of the standard text (<<13-references.adoc#_1, [1]>>) is given within parentheses after each limitation. The list of ASN.1 related limitations can be found in chapter *4.25*.
 
-* C++ code generation for parameterized local templates is not supported.footnote:[The semantic analyzer is able to verify modules with such definitions, but the generated C++ code will be incomplete or erroneous.] (5.0, relevant cells of Table 1)
+* {cpp} code generation for parameterized local templates is not supported.footnote:[The semantic analyzer is able to verify modules with such definitions, but the generated {cpp} code will be incomplete or erroneous.] (5.0, relevant cells of Table 1)
 * Parameterized TTCNâ€“3 `record`, `set` and `union types`. (5.4 in <<13-references.adoc#_1, [1]>>))
 * TTCNâ€“3 sub-typing constraints are checked only at compilation time. In the run-time environment the restricted types are substituted with the corresponding base type and no run-time error is produced if the assigned value violates the subtype constraint.
 * The special TTCNâ€“3 type `anytype` is supported with restrictions. (6.2.6 in <<13-references.adoc#_1, [1]>>)
diff --git a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
index fcd57454e84602839bbdb3ce34c19e2b3f91da5e..cb70b5b02a5ac72c8376b73c65c0bdf2e56b06c0 100644
--- a/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
+++ b/usrguide/referenceguide/4-ttcn3_language_extensions.adoc
@@ -11,7 +11,7 @@ The compiler does not report an error or warning if the semi-colon is missing at
 
 The statement block is optional after the guard operations of `altsteps`, `alt` and `interleave` constructs and in the response and exception handling part of `call` statements. A missing statement block has the same meaning as an empty statement block. If the statement block is omitted, a terminating semi-colon must be present after the guard statement.
 
-The standard escape sequences of C/C++ programming languages are recognized and accepted in TTCNâ€“3 character string values, that is, in literal values of `charstring` and `universal` `charstring` types, as well as in the arguments of built-in operations `log()` and `action()`.
+The standard escape sequences of C/{cpp} programming languages are recognized and accepted in TTCNâ€“3 character string values, that is, in literal values of `charstring` and `universal` `charstring` types, as well as in the arguments of built-in operations `log()` and `action()`.
 
 NOTE: As a consequence of the extended escape sequences and in contrast with the TTCNâ€“3 standard, the backslash character itself has to be always duplicated within character string values.
 
@@ -205,9 +205,9 @@ Types imported from another module (elsewhere) can be added to the anytype of th
 
 == Ports and Test Configurations
 
-If all instances of a TTCNâ€“3 port type are intended to be used for internal communication only (i.e.Â between two TTCNâ€“3 test components) the generation and linking of an empty Test Port skeleton can be avoided. If the attribute `with { extension "internal" }` is appended to the port type definition, all C++ code that is needed for this port will be included in the output modules.<<13-references.adoc#_9, [9]>>
+If all instances of a TTCNâ€“3 port type are intended to be used for internal communication only (i.e.Â between two TTCNâ€“3 test components) the generation and linking of an empty Test Port skeleton can be avoided. If the attribute `with { extension "internal" }` is appended to the port type definition, all {cpp} code that is needed for this port will be included in the output modules.<<13-references.adoc#_9, [9]>>
 
-If the user wants to use `address` values in `to` and `from` clause and sender redirect of TTCNâ€“3 port operations the `with { extension "address" }` attribute shall be used in the corresponding port type definition(s) to generate proper C++ code.
+If the user wants to use `address` values in `to` and `from` clause and sender redirect of TTCNâ€“3 port operations the `with { extension "address" }` attribute shall be used in the corresponding port type definition(s) to generate proper {cpp} code.
 
 NOTE: When address is used in port operations the corresponding port must have an active mapping to a port of the test system interface, otherwise the operation will fail at runtime. Using of address values in to and from clauses implicitly means system as component reference. (See section "Support of address type" in <<13-references.adoc#_16, [16]>> for more details).<<13-references.adoc#_10, [10]>>
 
@@ -268,7 +268,7 @@ The compiler realizes TTCNâ€“3 `interleave` statements using a different approac
 
 * Loop constructs `for`, `while` and `do-while` loops are accepted and supported without any restriction in `interleave` statements. The transformation of statements is done in a lower level than the TTCNâ€“3 language, which does not restrict the embedded loops.
 * Statements `activate`, `deactivate` and `stop` can also be used within `interleave`. The execution of these statements is atomic so we did not see the reason why the standard forbids them.
-* The size of our generated code is linear in contrast to the exponential code growth of the canonical algorithm. In other words, the C++ equivalent of every embedded statement appears exactly once in the output.
+* The size of our generated code is linear in contrast to the exponential code growth of the canonical algorithm. In other words, the {cpp} equivalent of every embedded statement appears exactly once in the output.
 * The run-time realization does not require any extra operating system resources, such as multi-threading.
 
 == Logging Disambiguation
@@ -1129,7 +1129,7 @@ All component types are compatible with each empty component type. Empty compone
 
 == Implicit Message Encoding
 
-The TTCNâ€“3 standard <<13-references.adoc#_1, [1]>> does not specify a standard way of data encoding/decoding. TITAN has a common C\++ API for encoding/decoding; to use this API external functions are usually needed. The common solution is to define a TTCNâ€“3 external function and write the C++ code containing the API calls. In most cases the C++ code explicitly written to an auxiliary C++ file contains only simple code patterns which call the encoding/decoding API functions on the specified data. In TITAN there is a TTCNâ€“3 language extension which automatically generates such external functions.
+The TTCNâ€“3 standard <<13-references.adoc#_1, [1]>> does not specify a standard way of data encoding/decoding. TITAN has a common C\++ API for encoding/decoding; to use this API external functions are usually needed. The common solution is to define a TTCNâ€“3 external function and write the {cpp} code containing the API calls. In most cases the {cpp} code explicitly written to an auxiliary {cpp} file contains only simple code patterns which call the encoding/decoding API functions on the specified data. In TITAN there is a TTCNâ€“3 language extension which automatically generates such external functions.
 
 Based on this automatic encoding/decoding mechanism, dual-faced ports are introduced. Dual-faced ports have an external and an internal interface and can automatically transform messages passed through them based on mapping rules defined in TTCNâ€“3 source files. These dual-faced ports eliminate the need for simple port mapping components and thus simplify the test configuration.
 
@@ -1175,7 +1175,7 @@ The following transformation rules may apply to the automatic conversion between
 * No conversion. Applicable to any message type, this is a type preserving mapping, no value conversion is performed. Source and target types must be identical. This mapping does not have any options. For example, control or status indication massages may transparently be conveyed between the external and the internal interfaces. Keyword used in attribute `user` of port type definition: `simple`.
 * Message discarding. This rule means that messages of the given source type will not be forwarded to the opposite interface. Thus, there is no destination type, which must be indicated by the not used symbol (-). This mapping does not have any options. For example, incoming status indication massages of the external interface may be omitted on the internal interface. Keyword used in attribute `user` of port type definition: `discard`.
 * Conversion using the built-in codecs. Here, a corresponding encoding or decoding subroutine of the built-in codecs (for example RAW, TEXT or BER) is invoked. The conversion and error handling options are specified with the same syntax as used for the encoding/decoding functions, see section <<attribute-syntax, Attribute Syntax>>. Here, source type corresponds to input type and target type corresponds to output type of the encoding. Keyword used in attribute `user` of port type definition: `encode` or `decode`; either followed by an optional `errorbehavior`.
-* Function or external function. The transformation rule may be described by an (external) function referenced by the mapping. The function must have the attribute `extension` specifying one of the prototypes given in section <<encoder-decoder-function-prototypes, Encoder/decoder Function Prototypes>>. The incoming and the outgoing type of the function must be equal to the source and target type of the mapping, respectively. The function may be written in TTCN-3, C++ or generated automatically by the compiler. This mapping does not have any options. Keyword used in attribute `user` of port type definition: `function`.
+* Function or external function. The transformation rule may be described by an (external) function referenced by the mapping. The function must have the attribute `extension` specifying one of the prototypes given in section <<encoder-decoder-function-prototypes, Encoder/decoder Function Prototypes>>. The incoming and the outgoing type of the function must be equal to the source and target type of the mapping, respectively. The function may be written in TTCN-3, {cpp} or generated automatically by the compiler. This mapping does not have any options. Keyword used in attribute `user` of port type definition: `function`.
 
 ==== Mapping with One Target
 
@@ -1284,7 +1284,7 @@ The first portion of the input data received in the parameter `param_1` of type
 [[automatic-generation-of-encoder-decoder-functions]]
 === Automatic Generation of Encoder/decoder Functions
 
-Encoding and decoding is performed by C++ external functions using the built-in codecs. These functions can be generated automatically by the complier. The present section deals with attributes governing the function generation.
+Encoding and decoding is performed by {cpp} external functions using the built-in codecs. These functions can be generated automatically by the complier. The present section deals with attributes governing the function generation.
 
 ==== Input and Output Types
 
@@ -1302,7 +1302,7 @@ The syntax of the `encode` and `decode` attributes is the following:
 
 BER encoding can be applied only for ASN.1 types.
 
-The <`codec_options`> part specifies extra options for the particular codec. Currently it is applicable only in case of BER and XML encoding/decoding. The `codec_options` are copied transparently to the parameter list of the C++ encoder/decoder function call in the generated function body without checking the existence or correctness of the referenced symbols.
+The <`codec_options`> part specifies extra options for the particular codec. Currently it is applicable only in case of BER and XML encoding/decoding. The `codec_options` are copied transparently to the parameter list of the {cpp} encoder/decoder function call in the generated function body without checking the existence or correctness of the referenced symbols.
 
 Example of prototype `convert`, BER encoding and decoding (the PDU is an ASN.1 type):
 [source]
@@ -1335,7 +1335,7 @@ The TITAN codec API has some well defined function calls that control the behavi
 
 Possible error types and error handlings are defined in <<13-references.adoc#\_16, [16]>>, section "The common API". The value of `<error_type>` shall be a value of type `error_type_t` without the prefix `ET_`. The value of `<error_handling>` shall be a value of type `error_behavior_t` without the prefix `EB_`.
 
-The TTCNâ€“3 attribute `errorbehavior(INCOMPL_ANY:ERROR)`, for example, will be mapped to the following C++ statement:
+The TTCNâ€“3 attribute `errorbehavior(INCOMPL_ANY:ERROR)`, for example, will be mapped to the following {cpp} statement:
 [source]
 ----
 TTCN_EncDec::set_error_behavior(TTCN_EncDec::ET_INCOMPL_ANY,
@@ -1453,7 +1453,7 @@ Restrictions:
 * the stream type of custom encoding and decoding functions is `bitstring`
 
 NOTE: Although theoretically variant attributes can be added for custom encoding types, their coding functions would not receive any information about them, so they would essentially be regarded as comments. If custom variant attributes are used, the variant attribute parserâ€™s error level must be lowered to warnings with the compiler option `-E`. +
-The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated C++ code to the header generated for the coder functionâ€™s module).
+The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated {cpp} code to the header generated for the coder functionâ€™s module).
 
 Example:
 [source]
@@ -1490,7 +1490,7 @@ This can be achieved the same way as the custom encoder and decoder functions de
 
 This can only be done for ASN.1 types, and has the same restrictions as the custom encoder and decoder functions. There is one extra restriction when using legacy codec handling (see section <<setting-the-default-codec-for-asn-1-types, Setting the default codec for ASN.1 types>>): an ASN.1 type cannot have both a PER encoder/decoder function and an encoder/decoder function of a built-in type set (this is checked separately for encoding and decoding).
 
-NOTE: The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated C++ code to the header generated for the coder functionâ€™s module).
+NOTE: The compiler searches all modules when attempting to find the coder functions needed for a type (including those that are not imported to the module where the `encvalue`, `decvalue`, `decmatch` or `@decoded` is located; if this is the case, then an extra include statement is added in the generated {cpp} code to the header generated for the coder functionâ€™s module).
 
 Example:
 [source]
@@ -1537,7 +1537,7 @@ Example: the attribute +
 
 === API describing External Interfaces
 
-Since the default class hierarchy of test ports does not allow sharing of C++ code with other port types, an alternate internal API is introduced for port types describing external interfaces. This alternate internal API is selected by giving the appropriate TTCNâ€“3 extension attribute to the port. The following extension attributes or attribute combinations can be used:
+Since the default class hierarchy of test ports does not allow sharing of {cpp} code with other port types, an alternate internal API is introduced for port types describing external interfaces. This alternate internal API is selected by giving the appropriate TTCNâ€“3 extension attribute to the port. The following extension attributes or attribute combinations can be used:
 
 .Port extension attributes
 [cols=",,,,,",options="header",]
@@ -1619,7 +1619,7 @@ type record ControlRequest { }
 type record ControlResponse { }
 type record PDUType1 { }
 type record PDUType2 { }
-// the encoder/decoder functions are written in C++
+// the encoder/decoder functions are written in {cpp}
 external function enc_PDUType1(in PDUType1 par) return octetstring
 with { extension "prototype(convert)" }
 external function dec_PDUType1(in octetstring stream,
@@ -7224,13 +7224,13 @@ In general, a module should require the full version of another module or TITAN
 
 === Consistency Check in the Generated Code
 
-A number of checks are performed during the build to ensure consistency of the TITAN compiler, TITAN runtime, C++ compiler used during the build. The compiler generates checking code that verifies:
+A number of checks are performed during the build to ensure consistency of the TITAN compiler, TITAN runtime, {cpp} compiler used during the build. The compiler generates checking code that verifies:
 
 * The version of the TITAN compiler matches the version of the TITAN runtime
 * The platform on which the build is being performed matches the platform of the TITAN compiler
 * The compiler used to build the TITAN compiler matches the compiler used to build the TITAN runtime
-* Some of this information (in form of C\++ preprocessor macros definitions and instructions) is available to test port writers to express dependency on a particular TITAN version. When a C++ file includes a header generated by the TITAN compiler, that header includes the definitions for the TITAN runtime, including version information. These macro dependencies can be used in user-written C++ code.
-* TTCN3_VERSION is a C/C\++ macro defined by the TITAN runtime headers. It contains an aggregated value of the TITAN major version, minor version and patch level. So, to express that a certain C++ file must be compiled together with TITAN R8C, the following code can be used:
+* Some of this information (in form of C\++ preprocessor macros definitions and instructions) is available to test port writers to express dependency on a particular TITAN version. When a {cpp} file includes a header generated by the TITAN compiler, that header includes the definitions for the TITAN runtime, including version information. These macro dependencies can be used in user-written {cpp} code.
+* TTCN3_VERSION is a C/C\++ macro defined by the TITAN runtime headers. It contains an aggregated value of the TITAN major version, minor version and patch level. So, to express that a certain {cpp} file must be compiled together with TITAN R8C, the following code can be used:
 +
 [source]
 ----
@@ -7239,7 +7239,7 @@ A number of checks are performed during the build to ensure consistency of the T
 #endif
 ----
 * There is a preprocessor macro defined in the makefile which identifies the platform (operating system). It can be one of SOLARIS (for Solaris 6), SOLARIS8 (for Solaris 8 and above), LINUX, WIN32. Platform-dependent code can be isolated using conditional compilation based on these macro definitions.
-* If the TITAN runtime was compiled with the GNU Compiler Collection (GCC), the macro GCC_VERSION is defined by the TITAN runtime headers. Its value is 10000 * (GCC major version) + 100 * (GCC minor version). For example, for GCC 3.4.6, GCC_VERSION will be defined to the value 30400; for GCC 4.1.2 it will be 40100. The value of this macro is compared during C++ compilation to the version of the compiler that was used to build TITAN itself to ensure consistency of the build. The GCC patch level is ignored for this comparison; code generated by a compiler with the same major and minor version is considered compatible. User-written code can use this value if it requires a certain version of the compiler. Alternatively, the predefined macros of the GNU compiler (*GNUC* and *GNUC_MINOR*) can be used for this purpose.
+* If the TITAN runtime was compiled with the GNU Compiler Collection (GCC), the macro GCC_VERSION is defined by the TITAN runtime headers. Its value is 10000 * (GCC major version) + 100 * (GCC minor version). For example, for GCC 3.4.6, GCC_VERSION will be defined to the value 30400; for GCC 4.1.2 it will be 40100. The value of this macro is compared during {cpp} compilation to the version of the compiler that was used to build TITAN itself to ensure consistency of the build. The GCC patch level is ignored for this comparison; code generated by a compiler with the same major and minor version is considered compatible. User-written code can use this value if it requires a certain version of the compiler. Alternatively, the predefined macros of the GNU compiler (*GNUC* and *GNUC_MINOR*) can be used for this purpose.
 * If the TITAN runtime was built with the SunPro compiler, the compiler itself defines the __SUNPRO_CC macro. Please consult the compiler documentation for the possible values.
 
 == Negative Testing
@@ -8089,7 +8089,7 @@ testcase TC(in integer i) runs on MyComp {
 }
 
 // external function can be used to re-throw the error in the catch block with a
-// modified or original (as in the example above) error message, the C++
+// modified or original (as in the example above) error message, the {cpp}
 // implementation:
 void throw_(const CHARSTRING& msg) {
   TTCN_error("%s", (const char*)msg);
diff --git a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
index 9ed38ba57e8516452511567e1333bc341053bf8c..d6e78315d306b6ff964283644a8d9041734be3aa 100644
--- a/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
+++ b/usrguide/referenceguide/6-compiling_ttcn3_and_asn1_modules.adoc
@@ -3,7 +3,7 @@
 :toc:
 :table-number: 11
 
-You can translate your TTCNâ€“3 and ASN.1 modules to C++ source code using the program compiler.
+You can translate your TTCNâ€“3 and ASN.1 modules to {cpp} source code using the program compiler.
 
 [[command-line-syntax]]
 == Command Line Syntax
@@ -102,7 +102,7 @@ Instructs the variant attribute parser to display warnings instead of errors for
 
 * `-f`
 +
-Forces the compiler to overwrite (update) the output files even if they exist or the contents of them will be identical. Without this flag the output C++ header and source files will be overwritten only if their contents change compared to the previous version.
+Forces the compiler to overwrite (update) the output files even if they exist or the contents of them will be identical. Without this flag the output {cpp} header and source files will be overwritten only if their contents change compared to the previous version.
 
 * `-g`
 +
@@ -144,7 +144,7 @@ Because of the `-T` flag the `Third.ttcn` will be treated as a TTCN-3 file, and
 
 * `-l`
 +
-Instructs the compiler to generate source file and line information (that is, #line directives) into the output code so that the error messages of the C\++ compiler refer back to the lines of the original TTCNâ€“3 input module. This makes finding the reason of C++ error messages easier. This option has effect only in the equivalent C++ code of TTCNâ€“3 functions, test cases and control parts and this feature is not provided in other TTCNâ€“3 definitions such as types, constants or templates.WARNING! This is an experimental feature and the C++ compiler may report misleading error messages that refer to totally wrong (e.g.Â non-existent) TTCNâ€“3 line numbers. In these cases please turn off this flag, repeat the compilation and analyze the generated code manually. Without this flag, the compiler also inserts the source code information for the better understanding of C++ error messages, but only as C++ comments. This option has no impact on the run-time performance of the generated code. The compiler performs full semantic analysis on its entire input; it normally does not generate erroneous C++ code. So this option became obsolete and will be removed in future versions.
+Instructs the compiler to generate source file and line information (that is, #line directives) into the output code so that the error messages of the C\++ compiler refer back to the lines of the original TTCNâ€“3 input module. This makes finding the reason of {cpp} error messages easier. This option has effect only in the equivalent {cpp} code of TTCNâ€“3 functions, test cases and control parts and this feature is not provided in other TTCNâ€“3 definitions such as types, constants or templates.WARNING! This is an experimental feature and the {cpp} compiler may report misleading error messages that refer to totally wrong (e.g.Â non-existent) TTCNâ€“3 line numbers. In these cases please turn off this flag, repeat the compilation and analyze the generated code manually. Without this flag, the compiler also inserts the source code information for the better understanding of {cpp} error messages, but only as {cpp} comments. This option has no impact on the run-time performance of the generated code. The compiler performs full semantic analysis on its entire input; it normally does not generate erroneous {cpp} code. So this option became obsolete and will be removed in future versions.
 
 * `-L`
 +
@@ -196,11 +196,11 @@ Disables the generation of RAW encoder/decoder routines for all TTCNâ€“3 types.
 
 * `-R`
 +
-Instructs the compiler to generate code for use with the function test runtime. The size of the generated code is significantly reduced, much of the functionality was migrated to the runtime. The generated C++ code has to be compiled using the TITAN_RUNTIME_2 symbol and has to be linked with the function test version of the runtime library. For example instead of the library file libttcn3.a the alternative libttcn3-rt2.a file must be used. The included c++ header files are the same.
+Instructs the compiler to generate code for use with the function test runtime. The size of the generated code is significantly reduced, much of the functionality was migrated to the runtime. The generated {cpp} code has to be compiled using the TITAN_RUNTIME_2 symbol and has to be linked with the function test version of the runtime library. For example instead of the library file libttcn3.a the alternative libttcn3-rt2.a file must be used. The included c++ header files are the same.
 
 * `-s`
 +
-Instructs the compiler to parse the given TTCNâ€“3 and ASN.1 modules and perform semantic analysis on them, but not to generate C++ output. The list of given modules shall be complete so it is not allowed to import from a module that is not in the list. All options that influence the code generation are silently ignored when used together with `-s`.
+Instructs the compiler to parse the given TTCNâ€“3 and ASN.1 modules and perform semantic analysis on them, but not to generate {cpp} output. The list of given modules shall be complete so it is not allowed to import from a module that is not in the list. All options that influence the code generation are silently ignored when used together with `-s`.
 +
 NOTE: The TTCNâ€“3 semantic analyzer of the compiler is still under development, thus, it is not capable of detecting every kind of semantic error.
 
@@ -286,7 +286,7 @@ The single dash character as command line argument has a special meaning: it con
 
 * `â€“ttcn2json`
 +
-Changes the purpose of the compiler to generate a JSON schema from the types defined in the specified TTCN-3 and ASN.1 modules. The parsing and semantic check of the input modules is still executed, but a JSON schema is generated instead of the C++ files. This must always be the first compiler option, and the previously listed options donâ€™t apply (apart from options `â€“A` and `â€“T`), instead the following options are available:
+Changes the purpose of the compiler to generate a JSON schema from the types defined in the specified TTCN-3 and ASN.1 modules. The parsing and semantic check of the input modules is still executed, but a JSON schema is generated instead of the {cpp} files. This must always be the first compiler option, and the previously listed options donâ€™t apply (apart from options `â€“A` and `â€“T`), instead the following options are available:
 
 * `-j`
 +
@@ -329,7 +329,7 @@ The switches denoted by square brackets are optional. More than one option may b
 
 * `-a`
 +
-The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory. The flag generates a Makefile that is capable of using pre-compiled C++ and object files from central directories in order to save disk space and compilation time. WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCNâ€“3 Executor and C++ compiler version, etc.).
+The flag refers to files using absolute path names in the generated Makefile. Makefile uses by default relative path names to access files located outside the current working directory of the compiler. Files from the current working directory are always referenced using only the file name without any directory. The flag generates a Makefile that is capable of using pre-compiled {cpp} and object files from central directories in order to save disk space and compilation time. WARNING! This feature works only if the generated files of the central directory is kept up-to-date and all directories use exactly the same environment (platform, TTCNâ€“3 Executor and {cpp} compiler version, etc.).
 
 * `-c`
 +
@@ -401,7 +401,7 @@ Writes the Makefile to the given directory or file. If the given argument is an
 
 * `-O <file>`
 +
-Add file to the list of other files in the generated `Makefile` without analyzing the file contents and suffix. This option can be used to temporarily exclude some TTCN-3, ASN.1 modules ASN.1 or C++ files from the build process, but add them to the archive created by the command make archive.
+Add file to the list of other files in the generated `Makefile` without analyzing the file contents and suffix. This option can be used to temporarily exclude some TTCN-3, ASN.1 modules ASN.1 or {cpp} files from the build process, but add them to the archive created by the command make archive.
 
 * `-p`
 +
@@ -439,7 +439,7 @@ Enforces legacy behaviour of the "out" function parameters (the "out" parameter
 +
 Enables code coverage and profiling in the TTCN-3 files listed in the `file` argument. The TTCN-3 files in the list must be separated by new lines and must also appear among the makefile generatorâ€™s arguments (this switch is ignored if the â€“t option is present).
 +
-If any of the source (TTCN-3, ASN.1, user-written C++) files does not exist or cannot be accessed, `ttcn3_makefilegen` exits with an error.
+If any of the source (TTCN-3, ASN.1, user-written {cpp}) files does not exist or cannot be accessed, `ttcn3_makefilegen` exits with an error.
 +
 Other options are discussed in the next chapters.
 
@@ -762,7 +762,7 @@ The `makefilegen` tool allows the usage of code splitting mechanisms when genera
 
 Let "number" be equal to 4 for this example. We want to split the files into four pieces.
 
-Firstly, TITAN finds the TTCN3 module whose C\++ generated code will be the largest. In this example, it will be 10000 characters (letâ€™s call it MAX). So the largest generated C++ module contains 10000 characters.
+Firstly, TITAN finds the TTCN3 module whose C\++ generated code will be the largest. In this example, it will be 10000 characters (letâ€™s call it MAX). So the largest generated {cpp} module contains 10000 characters.
 
 Secondly TITAN calculates the splitting threshold by dividing MAX with "number", so it will be 10000 / 4 = 2500 in this case. TITAN will only split the generated c++ files which are larger than 2500 characters.
 
@@ -816,11 +816,11 @@ NOTE: Error recovery is not always successful and it might result in additional
 
 After the syntax check the compiler performs semantic analysis on TTCNâ€“3 /ASN.1 module(s) and verifies whether the various definitions and language elements are used in the appropriate way according to the static semantics of TTCNâ€“3 and ASN.1 languages. In addition to error messages the compiler reports a warning when the corresponding definition is correct, but it might have unwanted effects.
 
-If both syntax and semantic checks were successful, the compiler generates a C++ header and source file that contains the translated module. If the name of the input module is `MyModule` (i.e.Â it begins with module `MyModule`), the name of the generated header and source file will be `MyModule.hh` and `MyModule.cc`, respectively. Note that the name of the output file does NOT depend on the name of input file. In ASN.1 module names the hyphens are converted to underscore characters (e.g.Â the C++ code for `My-Asn-Module` will be placed into `My_Asn_Module.hh` and `My_Asn_Module.cc`).
+If both syntax and semantic checks were successful, the compiler generates a {cpp} header and source file that contains the translated module. If the name of the input module is `MyModule` (i.e.Â it begins with module `MyModule`), the name of the generated header and source file will be `MyModule.hh` and `MyModule.cc`, respectively. Note that the name of the output file does NOT depend on the name of input file. In ASN.1 module names the hyphens are converted to underscore characters (e.g.Â the {cpp} code for `My-Asn-Module` will be placed into `My_Asn_Module.hh` and `My_Asn_Module.cc`).
 
-By default, the compiler generates the C++ code for all input modules. This can be unnecessarily time-consuming when doing incremental builds for large projects. The build process can be significantly speed up if the compiler option - (single dash) is used. In this case the C++ code will be generated only for those modules that have changed since last build of the ASN.1 modules. With selective code generation it can be exploited that the make utility can easily tell which source files were changed since the last compilation.
+By default, the compiler generates the {cpp} code for all input modules. This can be unnecessarily time-consuming when doing incremental builds for large projects. The build process can be significantly speed up if the compiler option - (single dash) is used. In this case the {cpp} code will be generated only for those modules that have changed since last build of the ASN.1 modules. With selective code generation it can be exploited that the make utility can easily tell which source files were changed since the last compilation.
 
-This sophisticated command line syntax is necessary because in general case it is impossible to perform the semantic analysis on a subset of the modules because those may import from modules outside the list. Moreover, to avoid undesirable side-effects of the code optimization techniques implemented in the compiler (e.g.Â type and value folding) the C++ code is generated not only for the modified modules, but for all modules that import definitions (either directly or indirectly) from the modified ones.
+This sophisticated command line syntax is necessary because in general case it is impossible to perform the semantic analysis on a subset of the modules because those may import from modules outside the list. Moreover, to avoid undesirable side-effects of the code optimization techniques implemented in the compiler (e.g.Â type and value folding) the {cpp} code is generated not only for the modified modules, but for all modules that import definitions (either directly or indirectly) from the modified ones.
 
 When the compiler translates an ASN.1 module, the different ASN.1 types are mapped to TTCNâ€“3 types as described in the table below.
 
diff --git a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
index 31b8f158380daf0cb37771b4db67e6d573a3a7e4..267f44b1da50c827455c9b6f21802e83d6bd6821 100644
--- a/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
+++ b/usrguide/referenceguide/7-the_run-time_configuration_file.adoc
@@ -901,7 +901,7 @@ The option can take one of the three possible values: `None`, `Single` and `Stac
 
 The location information is placed in each line of the log file between the event type or timestamp and the textual description of the event.
 
-This option works only if the command line option `â€“L` is passed to the compiler (see <<6-compiling_ttcn3_and_asn1_modules.adoc#command-line-syntax, here>>). This feature is useful for debugging new TTCNâ€“3 code or for understanding the traces of complex control constructs. If the location information is not generated into the C++ code the executable tests run faster, which can be more important when doing performance tests.
+This option works only if the command line option `â€“L` is passed to the compiler (see <<6-compiling_ttcn3_and_asn1_modules.adoc#command-line-syntax, here>>). This feature is useful for debugging new TTCNâ€“3 code or for understanding the traces of complex control constructs. If the location information is not generated into the {cpp} code the executable tests run faster, which can be more important when doing performance tests.
 
 NOTE: The reception of messages or procedure calls can only occur while the run-time environment is taking a new snapshot. A new snapshot is taken when the testcomponent is evaluating a stand-alone receiving operation, an `alt` construct or a standalone `altstep` invocation. Thus, the location information of the incoming messages or calls points to the first line of the above statements. The log event belonging to a TTCNâ€“3 operation can be the extraction of a message from the port queue and not the reception of an incoming message.
 
diff --git a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
index 8a1c7794862dfcc8d22c508662053a63898c2130..07c4881ecf9414b8faa6f5188440df052cbdc594 100644
--- a/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
+++ b/usrguide/referenceguide/8-the_titan_project_descriptor_file.adoc
@@ -200,7 +200,7 @@ Useful information can be found in TITAN Designer documentation <<13-references.
 |`dynamicLinking` |-l |- |false |O
 |`functiontestRuntime (use function test runtime (TITAN_RUNTIME_2)` |-R |-R |false |O
 |`singleMode` |-s |- |false |O
-|`codeSplitting (select code splitting mode for the generated C++ code)` |-U |-U |none |O
+|`codeSplitting (select code splitting mode for the generated {cpp} code)` |-U |-U |none |O
 |`defaultTarget ("executable" or "library", if â€“L applied, see 6.1.2)` |-L |- |executable |O
 |`targetExecutable` |-e |- |N/A |O
 |`TTCN3preprocessor (the name of the preprocessor meaningful only in Eclipse)` |- |- |cpp |O
@@ -215,7 +215,7 @@ Useful information can be found in TITAN Designer documentation <<13-references.
 |`defaultasOmit (-d compiler option)` |- |-d |false |O
 |`gccMessageFormat (emulate GCC error/warning message format)` |- |-g |false |O
 |`lineNumbersOnlyInMessages (use only line numbers in error/warning messages)` |- |-i |false |O
-|`includeSourceInfo (include source line info in C++ code)` |- |-l |false |O
+|`includeSourceInfo (include source line info in {cpp} code)` |- |-l |false |O
 |`addSourceLineInfo (add source line info for logging)` |- |-L |false |O
 |`suppressWarnings (suppress warnings)` |-w |-w |false |O
 |`Quietly (suppress all messages, quiet mode)` |- |-q |false |O
@@ -249,7 +249,7 @@ The supported values of `optimizationLevel` are:
 The support values for buildLevel are:
 
 * "Level 0 - Semantic Check"
-* "Level 1 - TTCN3 -> C++ compilation"
+* "Level 1 - TTCN3 -> {cpp} compilation"
 * "Level 2 - Creating object files"
 * "Level 2.5 - Creating object files with heuristical dependency update"
 * "Level 3 - Creating object files with dependency update"
diff --git a/usrguide/releasenotes/releasenotes.adoc b/usrguide/releasenotes/releasenotes.adoc
index e4432750769e276c6ce88bf4246dce573f2982fe..c2c41ad0bd3b67df08fe448269a03faf94d982ea 100644
--- a/usrguide/releasenotes/releasenotes.adoc
+++ b/usrguide/releasenotes/releasenotes.adoc
@@ -318,7 +318,7 @@ Version 2.1 has the following new features:
 * The performance of TEXT decoding has been improved.
 * A logger plugin (JUnitLogger) is now delivered with Titan. It outputs XML files in the same format as JUnit. Using this logger plugin allows integrating of Titan with the Jenkins (Hudson) continuous integration tool.
 * To allow JUnitLogger to receive the necessary information, the Titan Logger API has been slightly changed. Existing logger plugins will need to be rebuilt.
-* In response to a TR (HP88760), the C++ interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
+* In response to a TR (HP88760), the {cpp} interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
 * `ttcn3_makefilegen` has a new flag `â€“P`, which prints out the list of files found in a given TPD recursively relative to a given directory.
 * TTCN-3 level code coverage was implemented.
 * Text hover for T3Doc in Eclipse was implemented.
@@ -423,7 +423,7 @@ Version 1.8 has the following new features:
 
 Version 1.7 has the following new features:
 
-* The naming convention of the generated C\++ code has been revised to avoid potential name clashes between definitions. The definitions of each TTCNâ€“3 and ASN.1 module is put into a separate C++ namespace that corresponds to the module name. This eliminates all problems caused by definitions with identical names in different modules. The scope of C++ enum values that represent the values of TTCNâ€“3 and ASN.1 enumerated types became narrower to avoid conflicts if the same element name appears in two different enumerated types.
+* The naming convention of the generated C\++ code has been revised to avoid potential name clashes between definitions. The definitions of each TTCNâ€“3 and ASN.1 module is put into a separate {cpp} namespace that corresponds to the module name. This eliminates all problems caused by definitions with identical names in different modules. The scope of {cpp} enum values that represent the values of TTCNâ€“3 and ASN.1 enumerated types became narrower to avoid conflicts if the same element name appears in two different enumerated types.
 
 * Extension (inheritance) of TTCNâ€“3 component types and compatibility between different component types is now supported by the compiler.
 
@@ -450,7 +450,7 @@ Version 1.6 has the following new features:
 
 * The semantic check for the TTCNâ€“3 dynamic behavior descriptions (such as functions, altsteps, testcases) have been implemented, which means that all parts of TTCNâ€“3 modules are now analyzed.
 
-* The compiler generates the entire C++ code from the Abstract Syntax Tree, that is, the output of semantic analysis. This makes it possible to add support for some language constructs and perform code optimization in future versions. These were impossible with the old, parser-based code generator.
+* The compiler generates the entire {cpp} code from the Abstract Syntax Tree, that is, the output of semantic analysis. This makes it possible to add support for some language constructs and perform code optimization in future versions. These were impossible with the old, parser-based code generator.
 
 * The TTCNâ€“3 parser of the compiler supports recovery from syntax errors. This means the compiler does not stop when a syntax error is detected, but it continues to analyze the input to find more errors. +
 
@@ -483,7 +483,7 @@ Version 1.5 has the following new features:
 
 * The compiler produces user-friendly error messages with file name and line number information and supports error recovery. It displays all error messages found in the input modules.
 
-* The time needed for the compilation of generated C++ code was significantly reduced compared to 1.4.pl0. The saving can be more than 50 % in case of large projects.
+* The time needed for the compilation of generated {cpp} code was significantly reduced compared to 1.4.pl0. The saving can be more than 50 % in case of large projects.
 
 * Procedure based TTCNâ€“3 ports and the related communication operations are now supported with enhanced Test Port API.
 
@@ -504,7 +504,7 @@ Version 1.4 has the following new features:
 
 * The compiler performs automatic reordering in the generated code for TTCNâ€“3 types as well. This means, the generated C\++ code will be always valid even if the type definitions use forward referencing. +
 
-NOTE: The forward referencing problem between TTCNâ€“3 constants and templates is still unsolved. They must be declared in bottom-up order to get a working C++ code.
+NOTE: The forward referencing problem between TTCNâ€“3 constants and templates is still unsolved. They must be declared in bottom-up order to get a working {cpp} code.
 
 * The code generation routines of the previous compilers were fully re-used and no significant changes were made in the Base Library in order to preserve the stability of the executable tests.
 
@@ -544,11 +544,11 @@ Version 1.2 has the following new features:
 
 * The compiler supports the new, Edition 2 syntax of the TTCNâ€“3 Core Language. The obsolete language elements that were supported in version 1.1 (e.g.Â named alternatives) are still accepted for backward compatibility, but a warning message is printed.
 
-* The toolset contains a new ASN.1 compiler, which allows the importing of ASN.1 modules into TTCNâ€“3 test suites. Like the TTCNâ€“3 compiler, the ASN.1 compiler translates ASN.1 definitions to C\++ code, which shall be used together with C++ output of TTCNâ€“3 modules.
+* The toolset contains a new ASN.1 compiler, which allows the importing of ASN.1 modules into TTCNâ€“3 test suites. Like the TTCNâ€“3 compiler, the ASN.1 compiler translates ASN.1 definitions to C\++ code, which shall be used together with {cpp} output of TTCNâ€“3 modules.
 
-* The ASN.1 compiler performs a semantic analysis on its input and reports errors instead of generating invalid C++ code.
+* The ASN.1 compiler performs a semantic analysis on its input and reports errors instead of generating invalid {cpp} code.
 
-* The ASN.1 compiler may generate additional functions for the equivalent C++ classes of ASN.1 data types that allow the encoding and decoding of data values according to the Basic Encoding Rules (BER) of ASN.1.
+* The ASN.1 compiler may generate additional functions for the equivalent {cpp} classes of ASN.1 data types that allow the encoding and decoding of data values according to the Basic Encoding Rules (BER) of ASN.1.
 
 * The TTCNâ€“3 compiler has a new feature that may generate additional functions for TTCNâ€“3 data types for direct (RAW) encoding/decoding of messages. This encoding scheme can be efficiently used for protocols that define the encoding of its PDUs in table-based format. The encoding rules shall be specified in special with attributes of the data types.
 
@@ -902,7 +902,7 @@ Released on Jun.Â 27, 2012
 * The performance of TEXT decoding has been improved.
 * A logger plugin (`JUnitLogger`) is now delivered with Titan. It outputs XML files in the same format as JUnit. Using this logger plugin allows integrating of Titan with the Jenkins (Hudson) continuous integration tool.
 * To allow `JUnitLogger` to receive the necessary information, the Titan Logger API has been slightly changed. Existing logger plugins will need to be rebuilt.
-* In response to a TR (HP88760), the C++ interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
+* In response to a TR (HP88760), the {cpp} interface of the OBJID class has been changed. The type of the elements in the internal storage of the OBJID class is now specified with a `typedef`, `objid_component`. Code which uses the indexing operators or directly accesses the element storage will need to be rewritten. It is a backward incompatible change and it affects users of the SNMP test port. A new version of the SNMP test port was released (CNL 113 344 R4B) compatible with the new Titan.
 * `ttcn3_makefilegen` has a new flag `â€“P`, which prints out the list of files found in a given TPD recursively relative to a given directory.
 * TTCN-3 level code coverage was implemented.
 * Text hover for T3Doc in Eclipse was implemented.
@@ -988,7 +988,7 @@ Released on Oct.Â 10, 2011
 
 * We have re-implemented the `isbound` predefined function in way that is much more performance efficient than the previous one released.
 
-* The `encode_utf8` function of our universal charstring class became part of our public API, so it can now be safely used from C/C++ codes as well.
+* The `encode_utf8` function of our universal charstring class became part of our public API, so it can now be safely used from C/{cpp} codes as well.
 
 * The indexing of string templates became supported.
 
@@ -1115,7 +1115,7 @@ Released on Jan.Â 29, 2010
 
 * Dependency checking was enhanced in the build system. If using the new way, dependencies will be refreshed only for those modules that have changed, plus the dependencies on gcc are not tracked.
 
-* At build time the compiler can to split the generated code based on the types present in modules. When using the option "type", TITAN will create separate source files for the implementation code of the following types (for each module): sequence, sequence of, set, set of, union. In this case a common header file and a source file holding everything else will also be created. The amount of the generated files increases on this way, but as each of them is smaller the C++ compiler can compile them easier. As there are more files, the build process can run much more efficiently in parallel mode.
+* At build time the compiler can to split the generated code based on the types present in modules. When using the option "type", TITAN will create separate source files for the implementation code of the following types (for each module): sequence, sequence of, set, set of, union. In this case a common header file and a source file holding everything else will also be created. The amount of the generated files increases on this way, but as each of them is smaller the {cpp} compiler can compile them easier. As there are more files, the build process can run much more efficiently in parallel mode.
 
 * In the Designer plug-in the behavior of the content assistant can be configured by the user. Sorting of the proposals can be configured to be either alphabetical or relevance based. It is also possible to set the common prefixes of proposals, or in the case there was only 1 proposal found the whole proposal should be inserted automatically.
 
@@ -1393,7 +1393,7 @@ NOTE: TTCNâ€“3 regular expressions are used by the matching mechanism pattern in
 
 * Non-standard additional predefined function `unichar2char()` has been introduced.
 
-* The run-time realization of TTCNâ€“3 additional predefined functions has been enhanced. New polymorphic versions have been introduced to eliminate the conversion of arguments in C++. The error messages generated by these functions have been rephrased to make the reason of the failure easier to understand.
+* The run-time realization of TTCNâ€“3 additional predefined functions has been enhanced. New polymorphic versions have been introduced to eliminate the conversion of arguments in {cpp}. The error messages generated by these functions have been rephrased to make the reason of the failure easier to understand.
 
 * Utility `*ttcn3 logformat*` supports the indentation depth of zero. Option `-i` 0 eliminates the previous indentation made in the file so that each log entry is printed in one line.
 
@@ -1401,7 +1401,7 @@ NOTE: TTCNâ€“3 regular expressions are used by the matching mechanism pattern in
 
 * The meaning of metacharacter `%n` within the log file name skeletons has been extended. It is substituted with the string `_MTC_` in single mode and on the MTC, with string `_HC_` on the HCs or with the name of the PTC if it was given one when it was created. Formerly, this metacharacter had useful value only on PTCs.
 
-* The status of module parameter values given without module name in section `[MODULE PARAMETERS]` of the configuration file has been clarified. The ambiguity was introduced in the previous release, 1.7.pl0, in which the new C++ naming rules allow the definition of module parameters with identical names in different modules. If the module name is omitted or substituted with an asterisk character (*) in the configuration file the value will be set in all modules that have parameter with the given name. Error occurs if none of the modules contain module parameter with the that name. Unless the module name is given in the configuration file the run-time environment assumes that all identically named parameters have the same type.
+* The status of module parameter values given without module name in section `[MODULE PARAMETERS]` of the configuration file has been clarified. The ambiguity was introduced in the previous release, 1.7.pl0, in which the new {cpp} naming rules allow the definition of module parameters with identical names in different modules. If the module name is omitted or substituted with an asterisk character (*) in the configuration file the value will be set in all modules that have parameter with the given name. Error occurs if none of the modules contain module parameter with the that name. Unless the module name is given in the configuration file the run-time environment assumes that all identically named parameters have the same type.
 
 * The following enhancements have been made on the GUI:
 
@@ -1429,29 +1429,29 @@ New features added to the Eclipse plugins:
 
 *Fixed bugs*
 
-* The generated C\++ equivalent of enumerated types could not be compiled with GCC 2.95.x if the new naming rules were in effect. The problem was caused by the C++ enum type that was declared within the scope of the C++ class representing the values of the enumerated type. The old version of GCC accepts the casting operator only if the name of the embedded enum type is prefixed with the name of the C++ class.
+* The generated C\++ equivalent of enumerated types could not be compiled with GCC 2.95.x if the new naming rules were in effect. The problem was caused by the {cpp} enum type that was declared within the scope of the {cpp} class representing the values of the enumerated type. The old version of GCC accepts the casting operator only if the name of the embedded enum type is prefixed with the name of the {cpp} class.
 
 * When logging the matching procedure of optional fields in record and set types the field of the value and the template was printed in the wrong order if the field of the value was set to omit. Always the value must be printed first during matching, which corresponds to the order of arguments in built-in operation `match()`.
 
-* The compiler generated wrong C\++ code for repeat statements found within the response and exception handling parts of call statements. If the call statement was embedded into an altstep the generated code assumed that the repeat statement refers to the whole altstep. Otherwise the generated C++ code was erroneous, it could not be compiled.
+* The compiler generated wrong C\++ code for repeat statements found within the response and exception handling parts of call statements. If the call statement was embedded into an altstep the generated code assumed that the repeat statement refers to the whole altstep. Otherwise the generated {cpp} code was erroneous, it could not be compiled.
 
 * The copy constructor of class TTCN Buffer did not work properly in the Base Library. This class is used by the common API for encoding and decoding. The defective copy constructor did not copy the length indicator field of the buffer to the newly created object thus some manually written codec functions and Test Ports reported mysterious internal error messages.
 
 * The semantic analyzer of the compiler reported false error messages while checking procedure-based operations `catch(timeout)`. Although this operation is applicable after calling any blocking signature the compiler accepted `catch(timeout)` only if the regular catch operation was allowed (i.e.Â the corresponding signature had at least one exception type). Of course, the operation `catch(timeout)` is allowed within the response and exception handling parts of call operations and only if the respective operation has a call timer.
 
-* The compiler generated erroneous C\++ code for the construct _value returning done_ if the new naming rules were in effect. The invoked C++ function was not prefixed with the appropriate namespace if the done statement and the return type of the PTC behavior function (having attribute with _{extension "done" }_) were defined in different modules.
+* The compiler generated erroneous C\++ code for the construct _value returning done_ if the new naming rules were in effect. The invoked {cpp} function was not prefixed with the appropriate namespace if the done statement and the return type of the PTC behavior function (having attribute with _{extension "done" }_) were defined in different modules.
 
 * Erroneous circular TTCNâ€“3 type references pointing back to themselves with field or array sub-references (like type T[0].f1 T;) caused infinite recursion in the semantic analyzer and consequently the compiler crashed with segmentation fault.
 
 * The utility `*ttcn3 logbrowser*` mis-interpreted some log entries. If the text of the log entry contained only a small integer number (like 1 or 2) the log browser presented the number as an erroneous component reference and left the field for the event text empty.
 
-* The generated C\++ code related to TTCNâ€“3 expressions comparing optional fields of record and set types was erroneous in some cases. If two optional fields were tested for inequality the generated code could not be compiled with GCC 4.0.x or later. GCC complained about ambiguous overloading of operators. Furthermore, if an optional field containing a value of type charstring was compared with an optional field containing universal charstring the C++ code caused infinite recursion at runtime. All these errors were related to the instantiation of template member functions of C++ template classes.
+* The generated C\++ code related to TTCNâ€“3 expressions comparing optional fields of record and set types was erroneous in some cases. If two optional fields were tested for inequality the generated code could not be compiled with GCC 4.0.x or later. GCC complained about ambiguous overloading of operators. Furthermore, if an optional field containing a value of type charstring was compared with an optional field containing universal charstring the {cpp} code caused infinite recursion at runtime. All these errors were related to the instantiation of template member functions of {cpp} template classes.
 
 * The semantic analyzer of the compiler did not check properly the value list and value range (i.e.Â character range) type restrictions of type universal charstring. Even some basic checks, such as the verification of range boundaries and overlapping, were skipped in previous versions.
 
-* The compiler generated incomplete C++ type descriptor structures for some TTCNâ€“3 types, which could lead to segmentation fault in the run-time environment during encoding or decoding using the built-in RAW or TEXT codecs. For example, if a type alias was created for type charstring with a fixed length restriction, but without coding attributes then the type descriptor of the aliased type contained information only for RAW encoding. The information about TEXT coding was not inherited from the built-in type charstring. If this aliased type was embedded into a structured type with appropriate TEXT coding attributes the TEXT encoder and decoder operations on the structured type would crash with segmentation fault.
+* The compiler generated incomplete {cpp} type descriptor structures for some TTCNâ€“3 types, which could lead to segmentation fault in the run-time environment during encoding or decoding using the built-in RAW or TEXT codecs. For example, if a type alias was created for type charstring with a fixed length restriction, but without coding attributes then the type descriptor of the aliased type contained information only for RAW encoding. The information about TEXT coding was not inherited from the built-in type charstring. If this aliased type was embedded into a structured type with appropriate TEXT coding attributes the TEXT encoder and decoder operations on the structured type would crash with segmentation fault.
 
-* The compiler generated erroneous C++ initializers for literal values of type charstring containing NUL characters (i.e.Â characters with character code zero). The length of the strings was set correctly in the run-time environment, but the characters of the string contained memory garbage after the first NUL character.
+* The compiler generated erroneous {cpp} initializers for literal values of type charstring containing NUL characters (i.e.Â characters with character code zero). The length of the strings was set correctly in the run-time environment, but the characters of the string contained memory garbage after the first NUL character.
 
 * The algorithm that translates TTCNâ€“3 regular expressions to their POSIX equivalents handled the TTCNâ€“3 character set expressions incorrectly. Neither individual characters nor character ranges of the set were mapped properly (using the appropriate escape sequences) to POSIX. The resulting POSIX character set was sometimes faulty or had different meaning than the original TTCNâ€“3 set. This problem affected the matching mechanism pattern in templates of type charstring, the arguments of predefined function `regexp()` and the attributes of TEXT encoding in both the compiler and the run-time environment.
 
@@ -1465,9 +1465,9 @@ New features added to the Eclipse plugins:
 
 * The semantic checker algorithm that verified attribute user of dual-faced port types was incomplete. The compiler did not report any error if a source type of an in or out mapping was not present on the message list of the respective port type.
 
-* The decode type mapping rules of dual-faced port types did not consider the associated `errorbehavior` attribute. The reason was that the C++ equivalents of the errorbehavior settings were left out from the generated code by mistake.
+* The decode type mapping rules of dual-faced port types did not consider the associated `errorbehavior` attribute. The reason was that the {cpp} equivalents of the errorbehavior settings were left out from the generated code by mistake.
 
-* The default argument of the constructor (NULL pointer) was missing from the generated C\++ classes implementing TTCNâ€“3 ports if the respective TTCNâ€“3 port type had attribute provider or user. Because of this the compilation of the generated C++ code failed when a TTCNâ€“3 port array was created from the above port types. The C++ template class that realizes port arrays tried to instantiate its elements using the default constructor (i.e.Â without parameters).
+* The default argument of the constructor (NULL pointer) was missing from the generated C\++ classes implementing TTCNâ€“3 ports if the respective TTCNâ€“3 port type had attribute provider or user. Because of this the compilation of the generated {cpp} code failed when a TTCNâ€“3 port array was created from the above port types. The {cpp} template class that realizes port arrays tried to instantiate its elements using the default constructor (i.e.Â without parameters).
 
 * The command line version of the Main Controller (i.e.Â `mctr cli`) crashed with a segmentation fault after encountering the expansion of an invalid macro to a host name (e.g. $_{NonExistentMacro, hostname}_) in the configuration file. The crash occurred after reporting the appropriate error message. The reason was an uninitialized variable.
 
@@ -1475,7 +1475,7 @@ New features added to the Eclipse plugins:
 
 * The error message of the compiler pointed to the wrong location in the source file if a (named) TTCNâ€“3 constant was assigned to a variable and the actual value of the constant violated the subtype restrictions in the type of the variable. In this case the error message pointed to the literal value of the constant (which was apparently correct) rather than the faulty variable assignment.
 
-* The Base Library lacked the C\++ functions and operators that can implicitly convert a template (or template variable) of type charstring to a template of type universal charstring by translating the embedded matching mechanisms character-by-character. TTCNâ€“3 modules using such constructs were accepted by the compiler, but the generated C++ code could not be compiled due to ambiguous overloads of operators. To resolve the problem a new constructor and assignment operator have been added to class UNIVERSAL CHARSTRING template, both taking CHARSTRING template as argument.
+* The Base Library lacked the C\++ functions and operators that can implicitly convert a template (or template variable) of type charstring to a template of type universal charstring by translating the embedded matching mechanisms character-by-character. TTCNâ€“3 modules using such constructs were accepted by the compiler, but the generated {cpp} code could not be compiled due to ambiguous overloads of operators. To resolve the problem a new constructor and assignment operator have been added to class UNIVERSAL CHARSTRING template, both taking CHARSTRING template as argument.
 
 * Although the ASN.1 front-end of the compiler ignores all type constraints except the table and component relation constraints of open types, some valid type constraints were rejected by the parser. False syntax errors were generated, for instance, if a single value constraint contained values within brackets (such as `SEQUENCE` or `SET` values) or a permitted alphabet constraint (denoted by keyword FROM) contained single characters using the quadruple notation.
 
@@ -1498,11 +1498,11 @@ Released on March 9, 2007.
 
 *New features*
 
-* The naming convention of the generated C\++ code has been revised to avoid name clashes between different definitions. The use of a C++ namespace for each module eliminates all compilation problems caused by definitions with the same identifier in different modules. The proper scoping of enumerated values excludes the name conflict between two enumerated types and makes the enum-hack option unnecessary and obsolete.
+* The naming convention of the generated C\++ code has been revised to avoid name clashes between different definitions. The use of a {cpp} namespace for each module eliminates all compilation problems caused by definitions with the same identifier in different modules. The proper scoping of enumerated values excludes the name conflict between two enumerated types and makes the enum-hack option unnecessary and obsolete.
 
 * Extensibility (inheritance) of TTCNâ€“3 component types and type compatibility between different component types is now supported by the compiler.
 
-* The compiler can generate TTCNâ€“3 external functions automatically in C\++ to perform encoding and decoding of message types using the built-in codecs of the runtime environments. C++ programming is no longer necessary to create a complete and working protocol module. All options of the encoding shall be given in TTCNâ€“3 as attributes of the external functions.
+* The compiler can generate TTCNâ€“3 external functions automatically in C\++ to perform encoding and decoding of message types using the built-in codecs of the runtime environments. {cpp} programming is no longer necessary to create a complete and working protocol module. All options of the encoding shall be given in TTCNâ€“3 as attributes of the external functions.
 
 * Dual-faced TTCNâ€“3 ports are now supported. Such ports have two different interfaces: internal (used when sending and receiving messages) and external (used when connecting the port to another test component or mapping to a system port). The handling of incoming and outgoing messages shall be specified using type mapping rules in the attributes of port types.
 
@@ -1540,13 +1540,13 @@ Released on March 9, 2007.
 
 * The compiler reported an error if the argument of TTCNâ€“3 built-in operation `ischosen` was a value or template of an ASN.1 open type. ASN.1 open types should be visible from TTCNâ€“3 as union types.
 
-* The compiler generated wrong C++ code for port operation `getreply` if the corresponding signature had return type, but the operation did not specify a value match. The lack of value match means that all possible incoming return values should be accepted by the operation. However, when the referred signature template was nonparameterized the generated code matched the return value against the value match specified in the previous `getreply` operation referring to the same signature template.
+* The compiler generated wrong {cpp} code for port operation `getreply` if the corresponding signature had return type, but the operation did not specify a value match. The lack of value match means that all possible incoming return values should be accepted by the operation. However, when the referred signature template was nonparameterized the generated code matched the return value against the value match specified in the previous `getreply` operation referring to the same signature template.
 
 * The compiler aborted with an internal fatal error during semantic analysis when a function or altstep type had a timer formal parameter.
 
 * The error message of the run-time environment was misleading when trying to convert a record or set value containing an unbound optional field to a template of the corresponding type because the message referred to built-in function `ispresent`. The reason was that the internal realization of the value to template conversion was based on `ispresent`. The conversion algorithm has been rewritten to give a more straightforward error message.
 
-* The semantic analyzer of the compiler did not verify the compatibility of component types when checking the component references returned by built-in operations `create`, `self`, `mtc` and `system`. For example the compiler was unable to detect if a component reference returned by create was assigned to a variable of a different component type. The C++ code generated from invalid input could be compiled to executable, but the component operations following the erroneous statement could result in run-time errors.
+* The semantic analyzer of the compiler did not verify the compatibility of component types when checking the component references returned by built-in operations `create`, `self`, `mtc` and `system`. For example the compiler was unable to detect if a component reference returned by create was assigned to a variable of a different component type. The {cpp} code generated from invalid input could be compiled to executable, but the component operations following the erroneous statement could result in run-time errors.
 
 * The implementation of TTCNâ€“3 operation any `component.done` was incorrect in the Main Controller. The MC gave false positive answer to the MTC if there was a PTC that was just created, but not yet started.
 
@@ -1609,7 +1609,7 @@ Released on November 27, 2006.
 
 * In some cases the GUI did not load the user-defined test sets that were stored in the project.
 
-* The compiler generated wrong (uncompilable) C\++ code for the location information when the name of the input file contained special characters (like the backslash) that require escaping in C++ string literals.
+* The compiler generated wrong (uncompilable) C\++ code for the location information when the name of the input file contained special characters (like the backslash) that require escaping in {cpp} string literals.
 
 * The compiler aborted with an internal fatal error during semantic analysis if a RAW attribute POINTERTO referred to a non-existent field. The abort occurred after printing the relevant error message.
 
@@ -1617,11 +1617,11 @@ Released on November 27, 2006.
 
 * The compiled did not issue warnings for some TTCNâ€“3 reserved words that can appear in ASN.1 modules thus making the corresponding ASN.1 value or type field unreachable from TTCNâ€“3 . The values of type verdicttype (like `none` or `error`) and the binary operators of TTCNâ€“3 (like `not4b` or `xor4b`) were not detected and reported by the compiler.
 
-* The compiler crashed with a segmentation fault when generating code for an ASN.1 open type that did not have table constraint. This problem was introduced by a bugfix of the previous release that was about missing C++ classes related to open types. Nevertheless, an ASN.1 open type without table constraint is useless in TTCNâ€“3 because there is no way to create templates for it. The compiler now reports warnings when encountering such open types.
+* The compiler crashed with a segmentation fault when generating code for an ASN.1 open type that did not have table constraint. This problem was introduced by a bugfix of the previous release that was about missing {cpp} classes related to open types. Nevertheless, an ASN.1 open type without table constraint is useless in TTCNâ€“3 because there is no way to create templates for it. The compiler now reports warnings when encountering such open types.
 
 * The semantic analyzer of the compiler verified the arguments of built-in TTCNâ€“3 conversion functions int2hex and int2oct incorrectly. In some cases when the arguments were constants and the given value did not fit in the given length the semantic analyzer did not report any error, but the compiler aborted with an internal fatal error during constant folding while doing the conversion.
 
-* The compiler generated incorrect C\++ code for TTCNâ€“3 for loops if the boolean guard expression was constant false. In this case the entire loop was substituted with an empty C++ statement although the initial variable assignment had to be executed exactly once in all cases. The wrong code could cause problems if the initial assignment had side effects (e.g.Â it called a function or modified a variable defined outside the for loop).
+* The compiler generated incorrect C\++ code for TTCNâ€“3 for loops if the boolean guard expression was constant false. In this case the entire loop was substituted with an empty {cpp} statement although the initial variable assignment had to be executed exactly once in all cases. The wrong code could cause problems if the initial assignment had side effects (e.g.Â it called a function or modified a variable defined outside the for loop).
 
 * The compiler and the run-time environment supports the short-circuit evaluation of logical `and` and `or` operations as it is required by the TTCNâ€“3 standard. If the result of the operation can be determined based on the first (left) operand (i.e.Â the first operand is false in case of and or true in case of or) the second (right) operand will not be evaluated at all. The writer of the TTCNâ€“3 code can exploit this behavior if the right operand may have side-effects or cause a dynamic test case error.
 
@@ -1629,7 +1629,7 @@ Released on November 27, 2006.
 
 * The compiler detects if the same TTCNâ€“3 or ASN.1 input file is passed to it more than once and reports a single, but appropriate error message about this. Formerly the file was parsed and analyzed several times, the same error messages were repeated and only an error message complaining about duplicate module identifiers referred to the real problem.
 
-* The generated C++ code suffered aliasing problem in case of some TTCNâ€“3 function and altstep calls. If a component variable was passed as in parameter to a function having runs on clause and the called function modified the same variable the value of the in parameter has also changed. This behavior breaks TTCNâ€“3 semantics since in parameters shall always be passed by value. The code generator has been fixed by adding explicit copy constructor invocations at the calling side when necessary.
+* The generated {cpp} code suffered aliasing problem in case of some TTCNâ€“3 function and altstep calls. If a component variable was passed as in parameter to a function having runs on clause and the called function modified the same variable the value of the in parameter has also changed. This behavior breaks TTCNâ€“3 semantics since in parameters shall always be passed by value. The code generator has been fixed by adding explicit copy constructor invocations at the calling side when necessary.
 
 * The configuration file handler of the GUI reported syntax error and created syntactically invalid configuration file if a compound module parameter within brackets contained a typed macro reference. The problem was caused by a subroutine of the GUI that performed block auto-indentation on all configuration file entries. The algorithm did not recognize the brackets of the macro reference and inserted whitespace between the "$" and "{" characters.
 
@@ -1647,7 +1647,7 @@ Released on November 27, 2006.
 
 * The compiler checked the actual parameter of a parameterized ASN.1 assignment only when the parameter was referenced through the dummy reference. This allowed syntax and semantic errors in the actual parameters to remain hidden if the dummy reference was not used within the body of the parameterized assignment. The corrected algorithm checks all actual parameters as well as the entire instantiated assignment at the point of instantiation when processing the parameterized reference.
 
-* The generated C++ code could contain name clashes between types and values generated at the instantiation of parameterized ASN.1 assignments. The clash could occur, for example, when a parameterized information object assignment had a field setting and a parameter (dummy reference) with identical names (apart from the leading &).
+* The generated {cpp} code could contain name clashes between types and values generated at the instantiation of parameterized ASN.1 assignments. The clash could occur, for example, when a parameterized information object assignment had a field setting and a parameter (dummy reference) with identical names (apart from the leading &).
 
 [[version-1-6-pl4]]
 == Version 1.6.pl4
@@ -1716,17 +1716,17 @@ NOTE: The only possible value of these types is _{}_.
 
 * The Main Controller stopped in a deadlock in batch mode if the MTC and all alive HCs terminated at the same time and closed their control connections unexpectedly.
 
-* Empty character strings in TTCNâ€“3 pattern templates were not handled properly. The compiler accepted empty strings after the pattern keyword, but generated faulty (uncompilable) C++ code. Moreover, the run-time environment reported dynamic test case error if the pattern was empty (e.g.Â after variable substitution). Of course, empty charstring patterns are allowed and they match the empty string values only.
+* Empty character strings in TTCNâ€“3 pattern templates were not handled properly. The compiler accepted empty strings after the pattern keyword, but generated faulty (uncompilable) {cpp} code. Moreover, the run-time environment reported dynamic test case error if the pattern was empty (e.g.Â after variable substitution). Of course, empty charstring patterns are allowed and they match the empty string values only.
 
 * The TTCNâ€“3 parser of the compiler rejected array index sub-references in type references. That is why a nested unnamed type of a record of type could not be addressed. +
 
 NOTE: The array indices in type references are handled in a special way in the compiler: it is verified that the value in square brackets should be of type integer, but the number itself is not used for anything.
 
-* The compiler generated wrong (uncompilable) C\++ code for ASN.1 open types in some cases. The C++ equivalents of some types and values were missing if an unnamed information object set was used in the open typeâ€™s table constraint. This was the case, for instance, if the open type was embedded into a parameterized type assignment and the object set was defined in-line in the actual parameter list of the type reference.
+* The compiler generated wrong (uncompilable) C\++ code for ASN.1 open types in some cases. The {cpp} equivalents of some types and values were missing if an unnamed information object set was used in the open typeâ€™s table constraint. This was the case, for instance, if the open type was embedded into a parameterized type assignment and the object set was defined in-line in the actual parameter list of the type reference.
 
-* Incremental compilation of ASN.1 modules did not work properly if the instantiation of some parameterized type assignments changed since the last full re-compilation of all modules. Changing the order of files in the compilerâ€™s command line could cause similar problems. Module-based incremental compilation uses the concept that the C\++ equivalent of a module shall only depend on the module itself and the imported modules. Importing modules that use some definitions from the module must not influence the generated code. The C++ equivalents of parameterized assignments are generated when the assignment is instantiated by a parameterized reference (because only these instances can be visible from TTCNâ€“3 ). The instances are created in the module where the parameterized reference is because the actual parameters might be visible only from that module. Different instantiations of the same parameterized assignment are identified by instance counters. Earlier versions of the compiler used one instance counter for each parameterized assignment. This can cause problems when there is a parameterized assignment in module A and it is instantiated from B and C. If the number of instantiations in B changes this would change the instance counters of C. Thus the generated files of C became outdated although C does not import from B. Starting from this version the instance counters are associated with target modules. In the above example the parameterized assignment in A has two counters: one for B and another for C. This change required a new naming convention for the C\++ classes of instantiated types: the identifier of the target module became part of the name, which resulted in longer C++ identifiers.
+* Incremental compilation of ASN.1 modules did not work properly if the instantiation of some parameterized type assignments changed since the last full re-compilation of all modules. Changing the order of files in the compilerâ€™s command line could cause similar problems. Module-based incremental compilation uses the concept that the C\++ equivalent of a module shall only depend on the module itself and the imported modules. Importing modules that use some definitions from the module must not influence the generated code. The {cpp} equivalents of parameterized assignments are generated when the assignment is instantiated by a parameterized reference (because only these instances can be visible from TTCNâ€“3 ). The instances are created in the module where the parameterized reference is because the actual parameters might be visible only from that module. Different instantiations of the same parameterized assignment are identified by instance counters. Earlier versions of the compiler used one instance counter for each parameterized assignment. This can cause problems when there is a parameterized assignment in module A and it is instantiated from B and C. If the number of instantiations in B changes this would change the instance counters of C. Thus the generated files of C became outdated although C does not import from B. Starting from this version the instance counters are associated with target modules. In the above example the parameterized assignment in A has two counters: one for B and another for C. This change required a new naming convention for the C\++ classes of instantiated types: the identifier of the target module became part of the name, which resulted in longer {cpp} identifiers.
 
-* The compiler assigned wrong identifiers to some ASN.1 open type members. Open types are mapped to implicit CHOICE types and the alternatives are the distinct types from the table constraintâ€™s object set. The alternative identifiers of the CHOICE are derived from each typeâ€™s name by changing the first letter (which must always be a capital letter) to lower case. This mapping of names did not work properly if the elements of the object set were the instances of a parameterized information object assignment. For instance, different types got the same identifier (and therefore the generated C++ code was invalid) if the respective object field was a dummy reference pointing to the objectâ€™s formal parameter. When constructing open types the compiler generates a warning message if a member type has a complicated constructed name and thus the alternative will get a strange identifier. These warnings were missing too from the instances of parameterized types.
+* The compiler assigned wrong identifiers to some ASN.1 open type members. Open types are mapped to implicit CHOICE types and the alternatives are the distinct types from the table constraintâ€™s object set. The alternative identifiers of the CHOICE are derived from each typeâ€™s name by changing the first letter (which must always be a capital letter) to lower case. This mapping of names did not work properly if the elements of the object set were the instances of a parameterized information object assignment. For instance, different types got the same identifier (and therefore the generated {cpp} code was invalid) if the respective object field was a dummy reference pointing to the objectâ€™s formal parameter. When constructing open types the compiler generates a warning message if a member type has a complicated constructed name and thus the alternative will get a strange identifier. These warnings were missing too from the instances of parameterized types.
 
 * The semantic analyzer of the compiler did not accept value (character) range matching mechanisms in templates of type universal charstring.
 
@@ -1736,7 +1736,7 @@ NOTE: The array indices in type references are handled in a special way in the c
 
 * The compiler aborted with an internal fatal error when detecting an erroneous reference in the argument of built-in operations `ispresent` or `ischosen`. The proper error message was displayed before the abort.
 
-* The compiler generated wrong C++ code (which worked incorrectly) for TTCNâ€“3 function calls in very rare cases. The aliasing problem occurred if the same variable was passed to a function as both in and `inout` parameters. When the function has updated its `inout` parameter (i.e.Â the variable of the caller) the value of the in parameter has been changed although it should have been constant throughout the entire function call.
+* The compiler generated wrong {cpp} code (which worked incorrectly) for TTCNâ€“3 function calls in very rare cases. The aliasing problem occurred if the same variable was passed to a function as both in and `inout` parameters. When the function has updated its `inout` parameter (i.e.Â the variable of the caller) the value of the in parameter has been changed although it should have been constant throughout the entire function call.
 
 * The compiler aborted with an internal fatal error during the comparison of constant values of TTCNâ€“3 type objid and its ASN.1 equivalents (i.e.Â OBJECT IDENTIFIER and RELATIVE-OID). This could occur, for instance, while the compiler was checking the component relation constraints of some ASN.1 protocol modules.
 
@@ -1783,7 +1783,7 @@ Released on December 16, 2005.
 
 * TTCNâ€“3 with attributes that belong to modules or group definitions are now processed and propagated to the embedded definitions. Consistency checking of attributes and attribute qualifiers has been improved.
 
-* The compiler supports generation of `Makefiles` to be used with central storage of precompiled files. Administrators of larger projects can collect and compile the common TTCNâ€“3 and ASN.1 modules that change rarely (type definitions, test ports, etc.) in a central directory. Test developers can build their projects without re-compiling the common modules by taking the pre-compiled object files and C++ header files from the central storage. Usage of this feature can save compilation time as well as disk space for the individual developers.
+* The compiler supports generation of `Makefiles` to be used with central storage of precompiled files. Administrators of larger projects can collect and compile the common TTCNâ€“3 and ASN.1 modules that change rarely (type definitions, test ports, etc.) in a central directory. Test developers can build their projects without re-compiling the common modules by taking the pre-compiled object files and {cpp} header files from the central storage. Usage of this feature can save compilation time as well as disk space for the individual developers.
 
 * The configuration file of the run-time environment has been enhanced. Two new sections (`[INCLUDE]` and `[DEFINE]`) have been introduced. This allows modular configuration information spanning over multiple files and usage of macros and environment variables within the configuration files.
 
@@ -1825,23 +1825,23 @@ Released on December 16, 2005.
 
 *Fixed bugs*
 
-* Templates with length restrictions produced strange printout in the run-time logs due to a missing break in a C++ switch-case statement.
+* Templates with length restrictions produced strange printout in the run-time logs due to a missing break in a {cpp} switch-case statement.
 
 * The run-time location information of else if statements pointed to the wrong line of the TTCNâ€“3 code. For example, if an error occurred in the boolean expression of an else if statement the dynamic test case error message of the log file contained the line number of the first if statement. This made difficult to find the reason of the error since the first boolean expression, which the error message referred to, was correct.
 
-* The compiler generated faulty C\++ code if the last statement of a TTCNâ€“3 statement block was a select-case statement. The C++ compiler complained about that the last label of the block was not followed by a statement. The syntaxerror was corrected by adding an empty C++ statement (i.e.Â a semi-colon) after the corresponding label.
+* The compiler generated faulty C\++ code if the last statement of a TTCNâ€“3 statement block was a select-case statement. The {cpp} compiler complained about that the last label of the block was not followed by a statement. The syntaxerror was corrected by adding an empty {cpp} statement (i.e.Â a semi-colon) after the corresponding label.
 
-* The compiler crashed with a segmentation fault during code generation if the boolean expression of a TTCNâ€“3 if, for or while statement contained an in-line compound expression that could not be mapped directly to a C++ expression.
+* The compiler crashed with a segmentation fault during code generation if the boolean expression of a TTCNâ€“3 if, for or while statement contained an in-line compound expression that could not be mapped directly to a {cpp} expression.
 
 * If the actual value for a module parameter of a record of or set of type contained fewer elements in the configuration file than the default value in the TTCNâ€“3 module then the surplus elements of the default value remained present after processing the configuration file.
 
-* The compiler could produce a segmentation fault when generating the C++ structures for describing TEXT encoding of enumerated types. The reason was that the code generation subroutine addressed internal data structures in a wrong manner.
+* The compiler could produce a segmentation fault when generating the {cpp} structures for describing TEXT encoding of enumerated types. The reason was that the code generation subroutine addressed internal data structures in a wrong manner.
 
 * The expect script `*ttcn3 start*` detects if the configuration file instructs the MC to run in batch mode. Instead of causing a deadlock the script terminates with a proper error message.
 
 * The compiler aborted with an internal fatal error if a TTCNâ€“3 template reference tried to address a sub-field or element of a template (or template field) containing a generic wildcard like ? or *. Now a proper error message is printed in these circumstances.
 
-* The value comparison algorithm for set of types was not implemented in the compiler. These functions are applied during constant folding (i.e.Â when all operands of a TTCNâ€“3 expression are available at compilation time) to substitute the expression with its result in the generated C++ code. In case of set of values the comparison algorithm of record of types was applied, which could give incorrect result because it considered the order of elements.
+* The value comparison algorithm for set of types was not implemented in the compiler. These functions are applied during constant folding (i.e.Â when all operands of a TTCNâ€“3 expression are available at compilation time) to substitute the expression with its result in the generated {cpp} code. In case of set of values the comparison algorithm of record of types was applied, which could give incorrect result because it considered the order of elements.
 
 * The TTCNâ€“3 language mode of program `ctags` did not handle the string literals properly. If a TTCNâ€“3 string constant contained a special character like _{_ or _}_ `ctags` got confused and ignored the definitions in the rest of the file. Moreover, the program failed to parse character string patterns within templates.
 
@@ -1865,7 +1865,7 @@ Released on December 16, 2005.
 
 * Utility `*ttcn3 logmerge*` could cause segmentation fault if one of its arguments was a path name containing . or .., but its file name part did not contain dash (i.e. -) character.
 
-* The compiler generated invalid C\++ code if the first operand of predefined function `substr` was a charstring element. The C++ compiler complained about an ambiguous function overload.
+* The compiler generated invalid C\++ code if the first operand of predefined function `substr` was a charstring element. The {cpp} compiler complained about an ambiguous function overload.
 
 * The following bug fixes have been made on the GUI:
 
@@ -1878,7 +1878,7 @@ Released on August 1, 2005.
 
 *New features*
 
-* C++ code generation for TTCNâ€“3 interleave statements is now supported.
+* {cpp} code generation for TTCNâ€“3 interleave statements is now supported.
 
 * The compiler reports a warning if an ASN.1 identifier is a TTCNâ€“3 keyword so it is unreachable from TTCNâ€“3 . The warning is generated only if the ASN.1 identifier should be visible from TTCNâ€“3 (e.g.Â there is no warning if a named bit or an information object is identified with a TTCNâ€“3 keyword). The names of TTCNâ€“3 predefined functions are also considered to be keywords.
 
@@ -1902,7 +1902,7 @@ The compiler reported strange error messages on valid TTCNâ€“3 input if an encod
 
 * It was impossible to specify literal charstring values in RAW encoding attributes of TTCNâ€“3 types. Since the coding with attribute is delimited with quotation mark characters the beginning and end of the embedded string has to be escaped (i.e.Â the quotation mark character shall be preceded with a backslash or a double quotation mark character shall be used). However, the attribute parser of the compiler used a wrong regular expression, it expected a single quotation mark character as delimiters in charstring literals.
 
-* The code generator of the RAW enc/dec did not prefix the enumerated values if the `-E` (enum-hack) compiler switch was turned on. Thus the generated C++ code did not compile in this case.
+* The code generator of the RAW enc/dec did not prefix the enumerated values if the `-E` (enum-hack) compiler switch was turned on. Thus the generated {cpp} code did not compile in this case.
 
 * The documentation of RAW attribute `PRESENCE` contained a mistake in syntax description. The attribute parser of the compiler required a pair of brackets for multiple values, but the documentation does not. Now the parser accepts both syntax variants to preserve backward compatibility.
 
@@ -1979,9 +1979,9 @@ Released on June 30, 2005.
 
 * The compiler aborted with an internal fatal error when checking a TTCNâ€“3 expression (or sub-expression) if all operands of an arithmetic or logical operation were available at compilation timefootnote:[The operands were literal values or references pointing to constants.] and one of the operands was a referenced value pointing to a TTCNâ€“3 constant of type float or ASN.1 value of type REAL.
 
-* The generated C\++ code was uncompilable if the name of an ASN.1 built-in string type (e.g.Â UTF8String) was used as identifier in a TTCNâ€“3 module or the name of a TTCNâ€“3 built-in conversion function (e.g.Â bit2int) was used as ASN.1 identifier. Now the compiler appends a single underscore character to the C++ equivalents of these identifiers to avoid name clashes with the definitions of the Base Library.
+* The generated C\++ code was uncompilable if the name of an ASN.1 built-in string type (e.g.Â UTF8String) was used as identifier in a TTCNâ€“3 module or the name of a TTCNâ€“3 built-in conversion function (e.g.Â bit2int) was used as ASN.1 identifier. Now the compiler appends a single underscore character to the {cpp} equivalents of these identifiers to avoid name clashes with the definitions of the Base Library.
 
-* The compiler caused segmentation fault during semantic analysis if the type of a constant or module parameter was erroneous (e.g.Â the referenced type was not imported) and the value of the constant or the default value of the module parameter contained an embedded record or set value (i.e.Â a value with TTCNâ€“3 assignment notation). The problem occurred after reporting the relevant error message and only if when C++ code generation was requested (i.e.Â the command line switch `-s` was not used).
+* The compiler caused segmentation fault during semantic analysis if the type of a constant or module parameter was erroneous (e.g.Â the referenced type was not imported) and the value of the constant or the default value of the module parameter contained an embedded record or set value (i.e.Â a value with TTCNâ€“3 assignment notation). The problem occurred after reporting the relevant error message and only if when {cpp} code generation was requested (i.e.Â the command line switch `-s` was not used).
 
 * The GUI crashed at startup with segmentation fault if the environment variable TTCN3 DIR was not set or the configuration files and images were not found under `$TTCN3 DIR/etc/gui`.
 
@@ -1989,7 +1989,7 @@ Released on June 30, 2005.
 
 * The semantic analysis did not detect when a variable defined in the header of a TTCNâ€“3 for statement shadowed a definition in an outer scope unit with the same identifier.
 
-* The compiler generated invalid code if the argument of a TTCNâ€“3 `send` operation referred to an optional field of a record or set value (constant, variable, module parameter, etc.). The C++ compiler complained about ambiguous overload of a member function in the port class.
+* The compiler generated invalid code if the argument of a TTCNâ€“3 `send` operation referred to an optional field of a record or set value (constant, variable, module parameter, etc.). The {cpp} compiler complained about ambiguous overload of a member function in the port class.
 
 * The Main Controller caused segmentation fault in both command-line and GUI modes if the `stop` command was issued while a control part was running and no testcase was executed before.
 
@@ -2003,9 +2003,9 @@ Released on June 30, 2005.
 
 * The semantic analyzer of the compiler reported wrong circular recursion error message if a template reference in a function or testcase contained an array sub-reference the index of which was not constant. For example, this was the case when a for loop iterated through the elements of a record of template or template variable.
 
-* The compiler accepted any kinds of expressions (not only the boolean ones) in if, for, while and do-while statements because of a programming mistake in the semantic analyzer. Moreover, in most cases the generated C++ code was compilable (thus the problem remained hidden) if the type of the expression was a built-in TTCNâ€“3 type (e.g.Â charstring).
+* The compiler accepted any kinds of expressions (not only the boolean ones) in if, for, while and do-while statements because of a programming mistake in the semantic analyzer. Moreover, in most cases the generated {cpp} code was compilable (thus the problem remained hidden) if the type of the expression was a built-in TTCNâ€“3 type (e.g.Â charstring).
 
-* The compiler generated wrong (uncompilable) C++ code if the boolean expression of a if, for, while or do-while statement referred to an optional boolean field of a record or set value.
+* The compiler generated wrong (uncompilable) {cpp} code if the boolean expression of a if, for, while or do-while statement referred to an optional boolean field of a record or set value.
 
 * The semantic analyzer routine of the compiler that checks the length restriction of templates contained several bugs. In certain cases this could cause segmentation faults or aborts in the compiler or the acceptance of invalid inputs. For example, the bugs could be triggered with the following constructs: length ranges with infinity as upper limit, length restrictions for the universal charstring type, length restrictions combined with specific string values.
 
@@ -2028,7 +2028,7 @@ Released on April 1, 2005.
 
 * The compiler supports semantic checking for the dynamic parts of TTCNâ€“3 modules. This means that TTCNâ€“3 modules are entirely covered with semantic analysis.
 
-* The compiler generates the entire C++ code from the output of semantic analysis, the so-called Abstract Syntax Tree (AST).
+* The compiler generates the entire {cpp} code from the output of semantic analysis, the so-called Abstract Syntax Tree (AST).
 
 * The TTCNâ€“3 parser of the compiler supports error recovery, that is, it does not stop when a syntax error is detected, but it tries to read the further parts of the input and perform semantic analysis as well. However, in some cases it is not possible or worth-while to recover from a syntax error.
 
@@ -2064,7 +2064,7 @@ Released on April 1, 2005.
 
 * In some cases the compiler aborted with an internal fatal error when checking modified templates for record of or set of types. This was the case, for instance, if the base template contained a generic wildcard like ? or *.
 
-* The compiler generated invalid (uncompilable) C\++ code for `getcall` operations if the corresponding signature was imported from another module. This was because the default arguments of the C++ function that handles `param` redirects for the respective signature were generated into the source file instead of the header file and thus remained invisible for other modules.
+* The compiler generated invalid (uncompilable) C\++ code for `getcall` operations if the corresponding signature was imported from another module. This was because the default arguments of the {cpp} function that handles `param` redirects for the respective signature were generated into the source file instead of the header file and thus remained invisible for other modules.
 
 * The code generator of the compiler ignored the `NotUsedSymbol` characters in `param` redirect of `getcall` and `getreply` operations if the `VariableList` notation was used. Thus the run-time environment assigned the wrong parameters to the given variables.
 
@@ -2074,19 +2074,19 @@ Released on April 1, 2005.
 
 * The compiler rejected the `call` operations that did not have response and exception handling part with an error message even if the corresponding signature was a nonblocking one (i.e.Â it was defined with the `noblock` keyword).
 
-* The compiler generated invalid (uncompilable) C++ code for those in-line signature templates the signature of which had no parameters.
+* The compiler generated invalid (uncompilable) {cpp} code for those in-line signature templates the signature of which had no parameters.
 
-* The compiler did not generate the C++ equivalents of some data types thus the generated code was uncompilable because of missing classes if an ASN.1 PDU type was defined using an object set, which was imported from another ASN.1 module.
+* The compiler did not generate the {cpp} equivalents of some data types thus the generated code was uncompilable because of missing classes if an ASN.1 PDU type was defined using an object set, which was imported from another ASN.1 module.
 
 * All generated header files included `version.h` from the Base Library, which made it impossible to use the precompiled headers created by GCC 3.4 or above. The above file contains some preprocessor statements, which disable the processing of existing precompiled headers in further `#include` directives.
 
 * The compiler did not accept the `NotUsedSymbol` in the default duration of timer arrays. The symbol means that the corresponding array element shall have no default duration.
 
-* The compiler might generate invalid (uncompilable) code for the TTCNâ€“3 functions that had signature template parameters. The C++ compiler complained about missing encode text and decode text functions, which are used when the corresponding function is being started as a PTC behavior.
+* The compiler might generate invalid (uncompilable) code for the TTCNâ€“3 functions that had signature template parameters. The {cpp} compiler complained about missing encode text and decode text functions, which are used when the corresponding function is being started as a PTC behavior.
 
 * The compiler did not recognize properly the default syntax for ASN.1 objects. If an object class did not have user defined syntax the compiler rejected the valid object definitions with strange parse error messages.
 
-* The semantic analyzer did not detect errors in procedure based port types. For example, a reference to a non-existent signature in the incoming or outgoing list resulted in an erroneous (uncompilable) output C++ code.
+* The semantic analyzer did not detect errors in procedure based port types. For example, a reference to a non-existent signature in the incoming or outgoing list resulted in an erroneous (uncompilable) output {cpp} code.
 
 * Our run-time environment implements the TTCNâ€“3 entity that runs the control part and the MTC in the same process. The lists of active timers and defaults were not separated between the two entities thus the testcase could access and modify the control part timers and defaults. For instance, the statement all `timer.stop` in the testcase stopped the active timers of the control part as well.
 
@@ -2096,9 +2096,9 @@ Released on April 1, 2005.
 
 * The predefined conversion functions str2int and str2float in the run-time environment accepted some invalid input strings. For instance if the numbers were followed by letters in the input string the numbers were converted and the remaining letters were silently ignored. Now these functions accept only valid inputs containing a valid integer or float value. An invalid input causes dynamic testcase error.
 
-* The compiler generated invalid (uncompilable) C++ code if the component reference in the `connect`, `disconnect`, `map` or `unmap` operation referred to an optional field of a record or set value because there was no conversion function to perform the implicit cast.
+* The compiler generated invalid (uncompilable) {cpp} code if the component reference in the `connect`, `disconnect`, `map` or `unmap` operation referred to an optional field of a record or set value because there was no conversion function to perform the implicit cast.
 
-* The compiler aborted with a segmentation fault or similar error when trying to generate C++ code for the initial value of a component variable, which contained a `valueof` operation. Such constructs usually appear in the output of the TTCNâ€“2 to TTCNâ€“3 converter.
+* The compiler aborted with a segmentation fault or similar error when trying to generate {cpp} code for the initial value of a component variable, which contained a `valueof` operation. Such constructs usually appear in the output of the TTCNâ€“2 to TTCNâ€“3 converter.
 
 * The utility `*ttcn3 logmerge*` reported memory leaks when the operating systemâ€™s limit for the maximum number of simultaneously open files was smaller than the number of input files. In this case the log merge utility has to create temporary files in order to perform the merge in several steps. When the temporary file was closed the internal memory structure associated to it was not deallocated. Apart from the warning this bug had no other side effects.
 
@@ -2108,15 +2108,15 @@ Released on April 1, 2005.
 
 * The Main Controller entered an infinite loop and flooded the console with an endless sequence of error messages if the operating systemâ€™s limit of simultaneously open files was reached. This could happen when accepting the control TCP connections of newly created test components during load testing. The problem occurred on Solaris platform only. The reason was that the error codes of operating system calls were retrieved in an improper way and MC did not recognize the above situation.
 
-* If a literal value of TTCNâ€“3 float type caused an overflow in the internal memory representationfootnote:[TTCNâ€“3 float and ASN.1 REAL values are represented in the double type of the C/C++ language,which is mapped to 64-bit floating point numbers on most platforms.] the compiler stopped immediately with an internal fatal error during the parsing phase. Such situations are now handled properly and the compiler can continue its run after producing the appropriate error message.
+* If a literal value of TTCNâ€“3 float type caused an overflow in the internal memory representationfootnote:[TTCNâ€“3 float and ASN.1 REAL values are represented in the double type of the C/{cpp} language,which is mapped to 64-bit floating point numbers on most platforms.] the compiler stopped immediately with an internal fatal error during the parsing phase. Such situations are now handled properly and the compiler can continue its run after producing the appropriate error message.
 
 * The compiler aborted with an internal fatal error during code generation when it encountered a reference pointing to an element of a string value within template bodies or in the initial value of component variables. The code generator tried to follow the type of the embedded value and it handled the string element index in the same way as the indices of array and record of types.
 
 * The run-time environment did not handle the variable assignments for record of and set of types properly. If the newly assigned value had fewer elements than the previous value of the variable the extra elements at the end were not erased from the variable. For example, if a variable contained three elements and the newly assigned value had only two, the new value of the variable had incorrectly three elements: the first two from the new value and the third one from the old value. This problem was present regardless whether the embedded type was a built-in or a user defined type or the extra values were bound or not. The effects of this bug were the most strange if a component variable of the MTC was initialized in the component type definition and several test cases were executed after each other.
 
-* The run-time environment caused dynamic test case error if an optional component of an ASN.1 `SEQUENCE` or `SET` type, the type of which was the ANY type, was assigned to an optional octetstring field of a TTCNâ€“3 `record` or `set` type and the source field contained omit value. The appropriate C\++ member function was missing and the C++ compiler performed an implicit conversion, which assumed that the value of the source field is present.
+* The run-time environment caused dynamic test case error if an optional component of an ASN.1 `SEQUENCE` or `SET` type, the type of which was the ANY type, was assigned to an optional octetstring field of a TTCNâ€“3 `record` or `set` type and the source field contained omit value. The appropriate C\++ member function was missing and the {cpp} compiler performed an implicit conversion, which assumed that the value of the source field is present.
 
-* In case of some valid, but sophisticated TTCNâ€“3 or ASN.1 type recursion loops the compiler did not produce the equivalent C++ classes in the right bottom-up order. Thus the generated code was uncompilable because of forward referencing of incomplete types.
+* In case of some valid, but sophisticated TTCNâ€“3 or ASN.1 type recursion loops the compiler did not produce the equivalent {cpp} classes in the right bottom-up order. Thus the generated code was uncompilable because of forward referencing of incomplete types.
 
 * The Main Controller could report memory leaks if the configuration file passed to it contained syntax errors.
 
@@ -2124,9 +2124,9 @@ Released on April 1, 2005.
 
 * The compiler aborted with an internal fatal error during semantic analysis if the base template of a modified union template did not contain a specific value (e.g.Â it was a generic wildcard like "?").
 
-* The generated C\++ code was uncompilable if an indexed element of a string value was assigned to a template. The C++ compiler complained about ambiguous function overloads in case of all string types (i.e.Â bitstring, hexstring, octetstring, charstring and universal charstring).
+* The generated C\++ code was uncompilable if an indexed element of a string value was assigned to a template. The {cpp} compiler complained about ambiguous function overloads in case of all string types (i.e.Â bitstring, hexstring, octetstring, charstring and universal charstring).
 
-* The generated C\++ code was uncompilable if an operand of a built-in TTCNâ€“3 arithmetic, logical or string operation was a reference pointing to an optional field of a record or set value. The problem was present in case of all TTCNâ€“3 operations that are mapped to infix C++ operators.
+* The generated C\++ code was uncompilable if an operand of a built-in TTCNâ€“3 arithmetic, logical or string operation was a reference pointing to an optional field of a record or set value. The problem was present in case of all TTCNâ€“3 operations that are mapped to infix {cpp} operators.
 
 * The HC logs contained incorrect information about the exit status of the test component if the corresponding UNIX process was terminated by a signal. In this case the log file showed a successful (zero) exit status although the process was aborted by a fatal error. Now the HC distinguishes between normal and abnormal process termination and reports the signal number instead of exit status in the latter case.
 
@@ -2145,7 +2145,7 @@ Released on November 5, 2004.
 
 * The verification algorithm of `USER` limited licenses became more robust. Formerly only a reverse lookup was performed based on the numerical user ID (UID) of the process and the license was rejected if the UID was mapped to a login name different from that of the license file. Now, if this step fails a forward lookup is also performed on the login name of the license file. If the resulting UID matches the process UID the license is accepted. This makes the user name limited licensing working on UNIX systems where several login names are mapped to the same UID (e.g.Â portable Linux laptops with both local users and NIS membership). On such systems the reverse lookup returns one of the login names randomly.
 
-* The compiler generates the equivalent C++ code of TTCNâ€“3 templates based on the output of semantic analysis. This means the following enhancements:
+* The compiler generates the equivalent {cpp} code of TTCNâ€“3 templates based on the output of semantic analysis. This means the following enhancements:
 
 * The compiler automatically re-arranges the initialization sequences for nonparameterized templates in case of forward referencing. It is not mandatory anymore to place such templates in bottom-up order in the module.
 
@@ -2167,7 +2167,7 @@ Released on November 5, 2004.
 
 * The run-time environment executes the `EndTestCase` command, which is specified in section `[EXTERNAL COMMANDS]` of configuration file, after writing the verdict of test case into the log. Thus the external command can extract this verdict from the logand act accordingly.
 
-* The C++ mapping of TTCNâ€“3 and ASN.1 import statements has been improved. These updates make the generated code compatible with the limitations of GCC 3.4 or above that are in place when precompiled header files are used. The following changes were implemented:
+* The {cpp} mapping of TTCNâ€“3 and ASN.1 import statements has been improved. These updates make the generated code compatible with the limitations of GCC 3.4 or above that are in place when precompiled header files are used. The following changes were implemented:
 
 * The #include directives are generated in the same order as the import statements are placed in the source module. This allows the explicit control which header file to be included first.
 
@@ -2179,7 +2179,7 @@ Released on November 5, 2004.
 
 * Logging of timers is now supported. That is, a reference to a timer can be an argument of a `TTCNâ€“3 log()` statement. When executing the statement the attributes of the timer (state, default and actual duration, elapsed time) are printed into the log.
 
-* If the executable tests are built with GCC the C++ compiler will perform extra checks on the arguments of Base Library functions that have printf-like syntax. The variable arguments of `TTCN error()`, `TTCN warning()`, `TTCN Logger::log()`, `TTCN Logger::log event()`, etc. are verified against the format string. New warning messages may be displayed during the compilation of Test Ports and external functions if type mismatches are found.
+* If the executable tests are built with GCC the {cpp} compiler will perform extra checks on the arguments of Base Library functions that have printf-like syntax. The variable arguments of `TTCN error()`, `TTCN warning()`, `TTCN Logger::log()`, `TTCN Logger::log event()`, etc. are verified against the format string. New warning messages may be displayed during the compilation of Test Ports and external functions if type mismatches are found.
 
 * Log Browser now is able to determine the component name from the log file name.
 
@@ -2209,15 +2209,15 @@ Released on November 5, 2004.
 
 * If a TTCNâ€“3 or ASN.1 integer constant was so large that it did not fit in the internal memory representation of the compiler (actually 64-bit signed integers are used) the compiler stopped immediately with an internal fatal error during parsing. Such overflow situations now produce regular error messages and the compiler can continue analyzing the input.
 
-* The compiler generated erroneous (uncompilable) C++ code for type alias definitions of port types and signatures.
+* The compiler generated erroneous (uncompilable) {cpp} code for type alias definitions of port types and signatures.
 
 * The configuration file parser of the run-time environment accepted some invalid DNS names in section `[GROUPS]`. However, some valid names (e.g.Â names containing the dash character or having parts containing numbers only) were rejected.
 
 * Circular recursions within parameterized template references could lead to infinite recursions in the compiler. A typical example for this situation: the body of a nonparameterized template refers to a parameterized template and one of the actual parameters is a reference to the non-parameterized template itself.
 
-* In some very rare cases the compiler generated invalid C++ code for message based port types. Data was read from an uninitialized memory location and in case of a specific bit pattern the compiler called both the message based and the procedure based code generator for the same port type.
+* In some very rare cases the compiler generated invalid {cpp} code for message based port types. Data was read from an uninitialized memory location and in case of a specific bit pattern the compiler called both the message based and the procedure based code generator for the same port type.
 
-* The compiler generated wrong (uncompilable) C++ code if a TTCNâ€“3 charstring value contained non-printable characters. Such characters were created during constant folding (e.g.Â the output of function `int2char`, which was evaluated by the compiler).
+* The compiler generated wrong (uncompilable) {cpp} code if a TTCNâ€“3 charstring value contained non-printable characters. Such characters were created during constant folding (e.g.Â the output of function `int2char`, which was evaluated by the compiler).
 
 * Some compiler error messages reporting invalid RAW attributes printed memory garbage instead of TTCNâ€“3 identifiers.
 
@@ -2278,9 +2278,9 @@ Released on September 20, 2004.
 
 * The compiler reported memory leak at termination if it encountered a `self.stop` or `mtc.stop` statement in its input module(s). A small memory block was not deallocated during the parsing of these constructs. This mistake had no other harmful side-effects.
 
-* The compiler generated invalid C\++ code if a TTCNâ€“3 `activate` operation was used as a function statement. This construct was introduced in the most recent BNF and the newly written code generator forgot to put a semi-colon at the end of the equivalent C++ statement.
+* The compiler generated invalid C\++ code if a TTCNâ€“3 `activate` operation was used as a function statement. This construct was introduced in the most recent BNF and the newly written code generator forgot to put a semi-colon at the end of the equivalent {cpp} statement.
 
-* If a TTCNâ€“3 or ASN.1 module contained an enumerated type and it was imported into another TTCNâ€“3 module using the undocumented `"light" extension` attribute the C\++ equivalent of the importing module was uncompilable. This option disables the processing of some sections of the imported C++ header file from the importing module by using the C preprocessor to reduce the compilation time for large projects. The masked section contains mainly the C\++ equivalent classes of data types and in this case some in-line enumerated conversion functions in another (active) section referred to class members, which were invisible from the C++ translation unit of the importing module.
+* If a TTCNâ€“3 or ASN.1 module contained an enumerated type and it was imported into another TTCNâ€“3 module using the undocumented `"light" extension` attribute the C\++ equivalent of the importing module was uncompilable. This option disables the processing of some sections of the imported {cpp} header file from the importing module by using the C preprocessor to reduce the compilation time for large projects. The masked section contains mainly the C\++ equivalent classes of data types and in this case some in-line enumerated conversion functions in another (active) section referred to class members, which were invisible from the {cpp} translation unit of the importing module.
 
 * The compiler did not accept the hexadecimal string notation in ASN.1 modules for the values of the ANY type.
 
@@ -2300,11 +2300,11 @@ Released on September 20, 2004.
 
 * The compiler aborted with an internal fatal error during error recovery (i.e.Â after reporting the error) if an invalid `SEQUENCE` notation was used for an ASN.1 REAL value.
 
-* The generated C\++ code could be uncompilable due to ambiguous function overloads in the class that implements TTCNâ€“3 port types if the support of address type was turned on (i.e.Â the extension attribute `address` was used in the port type). The problem appeared only if the port type had outgoing messages or signatures and the address type was aliased to a built-in type the C++ equivalent class of which had a constructor with `int` parameter (e.g.`Â integer`, objid and all string types). The reason was a missing explicit cast in a generated function and the C++ compiler could not distinguish between component references and address values.
+* The generated C\++ code could be uncompilable due to ambiguous function overloads in the class that implements TTCNâ€“3 port types if the support of address type was turned on (i.e.Â the extension attribute `address` was used in the port type). The problem appeared only if the port type had outgoing messages or signatures and the address type was aliased to a built-in type the {cpp} equivalent class of which had a constructor with `int` parameter (e.g.`Â integer`, objid and all string types). The reason was a missing explicit cast in a generated function and the {cpp} compiler could not distinguish between component references and address values.
 
-* The compiler produced invalid C++ code if the to clause was present in a TTCNâ€“3 `raise` port operation. The generated code contained an unnecessary extra closing parenthesis.
+* The compiler produced invalid {cpp} code if the to clause was present in a TTCNâ€“3 `raise` port operation. The generated code contained an unnecessary extra closing parenthesis.
 
-* The semantic analyzer of the compiler did not report error if it encountered a length restriction or `ifpresent` matching mechanism in an actual value parameter of a template or function. It simply ignored the extra matching attributes and analyzed the specific value only. The generated C++ code was uncompilable in these cases.
+* The semantic analyzer of the compiler did not report error if it encountered a length restriction or `ifpresent` matching mechanism in an actual value parameter of a template or function. It simply ignored the extra matching attributes and analyzed the specific value only. The generated {cpp} code was uncompilable in these cases.
 
 * The special component references such as `null`, `mtc`, `system` and `self` were not handled in component `start` operations. Thus the run-time error messages were cryptic when the argument of start was one of the above.
 
@@ -2339,7 +2339,7 @@ Released on September 20, 2004.
 
 * It is allowed to pass template parameters to functions, `altsteps` and `testcases` by reference. Those parameters are denoted by the keywords `out` or `inout` similarly to value parameters. The actual parameters shall be template variables.
 
-* The conversion functions related to enumerated types are no longer global C functions. They were moved to static members of the value class. This makes easier to write generic C++ template functions in Test Ports that can handle any enumerated type.
+* The conversion functions related to enumerated types are no longer global C functions. They were moved to static members of the value class. This makes easier to write generic {cpp} template functions in Test Ports that can handle any enumerated type.
 
 * The script `*ttcn3 start*` handles the configuration files automatically. If it finds a file named `<ETS name>.cfg` in its current working directory it passes the file to MC as a command line argument.
 
@@ -2355,7 +2355,7 @@ Released on September 20, 2004.
 
 * The type descriptor needed for the RAW encoding of the boolean type was missing from the run-time environment. This resulted in segmentation fault if a message containing a boolean field was encoded or decoded.
 
-* The compiler accepted an invalid syntax for catching timeout on procedure based ports. The string `catch timeout` was interpreted as a `catch` operation in addition to the standard `PortReference.catch(timeout)` notation. Moreover, the standard syntax produced invalid C\++ output, only the irregular variant resulted in working code. Only the standard syntax is accepted from now, and it is translated to a valid C++ code.
+* The compiler accepted an invalid syntax for catching timeout on procedure based ports. The string `catch timeout` was interpreted as a `catch` operation in addition to the standard `PortReference.catch(timeout)` notation. Moreover, the standard syntax produced invalid C\++ output, only the irregular variant resulted in working code. Only the standard syntax is accepted from now, and it is translated to a valid {cpp} code.
 
 * The compiler returned a misleading successful (zero) exit status if it encountered a general problem with an input file (e.g.Â the file could not be opened or classified as a TTCNâ€“3 or ASN.1 module).
 
@@ -2370,7 +2370,7 @@ Released on April 30, 2004.
 
 * The compiler is able to generate `Makefiles` to be used in single mode with the newly introduced command line switch `-s`.
 
-* The `Makefile` generator of the compiler recognizes if a given C++ source file is generated from one of the TTCNâ€“3 or ASN.1 modules. In this case a warning is issued and the given file is not added to the list of USER SOURCES.
+* The `Makefile` generator of the compiler recognizes if a given {cpp} source file is generated from one of the TTCNâ€“3 or ASN.1 modules. In this case a warning is issued and the given file is not added to the list of USER SOURCES.
 
 * The compiler became less strict regarding the usage of semi-colons within `TTCNâ€“3modulepar` blocks. The compiler treats the semi-colons optional, but it issues a warning if the input does not conform to the standard TTCNâ€“3 BNF.
 
@@ -2390,7 +2390,7 @@ Released on April 30, 2004.
 
 * If the compiler generated a `Makefile` to be used with GNU make and all user source files had the `.cc` suffix, but one or more of them did not have its own header file, the suffix substitution rule was not used to obtain the list of object files. In this case only the user header files have to be explicitly enumerated, the names of object files do not need to be enumerated.
 
-* The `sizeof` built-in function could not be used on optional record or set fields (or their ASN.1 equivalents) if the type of the field was a `record of` or `set of` type. The generated C++ code did not compile in these cases, the compiler complained about no matching function.
+* The `sizeof` built-in function could not be used on optional record or set fields (or their ASN.1 equivalents) if the type of the field was a `record of` or `set of` type. The generated {cpp} code did not compile in these cases, the compiler complained about no matching function.
 
 * If the body of a parameterized template used a formal parameter with field or array sub-references, the compiler evaluated the type of the reference expression incorrectly and thus reported type mismatches on valid templates. For instance, if the type of a formal parameter was a record with an integer field then the compiler assumed that the type of the formal parameter reference with the field sub-reference is the record type and not integer.
 
@@ -2398,8 +2398,8 @@ Released on April 30, 2004.
 
 * The ASN.1 parser of the compiler did not consider the default tagging method correctly. If an embedded block (e.g.Â a `CHOICE` type) contained tagged types, the compiler decided whether to use implicit or explicit tags based on the default tagging method of the lastly parsed ASN.1 module instead of the current module. The problem was visible only if the input ASN.1 modules did not use the same default tagging method, which happens rarely.
 
-* The type descriptor structures in the Base Library were not declared for TTCNâ€“3 type universal charstring. This caused compilation errors in the generated C++ code if the universal charstring type was embedded into a record, set or union type. The problem did not affect the ASN.1 character string types.
-* The precedence requirements for RAW attributes `PRESENCE` and `CROSSTAG` were not checked at compilation. Such kinds of errors caused dynamic test case errors (i.e.Â when the field that determines the presence or selection of another field is encoded at a later position in the message than the field it points to). These problems are now detected by the compiler and no C++ code is generated for faulty types.
+* The type descriptor structures in the Base Library were not declared for TTCNâ€“3 type universal charstring. This caused compilation errors in the generated {cpp} code if the universal charstring type was embedded into a record, set or union type. The problem did not affect the ASN.1 character string types.
+* The precedence requirements for RAW attributes `PRESENCE` and `CROSSTAG` were not checked at compilation. Such kinds of errors caused dynamic test case errors (i.e.Â when the field that determines the presence or selection of another field is encoded at a later position in the message than the field it points to). These problems are now detected by the compiler and no {cpp} code is generated for faulty types.
 
 * The utility `*ttcn3 logformat*` did not interpret the command line switch `-s` properly (i.e.Â it did not split up the log of each test case into separate files) if the input log file contained location information. The logformat utility supports now also the newly introduced location information formats (stack traces, etc.).
 
@@ -2485,7 +2485,7 @@ NOTE: Although it is trivial to show a possible successful matching, it is very
 
 *Fixed bugs*
 
-* If the `-E` (enum-hack) switch was used the compiler generated invalid C\++ code for those ASN.1 enumerated values that are keywords in both TTCNâ€“3 and C++ languages (e.g.Â true).
+* If the `-E` (enum-hack) switch was used the compiler generated invalid C\++ code for those ASN.1 enumerated values that are keywords in both TTCNâ€“3 and {cpp} languages (e.g.Â true).
 
 * If an ASN.1 `SEQUENCE`, `SET` or `CHOICE` type definition contained a syntax error the error recovery routines of the compiler did not work properly. Thus the compiler could fail with internal error messages or produce memory leaks later during the semantic analysis.
 
@@ -2501,7 +2501,7 @@ NOTE: Although it is trivial to show a possible successful matching, it is very
 
 * If a RAW encoding attribute of a TTCNâ€“3 type contained a syntax error the file name in the compiler error message pointed to the lastly parsed TTCNâ€“3 file instead of the faulty one. Only the line number information was correct. Moreover, the error message did not contain the reason of the error.
 
-* The compiler generated invalid C++ code if the `PRESENCE` RAW attributes contained nested field references.
+* The compiler generated invalid {cpp} code if the `PRESENCE` RAW attributes contained nested field references.
 
 * If a TTCNâ€“3 default reference was logged, which has already deactivated, the `log()` statement could have unpredictable results (e.g.Â segmentation fault, irrelevant printout, etc.)
 
@@ -2522,7 +2522,7 @@ Released on January 23, 2004.
 
 * The elements of bitstring, hexstring, octetstring and charstring values, which can be accessed using an array-like syntax, can now be logged by TTCNâ€“3 `log()` statements. In previous versions the `log()` statement printed nothing for string element arguments.
 
-* The compiler now gives warning messages if there are circular import chains at module level, e.g.Â module A imports things from module B, module B imports another things from module C and module C imports something from module A. This is legal in both ASN.1 and TTCNâ€“3 , but the generated C++ code might be uncompilable.
+* The compiler now gives warning messages if there are circular import chains at module level, e.g.Â module A imports things from module B, module B imports another things from module C and module C imports something from module A. This is legal in both ASN.1 and TTCNâ€“3 , but the generated {cpp} code might be uncompilable.
 
 * `GeneralizedTime` and `UTCTime` have been prefixed with ASN in the library because also OSS library uses these identifiers. This prefix is consistent with some other type names (e.g.Â `ASN NULL`).
 
@@ -2532,11 +2532,11 @@ Released on January 23, 2004.
 
 * The compiler issued irrelevant error messages for modified templates if the base template had formal parameter list. The error message complained about missing actual parameter lists, but the actual parameters of the base template shall not be specified according to TTCNâ€“3 syntax.
 
-* The compiler aborted with an internal fatal error if the base template reference of a modified template pointed to a definition other than a template. _â€¢_ The compiler generated invalid C\++ code for some ASN.1 constructs if the enumhack (`-E`) option was used. If an ASN.1 type contained an embedded (unnamed) ENUMERATED type the C++ `enum` values were incorrectly prefixed in value assignments for such types.
+* The compiler aborted with an internal fatal error if the base template reference of a modified template pointed to a definition other than a template. _â€¢_ The compiler generated invalid C\++ code for some ASN.1 constructs if the enumhack (`-E`) option was used. If an ASN.1 type contained an embedded (unnamed) ENUMERATED type the {cpp} `enum` values were incorrectly prefixed in value assignments for such types.
 
-* The compiler crashed with a segmentation fault if an actual parameter of an altstep invocation contained an in-line compound expression. The C\++ mapping of such constructs is still unsolved due to the lack of full semantic analysis. The compiler now continues the parsing and substitutes the unsupported parameter with the comment /* NOT SUPPORTED */ in the output code, which will cause a C++ compilation error.
+* The compiler crashed with a segmentation fault if an actual parameter of an altstep invocation contained an in-line compound expression. The C\++ mapping of such constructs is still unsolved due to the lack of full semantic analysis. The compiler now continues the parsing and substitutes the unsupported parameter with the comment /* NOT SUPPORTED */ in the output code, which will cause a {cpp} compilation error.
 
-* The compiler generated erroneous C\++ code for certain legal TTCNâ€“3 constructs. Let us assume that the name P was used to identify a component variable in component type A. If a function, altstep or testcase had a runs on clause other than A and a formal parameter named `P` the resulting C++ code did not compile if parameter `P` was used in the function body. The reason is that the TTCNâ€“3 component type scoping is solved using tricky C preprocessor macros in the generated code. Due to the wrong placement of preprocessor statements different name substitution rules were applied on formal parameter list and function body.
+* The compiler generated erroneous C\++ code for certain legal TTCNâ€“3 constructs. Let us assume that the name P was used to identify a component variable in component type A. If a function, altstep or testcase had a runs on clause other than A and a formal parameter named `P` the resulting {cpp} code did not compile if parameter `P` was used in the function body. The reason is that the TTCNâ€“3 component type scoping is solved using tricky C preprocessor macros in the generated code. Due to the wrong placement of preprocessor statements different name substitution rules were applied on formal parameter list and function body.
 
 * If the user `unmap` function of a Test Port called Install Handler the event handler could remain active after the deactivation of the port. This could result in unexpected Event Handler calls and warnings when the test component terminated.
 
@@ -2593,19 +2593,19 @@ Released on December 19, 2003.
 
 * The load balancing algorithm in the Main Controller did not count the MTC when choosing a location for a newly created PTC. For instance, if a test configuration, which required 3 PTCs, was distributed on two hosts it happened that the first host ran 2 PTCs in addition to the MTC while the second host had only one PTC.
 
-* The compiler generated invalid C++ code for TTCNâ€“3 constants that referred to a sub-field of another constant (or ASN.1 value), which was imported from another module.
+* The compiler generated invalid {cpp} code for TTCNâ€“3 constants that referred to a sub-field of another constant (or ASN.1 value), which was imported from another module.
 
 * Use of TTCNâ€“3 subtype constraints (e.g.Â value lists or length restrictions) caused memory leakage in the compiler if it was invoked with the `-p` (parse only) option. The memory responsibilities were incorrectly assigned in the syntax tree if the semantic analysis was bypassed.
 
 * The parse errors in ASN.1 modules (or embedded blocks within ASN.1 definitions) caused memory leaks within the compiler.
 
-* Compound templates (both with value list and assignment notation) were accepted by the compiler for objid and ASN.1 NULL types. The C++ code generated from such invalid input was also erroneous, of course.
+* Compound templates (both with value list and assignment notation) were accepted by the compiler for objid and ASN.1 NULL types. The {cpp} code generated from such invalid input was also erroneous, of course.
 
 * When a modified template was written for a union type, which contained an embedded record the compiler did not allow missing fields for the inner record even if the same alternative of the union was selected as in the base template.
 
 * References to parameterized TTCNâ€“3 entities (i.e.Â templates or functions) were accepted by the compiler without actual parameter lists in template bodies.
 
-* If a statement block within a TTCNâ€“3 altstep contained local variable definitions the generated C++ code did not compile because of a missing pair of brackets.
+* If a statement block within a TTCNâ€“3 altstep contained local variable definitions the generated {cpp} code did not compile because of a missing pair of brackets.
 
 * Circular references within TTCNâ€“3 constant expressions (that is, if the right-handside value of a constant definition referred back to the same constant) caused the compiler to abort after reporting the relevant error message.
 
@@ -2632,7 +2632,7 @@ Released on October 31, 2003.
 
 * When a TTCNâ€“3 enumerated type was forward referenced within a module the compiler aborted with an internal fatal error if the enum hack (`-E`) option was used.
 
-* The compiler generated incorrect C++ code for some procedure-based port types. This caused memory corruption when an incoming call, reply or exception was extracted from the port queue, which could result in unpredictable behavior (segmentation faults, infinite loops, etc.) on some platforms.
+* The compiler generated incorrect {cpp} code for some procedure-based port types. This caused memory corruption when an incoming call, reply or exception was extracted from the port queue, which could result in unpredictable behavior (segmentation faults, infinite loops, etc.) on some platforms.
 
 * When an individual testcase was executed in parallel mode (i.e.Â without the control part) the name of the module and testcase were swapped in the log (like this: `Executing test case MyModule in module MyTestCase.`).
 
@@ -2664,9 +2664,9 @@ Released on September 19, 2003.
 
 *New features*
 
-* The generated C++ code no longer uses template classes for the realization of enumerated, record of and set of types and their ASN.1 equivalents. This results in significantly faster compilation of the generated code especially in case of large projects. The generated flat code provides the same (or backward compatible) API for the Test Ports.
+* The generated {cpp} code no longer uses template classes for the realization of enumerated, record of and set of types and their ASN.1 equivalents. This results in significantly faster compilation of the generated code especially in case of large projects. The generated flat code provides the same (or backward compatible) API for the Test Ports.
 
-* The compiler supports semantic analysis and automatic ordering for TTCNâ€“3 module (global) constants. The semantic checks include the folding of expressions, which results in more compact and faster C++ code. The component constants and local constants are still unchecked.
+* The compiler supports semantic analysis and automatic ordering for TTCNâ€“3 module (global) constants. The semantic checks include the folding of expressions, which results in more compact and faster {cpp} code. The component constants and local constants are still unchecked.
 
 * The compiler error messages include location information (file name and line number) for the faulty language elements. This helps a lot in finding the faults in TTCNâ€“3 and ASN.1 modules.
 
@@ -2690,7 +2690,7 @@ Released on September 19, 2003.
 
 * The logging of template matching (which is done at failed receive events if the logging of event `TTCN MATCHING` is enabled) did not work properly for record of and set of types and their ASN.1 equivalents. The algorithm did not compare the sub-fields of the elements even if the template had the same number of elements. Now the field-by-field comparison is done, but only if the template and the received value has the same number of elements.
 
-* The compiler did not translate the TTCNâ€“3 identifiers properly if they ended up by more than one underscore character. For example, 2 underscores at the end became 3 underscores in C++ instead of 4.
+* The compiler did not translate the TTCNâ€“3 identifiers properly if they ended up by more than one underscore character. For example, 2 underscores at the end became 3 underscores in {cpp} instead of 4.
 
 * The error messages given by the compiler when detecting syntax errors in the RAW encoding attributes referred to the wrong file. The error messages always contained the file name of the lastly parsed TTCNâ€“3 module, but the line numbers were correct.
 
@@ -2698,7 +2698,7 @@ Released on September 19, 2003.
 
 * The _>>_ (shift right) operator produced invalid results for some bitstring and hexstring values. If the string operand was longer than 1 byte (8 bits or 2 nibbles, respectively) the last few bits or nibbles of the result could contain memory garbage instead of the correct value.
 
-* TTCNâ€“3 identifiers `stdin`, `stdout` and `stderr` are handled by the compiler as if they were C++ keywords to avoid interferences with the libc macros.
+* TTCNâ€“3 identifiers `stdin`, `stdout` and `stderr` are handled by the compiler as if they were {cpp} keywords to avoid interferences with the libc macros.
 
 [[version-1-4-pl3]]
 == Version 1.4.pl3
@@ -2709,9 +2709,9 @@ Released on July 23, 2003.
 
 * The compiler has a new option, which allows to parse its input modules without performing semantic analysis or code generation. Consequently, the command line switch `-s` has been introduced and the meaning of `-p` changed. Now `-p` means parsing only and `-s` includes semantic checks as well.
 
-* The size of the C++ classes that the compiler generates for record/set/union types or their ASN.1 equivalents was reduced by about 10 %. This results in smaller executables and faster compilation (especially in case of incremental builds).
+* The size of the {cpp} classes that the compiler generates for record/set/union types or their ASN.1 equivalents was reduced by about 10 %. This results in smaller executables and faster compilation (especially in case of incremental builds).
 
-* The compiler is now capable of selective code generation when doing incremental builds. It means that after performing a relatively fast parsing and semantic analysis on all modules the C++ code is generated only for those modules that have changed since the last build or import from changed modules. This feature can substantially reduce the time needed for an incremental compilation in case of large projects. Of course, the capability of selective updating has been preserved.
+* The compiler is now capable of selective code generation when doing incremental builds. It means that after performing a relatively fast parsing and semantic analysis on all modules the {cpp} code is generated only for those modules that have changed since the last build or import from changed modules. This feature can substantially reduce the time needed for an incremental compilation in case of large projects. Of course, the capability of selective updating has been preserved.
 
 * The interrupt signal (which can be raised, for example, by pressing Control-C while the executable tests are running) is now handled explicitly in single mode. If the signal is received the run-time environment tries to clean up all resources (destroys all existing port mappings, calls the destructors of global objects, etc.) before terminating instead of exiting immediately. This was necessary for implementing test ports on the top of some poorly designed APIs, which require the application level connections to be terminated explicitly (although the communication is carried by TCP).
 
@@ -2746,7 +2746,7 @@ Released on June 30, 2003.
 
 *Fixed bugs*
 
-* There was a memory corruption bug in the ASN.1 front-end of the compiler, which could result in invalid C++ identifiers in the generated code. The phenomenon was libc dependent and appeared only on some Linux platforms.
+* There was a memory corruption bug in the ASN.1 front-end of the compiler, which could result in invalid {cpp} identifiers in the generated code. The phenomenon was libc dependent and appeared only on some Linux platforms.
 
 * The Main Controller did not stop if the given configuration file did not exist or contained syntax errors. It assumed that the configuration file is empty in this cases.
 
@@ -2787,9 +2787,9 @@ Released on June 13, 2003.
 
 * The template matching mechanism for the set of type construct (which uses sophisticated graph-pairing algorithms) could stuck at infinite loops in some cases due to an improper variable initialization. The infinite loop included memory allocation thus the memory consumption of the executable grew rapidly after reaching this deadlock situation.
 
-* The `Makefile` generated by the compiler behaved incorrectly in case of incremental compilation because of a missing empty rule. The build process stopped immediately after the translation of TTCNâ€“3 and ASN.1 modules and the C++ compiler was not invoked. The `make` command had to be issued again for the complete build. Moreover, in case of the non-GNU version the build procedure did not stop if the TTCNâ€“3 /ASN.1 compiler returned unsuccessful exit status.
+* The `Makefile` generated by the compiler behaved incorrectly in case of incremental compilation because of a missing empty rule. The build process stopped immediately after the translation of TTCNâ€“3 and ASN.1 modules and the {cpp} compiler was not invoked. The `make` command had to be issued again for the complete build. Moreover, in case of the non-GNU version the build procedure did not stop if the TTCNâ€“3 /ASN.1 compiler returned unsuccessful exit status.
 
-* The `-E` (enum-hack) option generated invalid C\++ identifiers if the enumeration was a C/C++ keyword (e.g.`class`).
+* The `-E` (enum-hack) option generated invalid C\++ identifiers if the enumeration was a C/{cpp} keyword (e.g.`class`).
 
 * The default syntax (i.e.Â when `WITH SYNTAX` is not defined) of object classes was implemented incorrectly.
 
@@ -2899,13 +2899,13 @@ Released on April 18, 2003.
 
 * The TTCNâ€“3 behavior statement `self.stop` was refused by the compiler, although it is allowed in the standard text. The reason for this was a bug in the official TTCNâ€“3 BNF that disallows `self.stop`. The compiler now accepts `self.stop`, which has identical meaning as stop.
 
-* The TTCNâ€“3 compiler generated invalid C++ code if an altstep was instantiated from the top-level alternative of another altstep in combination with a boolean guard expression. A closing bracket was missing in this case.
+* The TTCNâ€“3 compiler generated invalid {cpp} code if an altstep was instantiated from the top-level alternative of another altstep in combination with a boolean guard expression. A closing bracket was missing in this case.
 
 * The ASN.1 compiler produced an inappropriate error message if in a module with AUTOMATIC TAGS a CHOICE type was included in a SEQUENCE with tagging.
 
 * The ASN.1 tag descriptor structures in the run-time environment were initialized in wrong order. Therefore dynamic testcase errors could happen during encoding/decoding with the error message â€The innermost tag is not explicitâ€.
 
-* Some parts of the C++ header file generated by the ASN.1 compiler was reordered to resolve some import related problems.
+* Some parts of the {cpp} header file generated by the ASN.1 compiler was reordered to resolve some import related problems.
 
 * In parallel mode the log files are always placed in the current working directory of the HC even if the executable is started with a full pathname. In former versions if the HC was started with a pathname the logs where placed to the directory where the HC resided. Moreover, on Windows platforms the `.exe` suffix of the HC executables is also cut from the names of the log files.
 
@@ -2926,7 +2926,7 @@ Released on February 10, 2003.
 
 * The internal control protocols of the parallel test architecture were updated. The updates, which are the first steps in the migration toward version 1.3, are not backward compatible. Therefore the ETSes built with 1.2.pl4 must use the Main Controller of version 1.2.pl4 only. Similarly, the Main Controller of 1.2.pl4 does not work with ETSes built with earlier versions. Using incompatible versions may result in run-time errors or deadlocks.
 
-* The TTCNâ€“3 compiler emits the repeated string (bitstring, hexstring, octetstring, charstring) and object identifier literals into the generated C++ source file only once for each module. This can reduce the size of binary object code by about 20-30% for modules containing mainly TTCNâ€“3 templates.
+* The TTCNâ€“3 compiler emits the repeated string (bitstring, hexstring, octetstring, charstring) and object identifier literals into the generated {cpp} source file only once for each module. This can reduce the size of binary object code by about 20-30% for modules containing mainly TTCNâ€“3 templates.
 
 * All ASN.1 identifiers are printed in TTCNâ€“3 form into the log file (underscores are used instead of hyphenation characters).
 
@@ -2946,13 +2946,13 @@ Released on February 10, 2003.
 
 * The internal handling of TTCNâ€“3 port mappings could cause the unpredictable behavior of the ETS on some platform/compiler combinations (e.g.Â on Debian Linux with GCC 2.95.4) because of memory corruption due to incorrect memory allocation methods.
 
-* If more than one empty record or set type was defined as incoming or outgoing type on a TTCNâ€“3 port type the send or receive operations with in-line templates (like `EmptyRecordType`: _{}_) resulted in erroneous C++ code. The remained limitation is that the type name must be always present for in-line empty record templates even if the type is unambiguous.
+* If more than one empty record or set type was defined as incoming or outgoing type on a TTCNâ€“3 port type the send or receive operations with in-line templates (like `EmptyRecordType`: _{}_) resulted in erroneous {cpp} code. The remained limitation is that the type name must be always present for in-line empty record templates even if the type is unambiguous.
 
 * The caching of status values in stand alone receiving statements (such as `receive`, `timeout` or `done` operations) was incorrectly implemented. If an activated default has returned with a repeat statement the ETS could hang in a live-lock or report a dynamic testcase error incorrectly.
 
 * The run-time configuration file parser did not accept ASN.1 identifiers (enumerated values, field names, etc.) that contained hyphenation character. Such identifiers can now be used in the configuration file either in the original ASN.1 form or in TTCNâ€“3 form (i.e.Â the hyphenation characters are replaced by underscores). Both formats are equivalent.
 
-* The TTCNâ€“3 compiler generated invalid or incorrectly working C++ code if a variable of a set type was initialized at the definition and the fields were not in the same order as in the type definition.
+* The TTCNâ€“3 compiler generated invalid or incorrectly working {cpp} code if a variable of a set type was initialized at the definition and the fields were not in the same order as in the type definition.
 
 [[version-1-2-pl3]]
 == Version 1.2.pl3
@@ -3000,9 +3000,9 @@ Released on October 11, 2002.
 
 *New features*
 
-* The internal string handling routines were rewritten in both TTCNâ€“3 and ASN.1 compilers. The old functions were inefficient, especially when generating large C++ output files. The improved TTCNâ€“3 compiler runs significantly (about 4 times, the ASN.1 compiler 2 times) faster on a typical input module.
+* The internal string handling routines were rewritten in both TTCNâ€“3 and ASN.1 compilers. The old functions were inefficient, especially when generating large {cpp} output files. The improved TTCNâ€“3 compiler runs significantly (about 4 times, the ASN.1 compiler 2 times) faster on a typical input module.
 
-* The C\++ header and source files generated from TTCNâ€“3 and ASN.1 type definitions were restructured so that the header files became smaller. This means faster compilation (with lower memory usage) from C++ to object module in case of the importing modules of those type definitions.
+* The C\++ header and source files generated from TTCNâ€“3 and ASN.1 type definitions were restructured so that the header files became smaller. This means faster compilation (with lower memory usage) from {cpp} to object module in case of the importing modules of those type definitions.
 
 * The error messages related to templates became more talkative for record/set/SEQUENCE and union/CHOICE types. This helps locating the error when debugging faulty template definitions. The type and field names are incorporated into the error strings.
 
@@ -3018,9 +3018,9 @@ Released on October 11, 2002.
 
 *Fixed bugs*
 
-* One header file (Message `types.hh`) was missing from the binary distribution. This caused C++ compilation errors for startable TTCNâ€“3 functions.
+* One header file (Message `types.hh`) was missing from the binary distribution. This caused {cpp} compilation errors for startable TTCNâ€“3 functions.
 
-* The `stop component` operation caused idle PTCs (i.e.Â PTCs that were just created and no `start` operation was performed on them) to abort with a core dump because of an uncaught C++ exception.
+* The `stop component` operation caused idle PTCs (i.e.Â PTCs that were just created and no `start` operation was performed on them) to abort with a core dump because of an uncaught {cpp} exception.
 
 * The `create`, `done`, component `start`, `stop` and `running` operations report proper error messages in single mode.
 
@@ -3059,7 +3059,7 @@ Released on August 16, 2002.
 
 * Event severity TTCN DEBUG was introduced in logger.
 
-* String literals (constants) are translated to static C\++ objects, that is, they are listed in the source file only. In previous version when a string constant was added to or removed from the source TTCNâ€“3 module, the compiler re-generated the C++ header file as well and therefore it was necessary to re-compile several C++ files.
+* String literals (constants) are translated to static C\++ objects, that is, they are listed in the source file only. In previous version when a string constant was added to or removed from the source TTCNâ€“3 module, the compiler re-generated the {cpp} header file as well and therefore it was necessary to re-compile several {cpp} files.
 
 *Fixed bugs*
 
@@ -3067,7 +3067,7 @@ Released on August 16, 2002.
 
 * If some modules of the ETS were compiled on Solaris 8 while others on Solaris 2.6 (but using the same GCC 3.0.3), it might have happened that the functions of RAW enc/dec were unable to catch an internal exception and therefore the TC was killed by an abort signal. The reason of this problem might be the incompatibilities in the system header files of the two operating system. However, making the copy constructor of the exception class trivial has solved the problem.
 
-* The compiler generated invalid C++ code for nested altsteps (i.e.Â when an altstep was instantiated from another one).
+* The compiler generated invalid {cpp} code for nested altsteps (i.e.Â when an altstep was instantiated from another one).
 
 * The TTCNâ€“3 standard specifies that if the action list of a default terminates without reaching a stop or repeat statement, the test executor has to skip the alt statement or receiving operation that the default was called from and jump to the next statement. In the previous version, however, this situation was handled incorrectly and resulted in a dynamic test case error.
 
@@ -3104,7 +3104,7 @@ Released on July 29, 2002.
 
 * Some additional predefined functions were renamed according to the latest TTCNâ€“3 specification. Non-standard predefined functions `string2bit` and `string2oct` were renamed to `str2bit` and `str2oct`, respectively. For backward compatibility built-in functions can still be referred using old names as well.
 
-* The generation and use of empty test port skeletons can be omitted for port types that are used only for internal communication between test components. If the with attribute extension `internal` is appended to the port type definition, all necessary code will be included in the C++ output files of the module. This feature reduces the compilation time and the total size of ETS.
+* The generation and use of empty test port skeletons can be omitted for port types that are used only for internal communication between test components. If the with attribute extension `internal` is appended to the port type definition, all necessary code will be included in the {cpp} output files of the module. This feature reduces the compilation time and the total size of ETS.
 
 * A positive integer identifier number is assigned to all incoming messages when the message is appended to the port queue. The extraction of messages (e.g.Â in case of a successful `receive` operation) is also logged with a reference to these identifiers. This addition may help the test writers to trace continuously the actual state of port queues when debugging TTCNâ€“3 code.
 
@@ -3114,7 +3114,7 @@ Released on July 29, 2002.
 
 *Fixed bugs*
 
-* The line numbering (i.e. `-l`) compiler option generated invalid C++ code for the named alternatives.
+* The line numbering (i.e. `-l`) compiler option generated invalid {cpp} code for the named alternatives.
 
 * The line continuation backslashes in the generated `Makefile` caused syntax errors with some non-GNU versions of make.
 
@@ -3126,7 +3126,7 @@ Released on July 29, 2002.
 
 * The `map` and `unmap` port operations did not work in single mode. Moreover, `connect` and `disconnect` operations produce proper error messages in single mode.
 
-* Escape sequences in single character string literals (e.g.Â in a charstring containing only a quotation mark character) resulted in invalid C++ code.
+* Escape sequences in single character string literals (e.g.Â in a charstring containing only a quotation mark character) resulted in invalid {cpp} code.
 
 * All ports of test components are started implicitly according to the TTCNâ€“3 specification immediately when the component is created. The explicit start statements are no longer necessary.
 
@@ -3155,13 +3155,13 @@ Released on February 11 2002.
 
 * The assignment operator did not work properly for bitstring elements.
 
-* The size of equivalent C++ code was reduced by about 10 % in case of compound TTCNâ€“3 data types because of revised template realizations.
+* The size of equivalent {cpp} code was reduced by about 10 % in case of compound TTCNâ€“3 data types because of revised template realizations.
 
 * The Main Controller no longer creates the log file Parallel MC log, which contained debug messages only.
 
 * The built-in TTCNâ€“3 type verdicttype was not recognized by the compiler. The compiler supported the older syntax that called this type as verdict.
 
-* The compiler generated invalid C\++ code if you used an enumerated type in a record of type construct (within the same module). The resulting C++ definitions were in the wrong order.
+* The compiler generated invalid C\++ code if you used an enumerated type in a record of type construct (within the same module). The resulting {cpp} definitions were in the wrong order.
 
 * The octetstring values that contained ASCII control characters (e.g.Â newlines or tabulators) were incorrectly logged in ASCII format.
 
@@ -3178,11 +3178,11 @@ Released on December 21 2001.
 
 * It is possible to execute external programs (shell scripts) by the ETS at the beginning or end of each test case or control part.
 
-* TTCNâ€“3 constants and module parameters cannot be modified from TTCNâ€“3 code. Such attempts result in erroneous C++ code.
+* TTCNâ€“3 constants and module parameters cannot be modified from TTCNâ€“3 code. Such attempts result in erroneous {cpp} code.
 
-* The compiler inserts source code information (i.e.Â the name and line number of TTCNâ€“3 source code) as comments into the equivalent C++ code of TTCNâ€“3 functions, test cases and control parts. This feature hopefully can help when locating syntax errors in TTCNâ€“3 code. It still does not work for other definitions (such as constants or templates), but it will be extended in future versions.
+* The compiler inserts source code information (i.e.Â the name and line number of TTCNâ€“3 source code) as comments into the equivalent {cpp} code of TTCNâ€“3 functions, test cases and control parts. This feature hopefully can help when locating syntax errors in TTCNâ€“3 code. It still does not work for other definitions (such as constants or templates), but it will be extended in future versions.
 
-* The `-l` command line switch instructs the compiler to include this line information as #line directives instead of C\++ comments. Using this the error messages of the C++ compiler will point to the lines of the original TTCNâ€“3 source code. However, be extremely careful with this option because sometimes the error messages can refer to invalid line numbers. In such cases turn this switch off and analyze the C++ code manually.
+* The `-l` command line switch instructs the compiler to include this line information as #line directives instead of C\++ comments. Using this the error messages of the {cpp} compiler will point to the lines of the original TTCNâ€“3 source code. However, be extremely careful with this option because sometimes the error messages can refer to invalid line numbers. In such cases turn this switch off and analyze the {cpp} code manually.
 
 * The TTCNâ€“3 `rem` operator is now supported. In the Test Port API it is mapped to global function `rem`, which takes two arguments, either `INTEGER` or `int` in any combinations.
 
@@ -3196,11 +3196,11 @@ Released on December 21 2001.
 
 * There were linking problems with the OpenSSL shared library on some Solaris systems. In the meantime the downloadable packages were updated, so these problems should disappear using the current 1.1.pl8 version.
 
-* The compiler generated invalid C++ code for the initializers of constant and variable arrays.
+* The compiler generated invalid {cpp} code for the initializers of constant and variable arrays.
 
 * The string concatenation operation in Test Port API was changed from '&' to '+' for all string types. The `&` operator will be used for the TTCNâ€“3 and4b operator in future versions.
 
-* In the Test Port API the TTCNâ€“3 `mod` operator is no longer mapped to the C++ operator `%` because they have different semantics in case of negative operands. Instead the global function `mod` was introduced, which takes two arguments, either `INTEGER` or `int` in any combinations.
+* In the Test Port API the TTCNâ€“3 `mod` operator is no longer mapped to the {cpp} operator `%` because they have different semantics in case of negative operands. Instead the global function `mod` was introduced, which takes two arguments, either `INTEGER` or `int` in any combinations.
 
 * It was impossible to set negative integer numbers as module parameters in the configuration file.
 
@@ -3231,7 +3231,7 @@ Released on November 7 2001.
 
 * Predefined functions `oct2int` and `bit2int` returned wrong integer values, because they interpreted the octets or bits in the wrong order.
 
-* Invalid C++ code was generated for TTCNâ€“3 functions that had formal port parameters but were otherwise startable on PTCs.
+* Invalid {cpp} code was generated for TTCNâ€“3 functions that had formal port parameters but were otherwise startable on PTCs.
 
 [[version-1-1-pl7]]
 == Version 1.1.pl7
@@ -3244,7 +3244,7 @@ Released on October 8 2001.
 
 * The memory handling of record of type construct was improved.
 
-* External TTCNâ€“3 constants and functions are now supported. They are translated to external C++ constant definitions or function prototypes in the target header file.
+* External TTCNâ€“3 constants and functions are now supported. They are translated to external {cpp} constant definitions or function prototypes in the target header file.
 
 * The compiler does not stop when it encounters an unsupported type definitions, instead it outputs a warning message. Value list and length restrictions are simply ignored while the set of type construct is currently substituted with record of.
 
@@ -3256,15 +3256,15 @@ Released on October 8 2001.
 
 * Performing a running operation on an already terminated component sometimes resulted in dynamic test case error instead of returning false.
 
-* Passing of simple value parameters (i.e.Â without `tt in`, `out` or `inout` keywords) in TTCNâ€“3 functions resulted in invalid C++ code in some cases. Now these parameters are passed by value in case of data types and by reference in case of port types.
+* Passing of simple value parameters (i.e.Â without `tt in`, `out` or `inout` keywords) in TTCNâ€“3 functions resulted in invalid {cpp} code in some cases. Now these parameters are passed by value in case of data types and by reference in case of port types.
 
 * Concatenation (`&`) operators were not implemented for string elements returned by indexing.
 
 * Expressions were not allowed in timer start operations. +
 
-NOTE: Simple function instances (i.e.Â their return values) are still not allowed in timer start operations, because the compiler cannot distinguish `MyTimer.start(MyFunction()`) from `MyComponent.start(MyFunction()`), but they should be handled in different ways. In such cases please use `MyTimer.start(MyFunction() + 0.0)` as a workaround, which yields always valid C++ code.
+NOTE: Simple function instances (i.e.Â their return values) are still not allowed in timer start operations, because the compiler cannot distinguish `MyTimer.start(MyFunction()`) from `MyComponent.start(MyFunction()`), but they should be handled in different ways. In such cases please use `MyTimer.start(MyFunction() + 0.0)` as a workaround, which yields always valid {cpp} code.
 
-* Value list and complemented list templates for record of types resulted in invalid C++ code.
+* Value list and complemented list templates for record of types resulted in invalid {cpp} code.
 
 [[version-1-1-pl6]]
 == Version 1.1.pl6
@@ -3279,7 +3279,7 @@ Released on September 26 2001.
 
 * Test execution terminated abnormally in parallel mode if the `disconnect` port operation was performed on a component other than the connection was requested from by a `connect` operation.
 
-* The compiler generated invalid C++ code for some templates that contain specific values for enumerated types.
+* The compiler generated invalid {cpp} code for some templates that contain specific values for enumerated types.
 
 [[version-1-1-pl5]]
 == Version 1.1.pl5
@@ -3288,7 +3288,7 @@ Released on September 17 2001.
 
 *New features*
 
-* The compiler does not overwrite the target C\++ header or source file if its content does not change. This can speed up incremental compilation because the header files usually do not change if the user only modifies a TTCNâ€“3 definition and therefore only one C++ module shall be re-compiled. This feature can be disabled by passing the `-f` switch to the compiler.
+* The compiler does not overwrite the target C\++ header or source file if its content does not change. This can speed up incremental compilation because the header files usually do not change if the user only modifies a TTCNâ€“3 definition and therefore only one {cpp} module shall be re-compiled. This feature can be disabled by passing the `-f` switch to the compiler.
 
 * Non-standard conversion functions `oct2char` and `char2oct` were introduced.
 
@@ -3300,7 +3300,7 @@ Released on September 17 2001.
 
 * Translation of named alts having parameters caused memory leakage in the compiler.
 
-* Translation of TTCNâ€“3 functions having port parameters resulted in invalid C++ code.
+* Translation of TTCNâ€“3 functions having port parameters resulted in invalid {cpp} code.
 
 [[version-1-1-pl4]]
 == Version 1.1.pl4
@@ -3352,15 +3352,15 @@ Released on August 1 2001.
 
 *Fixed bugs*
 
-* Some C\++ templates of Base Library generated erroneous C++ code.
+* Some C\++ templates of Base Library generated erroneous {cpp} code.
 
 * The bug in Main Controller that caused some map operations to fail was fixed.
 
-* C/C\++ keywords that are not keywords in TTCNâ€“3 are now translated to valid C++ identifiers, i.e.Â the compiler appends a trailing underscore character to them.
+* C/C\++ keywords that are not keywords in TTCNâ€“3 are now translated to valid {cpp} identifiers, i.e.Â the compiler appends a trailing underscore character to them.
 
 * C style comments longer than 16 kbytes in TTCNâ€“3 modules caused the compiler to fail during translation.
 
-* The translation of TTCNâ€“3 `union` type constructs was improved. The former quadratic algorithm was replaced with a linear one, which results in both faster translation and smaller generated C++ code, especially for unions containing a large number of fields.
+* The translation of TTCNâ€“3 `union` type constructs was improved. The former quadratic algorithm was replaced with a linear one, which results in both faster translation and smaller generated {cpp} code, especially for unions containing a large number of fields.
 
 * Some error messages of the compiler printed the identifiers with double underscore characters.
 
@@ -3379,7 +3379,7 @@ Released on July 23 2001.
 
 * Port operations `connect`, `disconnect`, `map` and `unmap` now works for members of port arrays as well.
 
-* The compiler generated erroneous C++ code for setting the initial value of variable and constant arrays.
+* The compiler generated erroneous {cpp} code for setting the initial value of variable and constant arrays.
 
 * Functions were startable only if their parameters were explicitly denoted by in keyword.
 
@@ -3400,7 +3400,7 @@ Released on July 10 2001.
 
 * White spaces were removed from the beginning of comment lines in `Makefile` template generated by the compiler. This confused the make utility on FreeBSD.
 
-* C++ compiler flag `-O2` was removed from `Makefile` template generated by the compiler in order to decrease compilation time.
+* {cpp} compiler flag `-O2` was removed from `Makefile` template generated by the compiler in order to decrease compilation time.
 
 * In test port function `incoming message` logging is now performed before adding message into the port queue. This facilitates Test Port debugging (e.g.Â finding unbound fields).
 
@@ -3445,7 +3445,7 @@ NOTE: The parser may screw up if the omission of semicolon causes ambiguity.
 
 * In-line array initializers were not permitted by the compiler in the right values of local constant or variable definitions.
 
-* The generated C++ code was erroneous when using single initial values for union constants or variables.
+* The generated {cpp} code was erroneous when using single initial values for union constants or variables.
 
 * Execution failed with a dynamic test case error in a send or receive statement when converting a record or set value with an omitted optional field to template.
 
@@ -3537,17 +3537,17 @@ Log event subtypes were introduced and the generated codes were updated to use t
 [[version-1-7-pl0]]
 == Version 1.7.pl0
 
-* Test Port classes as well as C\++ classes of user defined data types are put into a C++ namespace that corresponds to the TTCNâ€“3 module. (INCOMPATIBLE)
+* Test Port classes as well as C\++ classes of user defined data types are put into a {cpp} namespace that corresponds to the TTCNâ€“3 module. (INCOMPATIBLE)
 
-* The C\++ equivalents of TTCNâ€“3 and ASN.1 enumerated values were moved into the scope of the C++ class that implements the enumerated type. The enum-hack option became obsolete. (INCOMPATIBLE)
+* The C\++ equivalents of TTCNâ€“3 and ASN.1 enumerated values were moved into the scope of the {cpp} class that implements the enumerated type. The enum-hack option became obsolete. (INCOMPATIBLE)
 
-* The C++ enumerated type that describes the selected field of a TTCNâ€“3 union or ASN.1 CHOICE type was moved into the scope of the value class. The naming rules of the possible enumerated values have changed too. (INCOMPATIBLE)
+* The {cpp} enumerated type that describes the selected field of a TTCNâ€“3 union or ASN.1 CHOICE type was moved into the scope of the value class. The naming rules of the possible enumerated values have changed too. (INCOMPATIBLE)
 
-* The C++ realization of TTCNâ€“3 predefined function `ischosen` has changed. There is one common function, which takes the enumerated field identifier as argument instead of the former dedicated functions for all possible fields. (INCOMPATIBLE)
+* The {cpp} realization of TTCNâ€“3 predefined function `ischosen` has changed. There is one common function, which takes the enumerated field identifier as argument instead of the former dedicated functions for all possible fields. (INCOMPATIBLE)
 
-* Useless C++ classes and port operations are no longer generated for procedure based communication. Signatures with `noblock` keyword do not allow reply or `getreply`, signatures without exception types do not allow raise or catch. (INCOMPATIBLE)
+* Useless {cpp} classes and port operations are no longer generated for procedure based communication. Signatures with `noblock` keyword do not allow reply or `getreply`, signatures without exception types do not allow raise or catch. (INCOMPATIBLE)
 
-* The C++ class that represents signature exceptions provides accessor functions for exception types using a new naming convention. The naming convention of the enumerated type that describes the selected type has also changed. (INCOMPATIBLE)
+* The {cpp} class that represents signature exceptions provides accessor functions for exception types using a new naming convention. The naming convention of the enumerated type that describes the selected type has also changed. (INCOMPATIBLE)
 
 * The address extension no longer works with imported address type. (INCOMPATIBLE)
 
@@ -3561,7 +3561,7 @@ No changes.
 [[version-1-6-pl4]]
 == Version 1.6.pl4
 
-* C++ representation of external function parameters without the in keyword has been changed. (INCOMPATIBLE)
+* {cpp} representation of external function parameters without the in keyword has been changed. (INCOMPATIBLE)
 
 [[version-1-6-pl3]]
 == Version 1.6.pl3
@@ -3581,9 +3581,9 @@ No changes.
 [[version-1-6-pl0]]
 == Version 1.6.pl0
 
-* The constructor of test port classes now has a default argument, which is a NULL pointer. In the newly created skeletons the default argument is already present, but it has to be added to the existing test port header files manually. Otherwise, if the port type is used in a port array the generated C++ code will not compile. The updated and newly created test ports also work with older versions. (INCOMPATIBLE)
+* The constructor of test port classes now has a default argument, which is a NULL pointer. In the newly created skeletons the default argument is already present, but it has to be added to the existing test port header files manually. Otherwise, if the port type is used in a port array the generated {cpp} code will not compile. The updated and newly created test ports also work with older versions. (INCOMPATIBLE)
 
-* The member function `set size()` was added to the C++ equivalents of record of and set of types. (ADDITION)
+* The member function `set size()` was added to the {cpp} equivalents of record of and set of types. (ADDITION)
 
 [[version-1-5-pl8]]
 == Version 1.5.pl8
@@ -3613,7 +3613,7 @@ No changes.
 [[version-1-5-pl3]]
 == Version 1.5.pl3
 
-* Type universal charstring is now supported. Its equivalent C++ class named UNIVERSAL CHARSTRING was introduced. (ADDITION)
+* Type universal charstring is now supported. Its equivalent {cpp} class named UNIVERSAL CHARSTRING was introduced. (ADDITION)
 
 [[version-1-5-pl2]]
 == Version 1.5.pl2
@@ -3628,7 +3628,7 @@ No changes.
 [[version-1-5-pl0]]
 == Version 1.5.pl0
 
-* The C++ API for invoking the RAW and BER encoding/decoding functions has significantly changed. The purpose of changes was to provide a common, unified and more flexible interface for both encoding methods. See the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN TTCNâ€“3 ProgrammerÂ´s Technical Reference] for more details. (INCOMPATIBLE)
+* The {cpp} API for invoking the RAW and BER encoding/decoding functions has significantly changed. The purpose of changes was to provide a common, unified and more flexible interface for both encoding methods. See the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN TTCNâ€“3 ProgrammerÂ´s Technical Reference] for more details. (INCOMPATIBLE)
 
 [[version-1-4-pl5]]
 == Version 1.4.pl5
@@ -3640,7 +3640,7 @@ No changes.
 
 * The procedure based ports are now supported with an enhanced Test Port API. (ADDITION)
 
-* The C\++ code generated by the compiler has changed for record of, set of and enumerated types. These are not realized as C++ template classes any more, but as regular C++ classes. These changes should not cause any incompatibilities in properly written test ports.
+* The C\++ code generated by the compiler has changed for record of, set of and enumerated types. These are not realized as {cpp} template classes any more, but as regular {cpp} classes. These changes should not cause any incompatibilities in properly written test ports.
 
 * The parameter type and/or return type of some helper functions used for enumerated types has been changed from `int` to `enum`. This may require explicit casting in some Test Ports. (INCOMPATIBLE)
 
@@ -3657,7 +3657,7 @@ No changes.
 [[version-1-4-pl1]]
 == Version 1.4.pl1
 
-* Class CHAR, which was the C++ equivalent of the obsolete TTCNâ€“3 type char was removed. The compiler substitutes all occurrences of type char with charstring and CHAR is now a typedef alias to class CHARSTRING, which provides partial backward compatibility. (INCOMPATIBLE)
+* Class CHAR, which was the {cpp} equivalent of the obsolete TTCNâ€“3 type char was removed. The compiler substitutes all occurrences of type char with charstring and CHAR is now a typedef alias to class CHARSTRING, which provides partial backward compatibility. (INCOMPATIBLE)
 
 * Hexstring related conversion functions were added. (ADDITION)
 
@@ -3681,7 +3681,7 @@ No changes.
 [[version-1-2-pl3]]
 == Version 1.2.pl3
 
-* TTCNâ€“3 type hexstring is now supported. Its C++ equivalent is class HEXSTRING. (ADDITION)
+* TTCNâ€“3 type hexstring is now supported. Its {cpp} equivalent is class HEXSTRING. (ADDITION)
 
 [[version-1-2-pl2]]
 == Version 1.2.pl2
diff --git a/usrguide/userguide/1-about_the_document.adoc b/usrguide/userguide/1-about_the_document.adoc
index 82f5cc30de67f9e9601568f3b26d3dcd13163861..d2a89c1182359ad83e1e62c8ad0a45b9a83f816a 100644
--- a/usrguide/userguide/1-about_the_document.adoc
+++ b/usrguide/userguide/1-about_the_document.adoc
@@ -8,7 +8,7 @@ The purpose of this document is to provide detailed information on using the TIT
 
 This document is intended for users of the TITAN TTCNâ€“3 Test Toolset. In addition to this document, readers requiring additional information on creating and building test suites or writing test ports are referred to the link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[TITAN Programmer's Technical Reference for TITAN TTCN-3 Test Executor].
 
-NOTE: Test port writing requires a sound knowledge of C++ programming.
+NOTE: Test port writing requires a sound knowledge of {cpp} programming.
 
 == Typographical Conventions
 
diff --git a/usrguide/userguide/2-overview_of_titan.adoc b/usrguide/userguide/2-overview_of_titan.adoc
index 2eac6cb81e9a5007b997c7e8ece39297ebd2aa81..aef3ed5007ce9d29eeedebd63f35d324611ed932 100644
--- a/usrguide/userguide/2-overview_of_titan.adoc
+++ b/usrguide/userguide/2-overview_of_titan.adoc
@@ -7,15 +7,15 @@ link:https://github.com/eclipse/titan.core/tree/master/usrguide/referenceguide[T
 
 The main components are the following:
 
-* The *Compiler*, which translates TTCNâ€“3 and ASN.1 modulesfootnote:[Compilation of ASN.1 modules is necessary only if the test suite imports type definitions from ASN.1 modules.] into C++ program code.
+* The *Compiler*, which translates TTCNâ€“3 and ASN.1 modulesfootnote:[Compilation of ASN.1 modules is necessary only if the test suite imports type definitions from ASN.1 modules.] into {cpp} program code.
 
-* The *Base Library*, written in C++ language, which contains important supplementary functions for the generated code.
+* The *Base Library*, written in {cpp} language, which contains important supplementary functions for the generated code.
 
 * The *Test Port(s)*, which facilitate the communication between the TTCNâ€“3 Test System and the System Under Test (SUT).
 
-The generated C\++ modules as well as the Test Ports should be compiled to binary object code and linked together with the Base Library using a traditional C++ compiler.
+The generated C\++ modules as well as the Test Ports should be compiled to binary object code and linked together with the Base Library using a traditional {cpp} compiler.
 
-All parts, except the protocol specific Test Ports, are included in the binary package of the Test Executor. The Test Executor is a protocol and platform independent tool that can be easily adapted to any kind of protocols by writing the appropriate Test Port. The generated C\++ code is exactly the same on all platforms, provided that the pre-compiled Base Library that matches the operating system and C++ compiler is used. The Test Port may use operating system calls or external library functions for sending or receiving messages towards System Under Test so it may become platform dependent.
+All parts, except the protocol specific Test Ports, are included in the binary package of the Test Executor. The Test Executor is a protocol and platform independent tool that can be easily adapted to any kind of protocols by writing the appropriate Test Port. The generated C\++ code is exactly the same on all platforms, provided that the pre-compiled Base Library that matches the operating system and {cpp} compiler is used. The Test Port may use operating system calls or external library functions for sending or receiving messages towards System Under Test so it may become platform dependent.
 
 Writing a Test Port is not an easy task for the first time, but the Compiler alleviates it by generating an empty skeleton for each function to be written. This skeleton is also useful for checking the correctness of an existing test suite because the Executable Test Program can be linked with this empty Test Port. In this case the resulting program actually does nothing, but the successful linking means that no modules or functions are missing from the test suite.
 
@@ -43,6 +43,6 @@ For detailed information, refer to <<3-creating_executable_test_suites_from_the_
 
 After the test suite has been created a suitable configuration file has been built, the executable is ready to run.
 
-The test executor can operate in single or parallel mode. The single modeâ€”also called non-parallel modeâ€”is thought for TTCNâ€“3 test suites built around a single test component. It is forbidden to create parallel test components in single mode: the test suite is not supposed to contain any `create` operation otherwise the test execution will fail. The parallel mode, on the other hand, offers full-featured test execution including distributed and parallel execution. The goal of introducing the single operating mode was to eliminate redundancies and thereby increase the speed of execution. It is possible to execute non-parallel test suites in parallel mode, but doing so results in unnecessary overhead. The C++ code generated by the compiler is suitable for both execution modes, there are no command line switches to select mode. The only difference is that different Base Libraries must be linked in single and parallel modes.
+The test executor can operate in single or parallel mode. The single modeâ€”also called non-parallel modeâ€”is thought for TTCNâ€“3 test suites built around a single test component. It is forbidden to create parallel test components in single mode: the test suite is not supposed to contain any `create` operation otherwise the test execution will fail. The parallel mode, on the other hand, offers full-featured test execution including distributed and parallel execution. The goal of introducing the single operating mode was to eliminate redundancies and thereby increase the speed of execution. It is possible to execute non-parallel test suites in parallel mode, but doing so results in unnecessary overhead. The {cpp} code generated by the compiler is suitable for both execution modes, there are no command line switches to select mode. The only difference is that different Base Libraries must be linked in single and parallel modes.
 
 For detailed information on executing test suites in single or parallel mode, refer to <<4-executing_test_suites.adoc, Executing Test Suites>>.
diff --git a/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc b/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc
index 6adef6dcb932dd536abee4e700250aa4d859b345..b2d4f1bbcbcd3f90cd988d726d127fefb8097940 100644
--- a/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc
+++ b/usrguide/userguide/3-creating_executable_test_suites_from_the_command-l.adoc
@@ -28,7 +28,7 @@ $(TTCN3_DIR)/bin/compiler $(TTCN3_MODULES) $(ASN1_MODULES)
 
 The variables `GENERATED_SOURCES` and `GENERATED_HEADERS` store the name of the source and header files that the compiler will generate. This rule calls the compiler with an argument list that contains the name of all TTCNâ€“3 and ASN.1 files. Beginning from version 1.2.pl0 the compiler does _not_ duplicate the underscore ("_") characters in output file names, so you may safely use such module and file names that contain this character.
 
-To compile the generated C++ code using `make`, the following rule in the `Makefile` is also needed:
+To compile the generated {cpp} code using `make`, the following rule in the `Makefile` is also needed:
 [source]
 ----
 .cc.o:
@@ -39,9 +39,9 @@ In this case simply issue the command `*make MyModule.o*` and the two translatio
 
 === Rules for Modular Test Suites
 
-The compiler supports modular TTCNâ€“3 test suites as well. Each module is translated to a separate C\++ header and source file. These source files can be compiled by the C++ compiler one-by-one separately.
+The compiler supports modular TTCNâ€“3 test suites as well. Each module is translated to a separate C\++ header and source file. These source files can be compiled by the {cpp} compiler one-by-one separately.
 
-The importing mechanisms work in the following way. For example, two TTCN-3 modules are present in files `A.ttcn` and `B.ttcn`, respectively. Definitions of module A may be used from module B, so the `import from A all`; statement must be added to module B. The modules A and B *must* be translated by the compiler in one step to `A.cc`, `A.hh`, `B.cc` and `B.hh`. During the compilation from TTCNâ€“3 to C++ of module B, the import statement will be translated to `#include "A.hh"`. This statement will be put to the beginning of `B.hh`, so you can refer to any definitions of A in module B. But note that when compiling `B.cc`, `A.hh` must exist and it must be up to date.
+The importing mechanisms work in the following way. For example, two TTCN-3 modules are present in files `A.ttcn` and `B.ttcn`, respectively. Definitions of module A may be used from module B, so the `import from A all`; statement must be added to module B. The modules A and B *must* be translated by the compiler in one step to `A.cc`, `A.hh`, `B.cc` and `B.hh`. During the compilation from TTCNâ€“3 to {cpp} of module B, the import statement will be translated to `#include "A.hh"`. This statement will be put to the beginning of `B.hh`, so you can refer to any definitions of A in module B. But note that when compiling `B.cc`, `A.hh` must exist and it must be up to date.
 
 Thus, additional rules are needed in the `Makefile`. It is recommended adding them automatically using the utility `makedepend` footnote:[The makedepend utility is available on all supported platforms. It usually can be found in the X11 development package.]. Run the following command:
 
@@ -50,7 +50,7 @@ Thus, additional rules are needed in the `Makefile`. It is recommended adding th
 
 This will add the rules to the end of the `Makefile` and they will be updated upon re-running `makedepend`. For further details please consult the manual page of `makedepend`.
 
-Multiple imports of the same module are handled correctly. For example, if importing all definitions of module C from both modules A and B in the previous example, all three C++ source files will compile correctly.
+Multiple imports of the same module are handled correctly. For example, if importing all definitions of module C from both modules A and B in the previous example, all three {cpp} source files will compile correctly.
 
 == Automatically Generated `Makefile`
 
@@ -71,7 +71,7 @@ The `Makefile` for a project can be generated using the generator tool `ttcn3_Ma
 
 * `{Module}*` are additional TTCNâ€“3 or ASN.1 modules, which are directly or indirectly referenced (imported) from the main module and thus required for building the executable test suite. Each argument should be a file name (with or without path) or a module name.
 
-* `{Test Port}*` specifies names of all test ports or other required C++ program modules. The names can be given with or without suffix.
+* `{Test Port}*` specifies names of all test ports or other required {cpp} program modules. The names can be given with or without suffix.
 
 * `{Other File}*` specifies the names of other files (configuration files, shell scripts, and so on) that are used in this project.
 
@@ -95,9 +95,9 @@ Then the `Makefile` generator tries to classify the file in the following catego
 
 * TTCNâ€“3 include files (based on suffix, only with `-p`)
 
-* C/C++ source files (based on suffix)
+* C/{cpp} source files (based on suffix)
 
-* C/C++ header files (based on suffix)
+* C/{cpp} header files (based on suffix)
 
 * other files (the rest)
 
@@ -107,11 +107,11 @@ If the `Makefile` generator ensured that the file is neither a TTCNâ€“3 nor an A
 
 The remaining files (configuration files and so on) will be added to the other filesâ€™ section of the `Makefile`. These files do not take part in the build process, but they are added to the archive files created using the `Makefile`.
 
-After the classification, the `Makefile` generator filters out the redundant generated C\++ files. If a given C/C++ file was found to be generated from one of the given TTCNâ€“3 or ASN.1 modules, a warning is printed and the file will be dropped from the list of C/C++ files. That is, the file will not be added to the list of user source files since it is already a member of the generated sources. This feature is useful if one wants to regenerate the `Makefile` using the shell wildcard `*.cc` while the generated files from the previous compilation are still present.
+After the classification, the `Makefile` generator filters out the redundant generated C\++ files. If a given C/{cpp} file was found to be generated from one of the given TTCNâ€“3 or ASN.1 modules, a warning is printed and the file will be dropped from the list of C/{cpp} files. That is, the file will not be added to the list of user source files since it is already a member of the generated sources. This feature is useful if one wants to regenerate the `Makefile` using the shell wildcard `*.cc` while the generated files from the previous compilation are still present.
 
-In the next step the algorithm tries to complete the list of C/C\++ files by checking the pairs of header and source files. If a C/C++ source file was identified and a header file with the same name exists (only the suffix differs) too, the `Makefile` generator will add the header file automatically. This step is performed in the reverse direction too: the `Makefile` generator can find an existing source file based on the header file given to it. Of course a C++ source file can exist without a header file or vice versa.
+In the next step the algorithm tries to complete the list of C/C\++ files by checking the pairs of header and source files. If a C/{cpp} source file was identified and a header file with the same name exists (only the suffix differs) too, the `Makefile` generator will add the header file automatically. This step is performed in the reverse direction too: the `Makefile` generator can find an existing source file based on the header file given to it. Of course a {cpp} source file can exist without a header file or vice versa.
 
-The `Makefile` generator continuously checks the uniqueness of files and module names. If the same file was given more than once in the command line the repeated argument is simply ignored and a warning message is displayed. It is not allowed to use two or more different TTCNâ€“3 or ASN.1 files containing modules with the same name because the generated C\++ files would clash. For similar reasons the user C/C++ files cannot have identical names even if they are located in different directories.
+The `Makefile` generator continuously checks the uniqueness of files and module names. If the same file was given more than once in the command line the repeated argument is simply ignored and a warning message is displayed. It is not allowed to use two or more different TTCNâ€“3 or ASN.1 files containing modules with the same name because the generated C\++ files would clash. For similar reasons the user C/{cpp} files cannot have identical names even if they are located in different directories.
 
 Finally the `Makefile` is generated based on the resulting data. If the `Makefile` generator finds an existing `Makefile` in its working directory, it will not be overwritten unless the option `-f` is used.
 
@@ -121,9 +121,9 @@ When a path name passed to the `Makefile` generator contains a directory part th
 
 The `Makefile` is generated based on the following assumptions:
 
-* Each object and if applicable, shared object file is located in the same directory as the C/C++ source file it is derived from. This allows the use of efficient wildcard rules.
+* Each object and if applicable, shared object file is located in the same directory as the C/{cpp} source file it is derived from. This allows the use of efficient wildcard rules.
 
-* The TTCNâ€“3 /ASN.1 compiler will place all generated C++ files in the current working directory.
+* The TTCNâ€“3 /ASN.1 compiler will place all generated {cpp} files in the current working directory.
 
 ==== Use of `GNU make`
 
@@ -131,13 +131,13 @@ If option `-g` is used, the resulting `Makefile` will be less redundant as it wi
 
 The more of the file naming conventions below are fulfilled, the more suffix substitution rules can be applied in the generated `Makefile`. If the rules are only partially fulfilled, the `Makefile` will be also correct, but it will be more difficult to maintain. It is recommended to follow these rules especially when starting a new project.
 
-* Unless option `-c` is used, all TTCNâ€“3, ASN.1 and C++ modules should reside in the current working directory. If these files are stored in a different scheme (for example in a hierarchical directory tree) symbolic links can be used to collect all input files into one build directory.
+* Unless option `-c` is used, all TTCNâ€“3, ASN.1 and {cpp} modules should reside in the current working directory. If these files are stored in a different scheme (for example in a hierarchical directory tree) symbolic links can be used to collect all input files into one build directory.
 
-* The suffix should be `.ttcn` for TTCNâ€“3 modules, `.asn` for ASN.1 modules and `.cc` for C/C++ files.
+* The suffix should be `.ttcn` for TTCNâ€“3 modules, `.asn` for ASN.1 modules and `.cc` for C/{cpp} files.
 
 * The file name (without suffix) should be identical to the module name. If the name of the ASN.1 module contains a hyphen, the corresponding file name should contain an underscore character instead. For example, the TTCNâ€“3 module `My_Module` should be stored in `My_Module.ttcn` and the file containing ASN.1 module My-ASN1-Module should be named as `My_ASN1_Module.asn`.
 
-* Each C/C++ module should have a header file with identical name, but with the suffix `.hh`.
+* Each C/{cpp} module should have a header file with identical name, but with the suffix `.hh`.
 
 ==== Use of Central Storage
 
@@ -147,23 +147,23 @@ The central directories should contain those common modules that do not change f
 
 In addition to the above mentioned ones the following assumptions are used in these `Makefiles`:
 
-* The compiler will generate C\++ files only for those TTCNâ€“3 and ASN.1 modules that are located in the current working directory. The generated C++ files of the remaining TTCNâ€“3 and ASN.1 modules should be located in the same directory as the respective module. If a module is located in a directory other than the current working directory and it does not have pre-compiled files a symbolic link must be created in the current working directory, which should point to the file containing the module.
+* The compiler will generate C\++ files only for those TTCNâ€“3 and ASN.1 modules that are located in the current working directory. The generated {cpp} files of the remaining TTCNâ€“3 and ASN.1 modules should be located in the same directory as the respective module. If a module is located in a directory other than the current working directory and it does not have pre-compiled files a symbolic link must be created in the current working directory, which should point to the file containing the module.
 
-* Object and if applicable, shared object files will be created only from those C/C++ source files that are located in the current working directory. Object and if applicable, shared object files of the remaining source files should be located in the same directory as the respective source file.
+* Object and if applicable, shared object files will be created only from those C/{cpp} source files that are located in the current working directory. Object and if applicable, shared object files of the remaining source files should be located in the same directory as the respective source file.
 
 * The TTCNâ€“3 and ASN.1 modules of central directories should not import definitions from the modules of the current working directory. Importing in the reverse direction is allowed, of course.
 
-* C/C++ files of central directories should not include header files of the current working directory. Local C/C++ files can include headers from other directories.
+* C/{cpp} files of central directories should not include header files of the current working directory. Local C/{cpp} files can include headers from other directories.
 
-* The generated C++ files and object and if applicable, shared object files of all central directories must be up-to-date before invoking `make`. Otherwise the build process will fail immediately with an error message footnote:[If an object and if applicable, a shared object file of a central directory is not up-to-date, but make is invoked it tries to build that file instead of printing an error message. The build will usually fail due to missing access rights. This is a known limitation of this `Makefile` system that cannot be easily solved in a generic way.]. In case of multi-level hierarchy of central directories the re-compilation should be performed in bottom-up order in the central directories.
+* The generated {cpp} files and object and if applicable, shared object files of all central directories must be up-to-date before invoking `make`. Otherwise the build process will fail immediately with an error message footnote:[If an object and if applicable, a shared object file of a central directory is not up-to-date, but make is invoked it tries to build that file instead of printing an error message. The build will usually fail due to missing access rights. This is a known limitation of this `Makefile` system that cannot be easily solved in a generic way.]. In case of multi-level hierarchy of central directories the re-compilation should be performed in bottom-up order in the central directories.
 
-* All directories must use the same environment, that is, same hardware platform, operating system, version of TTCNâ€“3 Executor and C++ compiler, command line switches, and so on, for building. Otherwise compilation or run-time errors may occur.
+* All directories must use the same environment, that is, same hardware platform, operating system, version of TTCNâ€“3 Executor and {cpp} compiler, command line switches, and so on, for building. Otherwise compilation or run-time errors may occur.
 
 Note that when a pre-compiled TTCNâ€“3 or ASN.1 module is taken from a central directory the following three files will be used from the central directory during the build process. Thus it is essential to keep all these files always consistent and up-to-date.
 
 * The module itself when performing the semantic analysis on the local modules importing it.
 
-* The generated C\++ header file when compiling the generated C++ files of the importing modules.
+* The generated C\++ header file when compiling the generated {cpp} files of the importing modules.
 
 * The object and if applicable, the shared object file when linking the executable.
 
@@ -199,7 +199,7 @@ The `Makefile` generator creates the `Makefile` with the following content:
 # - make port Generates port skeletons.
 # - make clean Removes all generated files.
 # - make compile Translates TTCN-3 and ASN.1 modules to
-# C++.
+# {cpp}.
 # - make dep Creates/updates dependency list.
 # - make objects Builds the object files without linking
 # the executable.
@@ -218,11 +218,11 @@ The `Makefile` generator creates the `Makefile` with the following content:
 # TTCN3_DIR =
 # Your platform: (SOLARIS, SOLARIS8, LINUX, FREEBSD or WIN32)
 PLATFORM = SOLARIS8
-# Your C++ compiler:
+# Your {cpp} compiler:
 CXX = g++
-# Flags for the C++ preprocessor (and makedepend as well):
+# Flags for the {cpp} preprocessor (and makedepend as well):
 CPPFLAGS = -D$(PLATFORM) -I$(TTCN3_DIR)/include
-# Flags for the C++ compiler:
+# Flags for the {cpp} compiler:
 CXXFLAGS = -Wall
 # Flags for the linker:
 LDFLAGS =
@@ -242,11 +242,11 @@ ARCHIVE_DIR = backup
 TTCN3_MODULES = MyExample.ttcn
 # ASN.1 modules of this project:
 ASN1_MODULES =
-# C++ source & header files generated from the TTCN-3 & ASN.1
+# {cpp} source & header files generated from the TTCN-3 & ASN.1
 # modules of this project:
 GENERATED_SOURCES = $(TTCN3_MODULES:.ttcn=.cc) $(ASN1_MODULES:.asn=.cc)
 GENERATED_HEADERS = $(GENERATED_SOURCES:.cc=.hh)
-# C/C++ Source & header files of Test Ports, external functions
+# C/{cpp} Source & header files of Test Ports, external functions
 # and other modules:
 USER_SOURCES = PCOType.cc
 USER_HEADERS = $(USER_SOURCES:.cc=.hh)
@@ -319,13 +319,13 @@ Always perform the following checklist before the first build of the executable
 
 * Verify that the variable `TTCN3_LIB` contains the name of the appropriate Base Library for the chosen operating mode, that is,` ttcn3` for single and `ttcn3-parallel` for parallel execution mode!
 
-* The variable `CXX` should point to the name or full path of the C++ compiler.
+* The variable `CXX` should point to the name or full path of the {cpp} compiler.
 
-* The variables `CPPFLAGS`, `CXXFLAGS` and `LDFLAGS` should contain the extra command line switches to be passed to the C\\++ preprocessor, compiler and linker, respectivelyfootnote:[For the detailed list and explanation of possible command line switches, refer to the manual page of the used C++ compiler]. For example, profiling or optimization is set here.
+* The variables `CPPFLAGS`, `CXXFLAGS` and `LDFLAGS` should contain the extra command line switches to be passed to the C\\++ preprocessor, compiler and linker, respectivelyfootnote:[For the detailed list and explanation of possible command line switches, refer to the manual page of the used {cpp} compiler]. For example, profiling or optimization is set here.
 
 * Using the variable `COMPILER_FLAGS` you can pass additional command line options to the TTCNâ€“3 /ASN.1 compiler.
 
-* Ensure that the version of the TTCNâ€“3 /ASN.1 compiler used is identical to the version of Base Library it is linked with. In case of version mismatch the generated C++ source files will not compile and an `#error` notification will be received. This means that changing to another version of TTCNâ€“3 Test Executor, a full re-build of all modules using `make clean` must be performed.
+* Ensure that the version of the TTCNâ€“3 /ASN.1 compiler used is identical to the version of Base Library it is linked with. In case of version mismatch the generated {cpp} source files will not compile and an `#error` notification will be received. This means that changing to another version of TTCNâ€“3 Test Executor, a full re-build of all modules using `make clean` must be performed.
 
 * Make sure to always build test ports from their source distribution. A version mismatch between the object and if applicable, shared object files may cause improper linkage or unpredictable behavior. It is thus contra-indicated to link precompiled test port objects and if applicable, shared objects into your executable (for example taken from a central repository). If the `Makefile` was generated with the option `-p` check also:
 
@@ -333,7 +333,7 @@ Always perform the following checklist before the first build of the executable
 
 * Command line options for the C preprocessor can be given using the `CPPFLAGS TTCN3` variable. +
 
-WARNING: do not confuse it with the `CPPFLAGS` variable, which is used on the generated C++ code.
+WARNING: do not confuse it with the `CPPFLAGS` variable, which is used on the generated {cpp} code.
 
 * Specify additional files which are included (`#include` directive) into `ttcnpp` files with the variable `TTCN3_INCLUDES`. These files will be checked (modification time) at every build to determine if any dependent files need to be recompiled. Any file with extension `.ttcnin` will be added to TTCN3_INCLUDES by the `Makefile` generator.
 
@@ -355,28 +355,28 @@ Checks the syntax and semantics of the TTCNâ€“3 and ASN.1 modules. This command
 
 * `*make clean*`
 +
-Removes all generated files (generated C++ files, object and TITAN generated shared object files and the executable) and log files. This command is useful when changing to another version of the test executor or simply for saving disk space.
+Removes all generated files (generated {cpp} files, object and TITAN generated shared object files and the executable) and log files. This command is useful when changing to another version of the test executor or simply for saving disk space.
 
 * `*make compile*`
 +
-Translates the TTCNâ€“3 and ASN.1 modules to C\++. It is useful when the user wants to carry out the compilation of the generated C++ code later. As a result, an empty file named `compile` is created in the working directory. The attributes of this file contain the date and time of the last compilation, which helps the compiler in selective code generation. It is not recommended to change this file manually. The compiler will be invoked only if one or more of the TTCNâ€“3 or ASN.1 modules were modified after that timestamp, otherwise the generated C++ files are up to date.
+Translates the TTCNâ€“3 and ASN.1 modules to C\++. It is useful when the user wants to carry out the compilation of the generated {cpp} code later. As a result, an empty file named `compile` is created in the working directory. The attributes of this file contain the date and time of the last compilation, which helps the compiler in selective code generation. It is not recommended to change this file manually. The compiler will be invoked only if one or more of the TTCNâ€“3 or ASN.1 modules were modified after that timestamp, otherwise the generated {cpp} files are up to date.
 
 * `*make diag*`
 +
 Lists general information about the environment and the build. This information can be useful to fix build problem by the developers or the support team. The output contains: +
 - the compiler related information (titan version, build date, C\\++ version, license information, see command `*"compiler â€“v"*`), +
-- main controller related information (titan version, C++ compiler version, build date, license information, see command `*"mctr_cli â€“v"*`), +
+- main controller related information (titan version, {cpp} compiler version, build date, license information, see command `*"mctr_cli â€“v"*`), +
 - C\++ compiler information (see command `*"g++ -v"*`), +
 - library creator info ( see command `*"ar â€“v"*`), +
 - values of environment variables `$TTCN3_DIR`, ``$ OPENSSL_DIR`, `$XML_DIR`, `$PLATFORM`.
 
 * `*make dep*`
 +
-Obsolete. Creates or updates the dependency list between the C++ header and source files by invoking the utility `makedepend`. This command must be invoked before the first compilation or when the list of modules or test ports has changed. It is also necessary to run `make dep` if an import statement has been added or removed in a module. The command implies `make compile` and after that it modifies the `Makefile` itself. Used only with older `gcc` versions.
+Obsolete. Creates or updates the dependency list between the {cpp} header and source files by invoking the utility `makedepend`. This command must be invoked before the first compilation or when the list of modules or test ports has changed. It is also necessary to run `make dep` if an import statement has been added or removed in a module. The command implies `make compile` and after that it modifies the `Makefile` itself. Used only with older `gcc` versions.
 
 * `*make objects*`
 +
-Creates or updates the object files created from the C++ source files. This command has the same effect as `make all` except that the executable test suite is not linked in the final step.
+Creates or updates the object files created from the {cpp} source files. This command has the same effect as `make all` except that the executable test suite is not linked in the final step.
 
 * `*make port*`
 +
@@ -390,11 +390,11 @@ Creates the shared object files from object files, compiled with `-fPIC`. This t
 Creates or updates the executable test suite and then runs it. This is only recommended for simple test suites in single mode. Running requires a configuration file; its name by default is `config.cfg`. This file has to be written by the user.
 
 === Building the Executable
-Issue the command `make dep` when finished creating and editing the `Makefile`. This command will translate all TTCNâ€“3 and ASN.1 modules to C++ and will find the dependencies between them automatically. The `Makefile` will be modified; many lines will be appended to it.
+Issue the command `make dep` when finished creating and editing the `Makefile`. This command will translate all TTCNâ€“3 and ASN.1 modules to {cpp} and will find the dependencies between them automatically. The `Makefile` will be modified; many lines will be appended to it.
 
 Finally, issue the `make` command, which will build the executable test suite. If any of the source files (TTCNâ€“3 or ASN.1 modules or test port source files) has been changed, issue the `make` command to get an up-to-date binary.
 
-If TTCNâ€“3 or ASN.1 modules or test ports are need to be added or removed to or from the project, regenerate the `Makefile` skeleton or change the variables `TTCN3_MODULES`, `ASN1_MODULES`, `GENERATED_HEADERS`, `GENERATED_SOURCES`, `OBJECTS` or `SHARED_OBJECTS` accordingly. If a new test port or other C/C++ module should be added, add it to the lines `USER_HEADERS`, `USER_SOURCES` and `OBJECTS` or `SHARED_OBJECTS`.
+If TTCNâ€“3 or ASN.1 modules or test ports are need to be added or removed to or from the project, regenerate the `Makefile` skeleton or change the variables `TTCN3_MODULES`, `ASN1_MODULES`, `GENERATED_HEADERS`, `GENERATED_SOURCES`, `OBJECTS` or `SHARED_OBJECTS` accordingly. If a new test port or other C/{cpp} module should be added, add it to the lines `USER_HEADERS`, `USER_SOURCES` and `OBJECTS` or `SHARED_OBJECTS`.
 
 WARNING: It is recommended to use the `makedepend` utility together with make. This ensures that all dependencies are handled correctly. Therefore, `make dep` command must be issued before the first use of `make` and whenever the module hierarchy (imports) changes! If no `make dep` command is issued then in some cases two `make` commands shall be issued for the successful compilation.
 
@@ -461,19 +461,19 @@ sed -e "$editcmd" <$1 >$2
 == Manual Building
 This section contains information useful for the experienced users who are using a build framework other than `make` for TTCNâ€“3 -based testing.
 
-=== Compiling the Generated C++ Code
+=== Compiling the Generated {cpp} Code
 
-If the TTCNâ€“3 test suite was successfully translated to C\++, itâ€™s a good idea to check if the generated code contains any errors. The simplest way is to compile it using a C++ compiler. Since the generated code refers to the base library, run the following command:
+If the TTCNâ€“3 test suite was successfully translated to C\++, itâ€™s a good idea to check if the generated code contains any errors. The simplest way is to compile it using a {cpp} compiler. Since the generated code refers to the base library, run the following command:
 [source, subs="+quotes"]
 *g++ -c -I$TTCN3_DIR/include -Wall MyModule.cc*
 
-In the following, using of an GNU C\++ compiler is assumed. If the TTCNâ€“3 /ASN.1 compiler did not report any errors in the input test suite, the generated C++ code must be correct (that is, compile without errors). After certain TTCNâ€“3 warnings (such as unreachable statements) the generated code may trigger similar warnings in the C++ compiler.
+In the following, using of an GNU C\++ compiler is assumed. If the TTCNâ€“3 /ASN.1 compiler did not report any errors in the input test suite, the generated {cpp} code must be correct (that is, compile without errors). After certain TTCNâ€“3 warnings (such as unreachable statements) the generated code may trigger similar warnings in the {cpp} compiler.
 
-The generated code has been tested on various versions of GNU C\++ and Sun Workshop C++ compilers. However, the code should work with any standard-compliant C\++ compiler since it does not depend on hardware or compiler specific features. If the generated code fails to compile on a supported platform and C++ compiler the situation is considered as a compiler bug and a Trouble Report can be issued footnote:[The Trouble Report must include the compiler error message(s), all input files and command line switches of the TTCNâ€“3 /ASN.1 compiler, the platform and the exact version of TITAN TTCNâ€“3 Test Executor and the C++ compiler. It is highly appreciated if the user could minimize the input by dropping out irrelevant modules and definitions.].
+The generated code has been tested on various versions of GNU C\++ and Sun Workshop {cpp} compilers. However, the code should work with any standard-compliant C\++ compiler since it does not depend on hardware or compiler specific features. If the generated code fails to compile on a supported platform and {cpp} compiler the situation is considered as a compiler bug and a Trouble Report can be issued footnote:[The Trouble Report must include the compiler error message(s), all input files and command line switches of the TTCNâ€“3 /ASN.1 compiler, the platform and the exact version of TITAN TTCNâ€“3 Test Executor and the {cpp} compiler. It is highly appreciated if the user could minimize the input by dropping out irrelevant modules and definitions.].
 
-The switch `-c` tells the GNU C++ compiler to compile only and not to build an executable because, for example, the `main` function is missing from the generated code. The switch `-I` adds the `$TTCN3_DIR/include` directory to the compilerâ€™s standard include path. The optional argument, `-Wall`, forces the compiler to report all warnings found in its input. This argument can be used in GCC only.
+The switch `-c` tells the GNU {cpp} compiler to compile only and not to build an executable because, for example, the `main` function is missing from the generated code. The switch `-I` adds the `$TTCN3_DIR/include` directory to the compilerâ€™s standard include path. The optional argument, `-Wall`, forces the compiler to report all warnings found in its input. This argument can be used in GCC only.
 
-The result after a successful compilation is an object file named `MyModule.o` and if applicable, a shared object file named `MyModule.so`. If compilation fails, a lot of error messages may be generated. For example, a misspelled type name in an included test port can totally confuse the C++ compiler. Thatâ€™s why it is recommended to analyze the reason of the first error message only.
+The result after a successful compilation is an object file named `MyModule.o` and if applicable, a shared object file named `MyModule.so`. If compilation fails, a lot of error messages may be generated. For example, a misspelled type name in an included test port can totally confuse the {cpp} compiler. Thatâ€™s why it is recommended to analyze the reason of the first error message only.
 
 === Linking the Executable
 
diff --git a/usrguide/userguide/4-executing_test_suites.adoc b/usrguide/userguide/4-executing_test_suites.adoc
index edc1e7ec538ac040be347e896bb2dc7a819bdb3e..f1529136efb5a2a6635e2e9b9c5e9bf157b8de1d 100644
--- a/usrguide/userguide/4-executing_test_suites.adoc
+++ b/usrguide/userguide/4-executing_test_suites.adoc
@@ -115,7 +115,7 @@ The test execution in parallel mode comprises the following steps:
 
 The components of test environment form two main groups: the Test System and the SUT. As TTCNâ€“3 is used for black box testing, that is, the test suite does not assume anything about the internal structure of the SUT, this section describes the internal structure of Test System only. The Test System consists of one or more test components, whose behaviors are entirely described in a TTCNâ€“3 test suite. The test system has other components for special purposes, listed below.
 
-Each component of the test system runs independently, they are different processes of the operating system. Every component executes one single thread of control. The components can be located on different machines and, of course, there can be more than one component running on the same computer. In the latter case scheduling among them is provided by the scheduler of the operating system. Regardless of their roles, all test components execute binary code generated from the same C++ source code. Their code consists of three parts: the code generated from the test suite by the TTCNâ€“3 compiler, the Test Ports and the TTCNâ€“3 Base Library.
+Each component of the test system runs independently, they are different processes of the operating system. Every component executes one single thread of control. The components can be located on different machines and, of course, there can be more than one component running on the same computer. In the latter case scheduling among them is provided by the scheduler of the operating system. Regardless of their roles, all test components execute binary code generated from the same {cpp} source code. Their code consists of three parts: the code generated from the test suite by the TTCNâ€“3 compiler, the Test Ports and the TTCNâ€“3 Base Library.
 
 The components communicate with each other using TCP connections with proprietary protocols and platform independently encoded abstract messages. The components form three groups according to their functionality.
 
@@ -294,8 +294,8 @@ The script returns different exit codes which can be used by user written softwa
 
 == Strange Behavior of the Executable
 
-If modular test suites are executed, sometimes the executable test program can do strange things, for example, the execution terminates without any reason or the send functions of the Test Port is not called, and so on. This is because out-of-date C\++ header files are used for translating the C++ modules, that is, there is a wrong `Makefile`.
+If modular test suites are executed, sometimes the executable test program can do strange things, for example, the execution terminates without any reason or the send functions of the Test Port is not called, and so on. This is because out-of-date C\++ header files are used for translating the {cpp} modules, that is, there is a wrong `Makefile`.
 
-This may happen when the Test Port files are renamed, so the compiler regenerates them. Thus the C++ source files generated by the compiler see an empty Test Port header file, but the fully functional Test Port object file is linked to the executable. In this case, the linking will be successful, but during the execution strange things can happen. The reason behind this phenomenon is that the modules consider the raw binary structure of the same C++ class different, for example they fetch the virtual function pointer from a wrong place.
+This may happen when the Test Port files are renamed, so the compiler regenerates them. Thus the {cpp} source files generated by the compiler see an empty Test Port header file, but the fully functional Test Port object file is linked to the executable. In this case, the linking will be successful, but during the execution strange things can happen. The reason behind this phenomenon is that the modules consider the raw binary structure of the same {cpp} class different, for example they fetch the virtual function pointer from a wrong place.
 
-Avoid these situations and re-compile all C++ files before reporting such bugs, and the use of `makedepend` utility is strongly recommended.
+Avoid these situations and re-compile all {cpp} files before reporting such bugs, and the use of `makedepend` utility is strongly recommended.