How-to change the definition of fundamental data types with MATLAB Embedder Coder for C++?

I am unable to configure/change the fundamental data types in generated C++ source code using MATLAB Embedded Coder v4.3.

I've tried a lot of possible combinations of Coder settings. Independently of what I configure: The generated C++ source code always uses the built-in MATLAB data types from the generated rtwtypes.h or tmwtypes.h (from the MATLAB installation directory). The main issue with this is boolean_T, which is not a bool, but a uint8. This causes problems with other APIs, e.g Mathworks own MATLAB Data API (C++). Example: boolean_T if used in a MEX library has to be explicitly casted to bool to get the correct logical type in MATLAB. This requires nasty reinterpret_casts in C++ to fix it (we use a lot of emxArrays). This would be no problem if we would be able to change the type from boolean_T to bool (by a typedef).

What we want to achieve: Use a custom header file that sets all fundamental type definitions, so that the generated code uses the type definitions in structs and function signatures instead of the ones from tmwtypes.h or rtwtypes.h. For example, instead of int32_T the the custom type FooInt32 (declared as using FooInt32 = std::int32_t in our custom header) should be used.

First I thought that setting cfg.HardwareImplementation.ProdHWDeviceType = 'Intel->x86-64 (Windows64)' causes MATLAB Embedded Coder to ignore the value of some settings:

• cfg.EnableCustomReplacementTypes: Only partially ignored: Setting cfg.ReplacementTypes.IsExtern = true and cfg.ReplacementTypes.HeaderFiles results in an added #include statement in the generated [...]_types.h file. But besides that nothing changes.
• cfg.DataTypeReplacement: Completely ignored: The generated source code is identical.

But even if cfg.HardwareImplementation.ProdHWDeviceType is not set, both settings do not cause any difference in the generated source code.

In addition to this the used data types sometimes (project specific, seems to depend on the used types) differ when explicitly setting cfg.HardwareImplementation.ProdHWDeviceType = 'Intel->x86-64 (Windows64)'in contrast to not setting it (default should be the host machine). But: In my case the host machine is Intel->x86-64 (Windows64)! Nonetheless the source code differs: Setting it, for example, defines types with 64-bits as a chunk[2] of two 32-bit values. I would assume that this setting should make no difference at all in case the host machine architecture is equal to the configured one.

Here are the most important MATLAB Coder settings we use (in their actual order):

cfg.CppInterfaceClassName                   = 'Instance';
cfg.CppInterfaceStyle                       = 'Methods';
cfg.CppNamespace                            = 'foo_bar';
cfg.DataTypeReplacement                     = 'CBuiltIn';
cfg.EnableCustomReplacementTypes            = true;
cfg.GenCodeOnly                             = true;
cfg.GenerateExampleMain                     = 'DoNotGenerate';
cfg.HardwareImplementation.ProdEqTarget     = true;
cfg.HardwareImplementation.ProdHWDeviceType = 'Intel->x86-64 (Windows64)';
cfg.HeaderGuardStyle                        = 'UsePragmaOnce';
cfg.MultiInstanceCode                       = true;
cfg.ReplacementTypes.IsExtern               = true;
cfg.ReplacementTypes.HeaderFiles            = "foo_matlab_coder_types.hpp";
cfg.TargetLang                              = 'C++';
cfg.TargetLangStandard                      = 'C++03 (ISO)';

Sadly I am not allowed to post MATLAB source code here.

All our projects use the exact same MATLAB Embedded Coder settings and are build on the same machine. Therefore I think there is something I completely overlook in the documentation or the MATLAB Embedded Coder has some serious issues regarding data types.

1. Can someone explain to me the possible reasons why the settings mentioned above do not cause any significant difference in the generated C++ source code?
2. Is it relate to the usage of the C++ programming language and/or the usage of emxArrays?
3. Can someone please give me some "best practice" guidelines regarding MATLAB Coder data types?

Last, but not least, the environment we use:

• OS: Windows 7 v6.1.7601 x64
• MATLAB R2019b v9.7.0.1190202 x64

Answer 1

[Darshan Ramakant Bhat]

Thanks for elaborating your issue. From your above explaination I see that you want to use custom types like replacing "int32_T" with "FooInt32".

Can you please try below config settings :

cfg = coder.config('lib');

cfg.EnableCustomReplacementTypes= true; % Honor the ReplacementTypes
cfg.ReplacementTypes.int32 = 'FooInt32'; % Use 'FooInt32' in the place of 'int32' data type.
cfg.ReplacementTypes.logical = 'MyBool'; % Use 'MyBool' in the places where the logical data types are used

cfg.ReplacementTypes.IsExtern = true; % Do not emit any data type definition, use it from the external file
cfg.ReplacementTypes.HeaderFiles = "foo_matlab_coder_types.hpp"; % Take definition from this header file

Relevent docs :

https://in.mathworks.com/help//coder/ref/coder.replacementtypes.html

https://in.mathworks.com/help//ecoder/ug/import-custom-type-definitions-from-external-header-files.html

https://in.mathworks.com/help//ecoder/ug/customize-data-type-replacement.html

https://in.mathworks.com/help/coder/ug/mapping-matlab-types-to-cc-types.html

Hardware Implementation will decide what is the actual C/C++ data type. For example, in certain hardwares "int8" can be "char", in some other hardware "int8" may be "int".

https://in.mathworks.com/help/coder/ref/coder.hardwareimplementation.html

Hope this will be helpful.

[Florian Wolters]

Thanks for your answer.

I've only forgot to include the actual type replacements (e.g. cfg.ReplacementTypes.int32) for the cfg instance in the OP. They do exist in our actual code.

I do understand that the HardwareImplementation settings should control the actual generated data types. But again: All this does not work at all for our code.

I've read the documentation already, but it seems I'm completely missing something. Thanks for the links, nonetheless.

I will read again and try to create a minimal short, self contained, correct example (SSCCE). If the problem(s) still remain with that example, I will post here again.