Compilation Errors relating to Abstract Classes

[EbenezerA99]

hi! I'm developing a test deployment on Fprime v3.0 and im running into some issues where integrating the three custom components that I wrote for this test cause compilation errors. Specifically, I am seeing the following:

The abstract class error only occurs for the three custom components I'm integrating into the deployment. All 3 of the components and the deployment itself are defined in the SSDL module in their respective fpp files.

Has anyone seen errors like this? I am unsure how to address the error within the v3.0 fprime framework(unsure if its a fpp issue?). Any help would be appreciated!

[timcanham]

This almost always means you didn't override the handler functions for ports and commands that are defined in the autocoded base class.

Run fprime_util impl -d <path to deployment> to get some stubs to base your code on.

[EbenezerA99]

That's what I thought as well, but I had already implemented the handler functions for the ports and commands for the three components.

However, I went ahead and ran the fprime-util impl command, regenerated the implementation stubs and changed the filenames to be correct, and it worked! This felt odd to me so I did some digging.

For some context, these three components were initially created in Fprime 2.X and I brought them over to Fprime 3.0 by using the fpp-from-xml tool and using the fpp files. I did not change the cpp & hpp files at all.

All 3 of the errors did indeed stem from not implementing a handler function correctly, however it was because some of the arguments to the function were ever so slightly different.

For example, one of the input ports that was causing the errors was of type Drv.ByteStreamRecv. When I initially generated the .cpp/.hpp files in Fprime 2.X the function definition was as follows:

void framedIn_handler(const NATIVE_INT_TYPE portNum, /*!< The port number*/ Fw::Buffer &recvBuffer, Drv::RecvStatus recvStatus);

However, in Fprime 3.0 when the .cpp/.hpp files were generated, the function definition is

void framedIn_handler( const NATIVE_INT_TYPE portNum, /*!< The port number*/ Fw::Buffer &recvBuffer, const Drv::RecvStatus &recvStatus );

As you can see, the recvStatus argument is slightly different(const pass by reference) in the new function definition. A similar issue(const buffer passed by reference in the fprime 3.0 version of the function handle) was the cause of the other 2 errors I was seeing.

Moving forward, when bringing over components that were initially created in fprime 2.X, I will make sure to generate the implementation stubs in 3.0 to avoid this issue. However, I was wondering what was the rationale behind making these changes to the function handles(change from pass by value to pass by reference) and is there a general rule that you all at JPL use to decide whether an argument should be passed by reference vs value? In your opinion, why is it beneficial to pass something like a Recv Status as a const reference?

[timcanham]

The pass by reference is more efficient, so we are trying to switch to that where it makes sense.