New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FMI fmi2CallbackFunctions is incompatible with C++ #443

modelica-trac-importer opened this Issue Oct 17, 2018 · 2 comments


None yet
3 participants

modelica-trac-importer commented Oct 17, 2018

Reported by federico.terraneo on 6 Oct 2018 09:28 UTC
fmi2FunctionTypes.h contains the following code

typedef struct {

const fmi2CallbackLogger logger;
const fmi2CallbackAllocateMemory allocateMemory;
const fmi2CallbackFreeMemory freeMemory;
const fmi2StepFinished stepFinished;
const fmi2ComponentEnvironment componentEnvironment;

} fmi2CallbackFunctions;

where all fields are declared const. However in C++ const fields in structs/classes can only be initialized in a constructor's intialization list, and the struct has no constructor. I think const should be removed to make this code interoperable with C++.

This issue has been reported to OpenModelica first
but apparently this file is part of the FMI standard.



This comment has been minimized.


pmai commented Oct 27, 2018

For what it's worth the header files are currently geared only toward the FMU interface itself, i.e. they are not really useful for the implementation calling the FMU: For the FMU code, it only ever needs to access the members of this struct (passed by pointer), so initialization issues are not relevant. In this case the const protection prevents the FMU from changing the member function pointers, which is the intention.

This consequently means that importing tools will usually need to use different header files/data sets to actually generate the struct (e.g. by using a non-const version of the struct and casting). This is of course a bit cumbersome, and might not way lightly against the perceived benefit of const protection.

In any case this is not a bug, in that it is done by design and the consequences are known and can be handled properly by tools (i.e. the original OpenModelica problem still looks an OpenModelica bug to me, since that code seems to want to instantiate an fmi2CallbackFunctions variable itself, which of course you cannot do).

I think this issue should be adressed one way or another (i.e. either stay with the current definition, or abandon constness) for 3.0 by poll.

PS: We might want to add even more clear guidance on this point (if we stay with the current definition) to make people more aware (if they read the standard, that is).


This comment has been minimized.


pmai commented Oct 27, 2018

See also issue #216, which tracks this for 2.0.1 release fix/nofix.

@pmai pmai added the needs poll label Oct 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment