C++ Limitations within GEL Expressions

The following C++ features are not fully supported within GEL expressions.

Casting to or from a virtual base class

Any cast to or from a virtual base class is treated as a reinterpret_cast (that is, no pointer adjustment is performed).

Qualified member names

Member names - identifiers after a ‘.’ or ‘->’ operators - cannot be qualified, as in obj.Base::base_member

Destructor cannot be named

The destructor of a class (X::~X) cannot be named in a GEL expression.

Pointer to members

Pointer to member values appear as an implementation structure.


Type synonyms defined with typedef are not available from GEL.

Partially qualified types

Types that are not in the top-level namespace must be fully qualified, and cannot be partially-qualified in the same manner as identifiers.

Run-time type identification

Code Composer Studio does not identify the dynamic (run-time) type of objects referred to by base class pointers.

C++ reference semantics

C++ references appear to GEL as pointers; GEL expressions must explicitly de-reference C++ references.

C++ function operator

The Watch window and Command window cannot resolve the address of an overloaded operator defined within a class. It will not recognize them as valid function names. This includes any function name of a class that starts with operator and ends with any special character such as +, -, *, ++, –, /, ->, [] (for example, operator+, operator-, or operator[]). To work around this limitation, you can use Symbol Browser to resolve any overloaded operator functions.

Inner braces in a GEL macro

Inner braces in a GEL macro do not work and may cause errors. For example, #define SQR(x) (x*x) is functional, but #define SQR(x) ((x)*(x)) causes a memory map read error.

The GEL language always interprets (identifier) as a type cast, while the C/C++ language may interpret this as a type cast if the identifier is a type name, or as the value of the variable identifier.


See also:

GEL Functions: Alphabetical List