CATIA CAA RADE Coding Standards


The CATIA CAA RADE product portfolio is the cutting edge offering from Dassault Systemes that provides the most complete set of tools, guides and Application Programming Interfaces that support the CATIA application development process using CAA (Component Application Architecture), from the initial customized product definition to the final product packaging.

CATIA CAA RADE is the development environment (the IDE) and the Application Program Interfaces (APIs) are the actual code to build CATIA CAA applications. CATIA CAA & RADE are used in conjunction. RADE is delivered on General Available (GA) releases, while APIs are delivered on each Service Pack (SP) level. RADE (Rapid Application Development Environment) is just the Visual Studio integration piece that allows developing CATIA CAA apps in Visual Studio through custom wizards. Building CATIA CAA applications requires CATIA CAA APIs and RADE. Normally RADE is a 32-bit installation, but the APIs are available on 32 and 64-bit depending on the CATIA base installation.

CATIA CAA RADE has some important tools used for managing, compiling and checking the source code written using CAA APIs. This article discusses RADE tools. CATIA CAA RADE tools are the Visual Studio customized programs  that are responsible for interfacing with code generation wizards, code builders and CAA dialog generators


CATIA CAA CAA Authorized APIs are located in the PublicInterfaces directory of each CAA framework. The list of CATIA CAA Authorized APIs are available in an encrypted file called AuthorizedAPI.script under RADE tools installation.

CATIA CAA RADE has a mechanism to help developers use only Authorized CAA APIs, CAA RADE code builder mkmk checks that CAA RADE applications only use Authorized APIs and issues an error if a DS Internal Resource like @nodoc or @CAA2Required is used. This is a corrective check done by CAA RADE code builder mkmk, and not a predictive one and forces CAA developers to review their coding and possibly their design when the CAA application is ready to be built.


Naming rules apply to both the Dassault Systèmes group, to the CATIA CAA Partners and Members, and to CAA customers that keep their in-house developments. They are aimed at avoiding CAA  object naming conflicts between the entities that can be found together in the same repository at CAA run time. Customers are also intended to make any CAA application or solution belong to the CAA application or solution family.

The CAA RADE naming conventions are based on a brand or company name, usually denoted by a trigram (a three letter upper case acronym). CAA RADE developers can use a separate traigram for your company name. For example, Engineering Custom Solutions Limited can have a triagram called ECS. CAA developers must ensure that the trigrams do not conflict with Dassault Systèmes brand names.


Create a Header File for each C++ or C Entity in CATIA CAA RADE

  • Create a separate header file for each class, interface, structure, global enumeration, global function, and macro, and put in this file only the declaration of this entity in the CATIA CAA RADE Workspace. Header file must have the same name as the CAA RADE entity. For example, the CATBaseUnknown class header file in CAA RADE is CATBaseUnknown.h, which is part of the System CAA RADE framework

Use #include Judiciously in CATIA CAA RADE Workspaces

  • Use #include to include the header file of the base class belonging to CATIA CAA RADE
  • Use #include to include the header file of a class when an instance of this class is used as a data member in CATIA CAA RADE
  • Use the C++ class forward declaration when a reference of, a value, or a pointer to a class is used as a method returned value or parameter, or if a pointer to a class is used as a data member in CATIA CAA RADE

C++ Threads and Templates – NOT SUPPORTED in CATIA CAA RADE

  • Don’t use Threads and Templates in CATIA CAA RADE programming as they are not portable to different operating systems, especially in the way they are supported by compilers and link-editors.

C++ Multiple Inheritance  – NOT SUPPORTED in CATIA CAA RADE

  • Do not use Multiple Inheritance in CATIA CAA RADE. The main problem raised by multiple inheritance is the ambiguity of the multiple inherited members, whether they come from two different base C++ classes that feature members with the same name, or from the same base C++ class that is multi-inherited. Use instead the CAA V5 Object Modeler that offers other means, such as CAA interfaces and CAA components, to deal with inheritance while keeping C++ single inheritance.

Virtual Inheritance  – NOT SUPPORTED in CATIA CAA RADE

  • Virtual inheritance in C++ is used in conjunction with multiple inheritance to solve the diamond ambiguity. This happens when a C++ class inherits from two other C++ classes that themselves inherit from the same C++ class. Since multiple inheritance shouldn’t be used, virtual inheritance shouldn’t be used too in CATIA CAA RADE.

Use Only Public Inheritance in CATIA CAA RADE

  • Inheritance can be set to public, protected, or private in C++. To make sure that base class public members remain public, and that the protected ones remain protected in the derived class, always use public inheritance in CATIA CAA RADE.

Do Not Implement friend Classes in CATIA CAA RADE

  • If two friend classes are conceptually one CATIA CAA RADE object, that is share the same life cycle. This occurs when a ‘big’ C++ object has to be split in two parts. Facing this situation, consider using aggregation as an alternative technique in CATIA CAA RADE.

Do not Expose Data Members as Public in CATIA CAA RADE

  • Exposing data members as public gives direct access to your data members to any user of your class instances in CATIA CAA RADE. This breaks encapsulation. Set your data members as private and expose methods to access them in CATIA CAA RADE

Avoid Defining Static Data Members in CATIA CAA RADE

  • Static is synonymous with memory fragmentation and pagination. In addition, a static member function is required to handle a static data member in CATIA CAA RADE. Before defining a C++ static data member, make sure this data is really common to all instances of your C++ class, such as an instance counter, and not only to some of them in CATIA CAA RADE

Always Declare the Destructor as Virtual for Classes to Derive in CATIA CAA RADE

  • This is important when an instance of a derived class is identified using a pointer to its base class to avoid memory leaks in CATIA CAA RADE

Do Not Declare Virtual Methods within Class Private Parts in CATIA CAA RADE

  • Since a virtual method is intended to be overridden in a derived class in CATIA CAA RADE, it must be accessible from this derived class. Inserting a virtual method in the private part of a C++ class hides it from its derived C++ classes, and from the client applications that use the class as well, and thus prevents from overriding it in CATIA CAA RADE.

Declare the Methods Intended to Be Redefined as Virtual in CATIA CAA RADE

  • The methods declared as virtual can be redefined when a client application derives the class in CATIA CAA RADE. This enables objects to be polymorphically processed and methods to be adapted to specialized objects in CATIA CAA RADE. Because you may not, in the general case, predict who will ever derive your C++ classes, and why, carefully set as virtual all the methods that make your class a base class and that must be redefined in the derived class. By doing so, you respect the future, by preserving the ability of possible future derivations to adapt your methods to the new objects in CATIA CAA RADE.

Avoid Implementing inline Methods in CATIA CAA RADE

  • Inline methods in C++ are faster than classical methods because they do not branch to another part of the C++ code, and consequently do not deal with all the current data saving and restoring operations in CATIA CAA RADE. The C++ inline method executable code is added at each call location by the C++ compiler. (With a macro, the preprocessor adds source code.) Even if it is faster, the general rule is to avoid inline methods, because any modification to such a method forces the CATIA CAA RADE client application to rebuild.

Constrain Variables, Arguments and Methods by Using const in CATIA CAA RADE

  • CAA RADE methods must use the const C++ modifier to indicate the parameters or arguments which are not modifiable. This can be used with method parameters, especially for input parameters, or with returned values, and for data members that must be initialized in the constructors in CATIA CAA RADE. Member functions can be declared as const to operate on constant objects in CATIA CAA RADE.

Lifecycle Rules

Always Initialize Your Pointers to NULL in CATIA CAA RADE

  • Whenever you create a pointer to a class instance or to an interface in CATIA CAA RADE, always initialize it to NULL. This ensures that the C++ pointer doesn’t take a non-null value without your knowledge, and that any part of the program uses the pointer as if it were correctly set by the developer. Pointers incorrectly valued are the main memory leak source in CATIA CAA RADE.

Always Test Pointer Values Before Using Them in CATIA CAA RADE

  • Whenever you use a pointer in CATIA CAA RADE, first test its value against NULL before using it. This ensures that the C++ pointer has a valid value and that you can use it safely. Otherwise, if the pointer is NULL, the CATIA CAA RADE program crashes. Put NULL first preferably.

Always Set Pointers to Deleted Objects to NULL in CATIA CAA RADE

  • In CATIA CAA RADE whenever you delete an object allocated using the new operator, or whenever you free a memory block allocated using either the malloc, calloc, or realloc functions, immediately set the pointer to NULL. This ensures that this pointer cannot be used any longer in CATIA CAA RADE.

Always Set Released Interface Pointers to NULL in CATIA CAA RADE

  • In CATIA CAA RADE releasing an interface pointer means that you don’t need it any longer, and thus that you don’t intend to use it again. To ensure that this pointer will never be used afterwards, set it to NULL as soon as you release it in CATIA CAA RADE

CATIA CAA RADE Object Modeler Rules

Never Implement the Same Interface Twice in the Same Component in CATIA CAA RADE

  • To satisfy the Determinism principle. Otherwise, a call to QueryInterface for this CAA interface is undetermined. A call to QueryInterface must always be determinist in CATIA CAA RADE. There is no means for the caller of QueryInterface to know which pointer is returned, and no means for QueryInterface to indicate which one is returned in CATIA CAA RADE

Appropriately Use Data and Code Extensions in CATIA CAA RADE

  • Use CAA data extensions if the extension class has data members. Otherwise, use code extensions in CATIA CAA RADE. To save memory. The code extension is dedicated to extension without data members in CAA. A code extension class is instantiated once for all the instances of the component it belongs to, while a data extension is instantiated for each component’s instance in CAA. This can save a lot of memory in CATIA CAA RADE. Declare a code extension using the CATImplementClass macro in CAA. Like any extension class, it should always be a CAA object modeler derived from CATBaseUnknown. As a code extension class, it should never C++-derive from a data extension class in CATIA CAA RADE.

Always OM-Derive Your Extensions from CATBaseUnknown in CATIA CAA RADE

  • If you set another class instead of CATBaseUnknown in CATIA CAA RADE, such as the class from which the extension class C++-derives, you introduce an unnecessary additional node in the metaobject chain that can only decrease performance in CATIA CAA RADE. This is done using the CATImplementClass macro with CATBaseUnknown or CATNull always set as the third argument in CATIA CAA RADE.

Correctly Use QueryInterface in CATIA CAA RADE

  • Initialize the pointer to the requested interface to NULL as per the CATIA CAA RADE standards
  • Use the same type, that is the same interface to initialize the pointerand to retrieve it from QueryInterface in CATIA CAA RADE
  • Never use a smart pointer in place of the interface pointer in CATIA CAA RADE
  • Test the returned CATIA CAA RADE code using the macros SUCCEEDED and FAILED.The output parameters of functions such as QueryInterface are valid and usable if and only if SUCCEEDED returns TRUE in CATIA CAA RADE. Never test the output pointers in CAA. Always test the HRESULT value using SUCCEEDED before using the output pointers in CATIA CAA RADE.

Enable Interface Pointers and Smart Interface Pointers to Coexist in CATIA CAA RADE

  • You will sometimes need to make interface pointers and smart pointers coexist in CATIA CAA RADE, because, for example, you call a function that returns an interface pointer you need to cast into a smart pointer to call another function in CATIA CAA RADE. Here are the rules to smooth over this coexistence.
    • Avoid retrieving an interface pointer while casting it as a smart interface pointer to the same interface in CATIA CAA RADE
    • Never retrieve an interface pointer while casting it as a smart interface pointer to another interface in CATIA CAA RADE
    • Never cast a smart pointer to an interface pointer in CATIA CAA RADE

Correctly Fill in the Interface Dictionary in CATIA CAA RADE

  • CATIA CAA RADE Interface Dictionary Rules:
    • Rule 1: A CATIA CAA RADE component must declare: The CAA interfaces it implements, that is, the CAA interfaces for which it declares a TIE in its implementation class or extension classes. The interfaces ObjectModeler-inherited by these CAA interfaces. A CATIA CAA RADE component must not declare the interfaces whose implementations are ObjectModeler-inherited through ObjectModeler component inheritance in CATIA CAA RADE
    • Rule 2: If the CAA code generated by the TIE macro, and the CAA code that implements the corresponding interface are located in two different CAA shared libraries or DLLs, you must declare, in the CAA dictionary, the shared library or DLL that contains the TIE code instead of the one that contains the CAA interface implementation code in CATIA CAA RADE.
    • In compliance with CATIA CAA RADE Determinism Principle. Depending on the CATIA CAA RADE runtime context, that is, which shared libraries or DLLs are loaded in memory, and on other CAA interface dictionary declarations, QueryInterface may find a pointer to the requested CAA interface on an inherited CAA implementation or extension, and not on the current interface in CATIA CAA RADE.

🎓 CATIA CAA Customization Training from PLM Coach
🎓 CATIA CAA Fundamentals – Getting Started  (URL:
Required for anyone getting started to develop CATIA CAA V5 applications in the scope of CATIA portfolio
🎓 CATIA CAA Advanced
Advanced techniques for extending the CATIA CAA data model in the Part and Product context.
🎓 CATIA CAA for 3DEXPERIENCE – Getting Started(URL:
Required for anyone developing CAA applications on top of the 3DEXPERIENCE platform
Required for anyone developing V6, 3DEXPERIENCE or migrating V5 applications in the scope of CATIA portfolio
🌍 CATIA CAA Customization References on Web
🌍 Dassault Systemes CATIA CAA Portfolio Page (URL:
🎬 Checkout Video on CATIA CAA RADE Coding Standards:

🌍 For PLM / CAD Training Visit ►

Follow PLM Coach on Social Media:  YouTube LinkedIn | Facebook | Twitter | Pinterest

📧 Contact PLM Coach:

Follow the link to Training Inquiry Form to provide your details ►

Follow the link to Text PLM Coach on WhatsApp ►

☏ Mobile Number ► +91-7989703878

💌 Email ►


Leave a Comment

Your email address will not be published.

Scroll to Top