To C or Not to C? That is the Question

Gerry Tyra - April 2015

Abstract:

C++ is a powerful language, and it is currently popular in the avionics industry. But all problems, or tools, do not yield gracefully to the C++ structures. The question is: how feasible is it to wrap the C++ classes to allow easy access to the message structure from other tools?

Introduction:

Assume that the message structures being discussed here are implemented for some target system, and you are a test engineer sitting in an integration lab. How do you translate the Ethernet packet captured by Wireshark into usable, readable data? Wireshark doesn't interface very will to a C++ library, but it will link to a C library. This implies that C++ to C wrappers are in order.

Once Done...

Assuming that the C++ header files are being auto generated, the resulting libraries become stable (all things being relative). A subsequent code generator can then create a set of C header files that wrap the C++ headers.

A native C++ application does not need the C wrappers, hence they can be excluded from the delivered build. However, in a lab, or a special application in the field, the C libraries can be part of an installation. This provides a relatively clean mechanism to extend the messaging system into other programming languages and/or for the construction of plug-ins for existing applications.

The wrapper will be effectively one function call deep, above the inherent depth of the C++ implementation.

Minor Down Side:

It has to be understood that the resulting wrappers can not take advantage of the economies provided by the C++ class implementations. The result is verbose, and the resulting interface will be tedious to use.

Summary:

The messaging system presented in these papers is not locked to C++. It is feasible to auto generate wrappers in C, or any other language, in order to implement the system in existing applications or alternative languages.