What's the suggested way to mix C and C++ sources in STM32CubeIDE

[NRumm.1]

Hi, I'm using STM32CubeIDE to develop firmware for a small appliance (using STM32F303) in C++, but I'm in troubles related to the build process, caused by generated files like stm32fxx_hal_mps.c including C++ headers, while being compiled with gcc.

What I did so far:

• converted the project from C to C++
• renamed all my header files from *.h to *.hpp and all source files from *.c to *.cpp
• renamed main.h/c to main.hpp/main.cpp (which is tedious, as STM32CubeIDE will regenerate the *.h/*.c versions upon any change to the configuration)
• left all other generated files with their original extension (so i.e. stm32xx_hal_conf.h remains a *.h-file)

As far as I can see in the output hpp/cpp files are compiled using g++, while h/c-files are compiled with gcc.

The problem is now that as *.h/*.c sources seem to get compiled with gcc, and as stm32xx_hal_conf.c includes main.hpp both files will be compiled with gcc. However, main.hpp includes another file config.hpp which itself imports the C++ versions of i.e. stdlib (cstdint), but those files can't be found by the gcc compiler. As such I see the following compiler error:

arm-none-eabi-g++ "../Core/Src/main.cpp" -mcpu=cortex-m4 -std=gnu++14 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F303xE -c -I../Core/Inc -I"STM32CubeIDEWorkspace/SensorBoardFirmware/CppUTest/include" -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -fno-rtti -fno-use-cxa-atexit -Wall -fstack-usage -MMD -MP -MF"Core/Src/main.d" -MT"Core/Src/main.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/main.o"
arm-none-eabi-g++ "../Core/Src/screen.cpp" -mcpu=cortex-m4 -std=gnu++14 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F303xE -c -I../Core/Inc -I"STM32CubeIDEWorkspace/SensorBoardFirmware/CppUTest/include" -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -fno-rtti -fno-use-cxa-atexit -Wall -fstack-usage -MMD -MP -MF"Core/Src/screen.d" -MT"Core/Src/screen.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/screen.o"
arm-none-eabi-gcc "../Core/Src/stm32f3xx_hal_msp.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F303xE -c -I../Core/Inc -I"STM32CubeIDEWorkspace/SensorBoardFirmware/CppUTest/include" -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Core/Src/stm32f3xx_hal_msp.d" -MT"Core/Src/stm32f3xx_hal_msp.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/stm32f3xx_hal_msp.o"
arm-none-eabi-gcc "../Core/Src/stm32f3xx_it.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F303xE -c -I../Core/Inc -I"STM32CubeIDEWorkspace/SensorBoardFirmware/CppUTest/include" -I../Drivers/STM32F3xx_HAL_Driver/Inc -I../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../Drivers/CMSIS/Device/ST/STM32F3xx/Include -I../Drivers/CMSIS/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Core/Src/stm32f3xx_it.d" -MT"Core/Src/stm32f3xx_it.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Core/Src/stm32f3xx_it.o"
In file included from ../Core/Inc/screen.hpp:8,
                 from ../Core/Inc/main.hpp:35,
                 from ../Core/Src/stm32f3xx_it.c:22:
../Core/Inc/config.hpp:8:10: fatal error: cstdlib: No such file or directory
    8 | #include <cstdlib>
      |          ^~~~~~~~~
compilation terminated.

What's the suggested way to handle such problem ? I highly appreciate any ideas (and yes, I'm a C++ noob).

Thank you lads !

[TDK]

<cstdlib> is a C++ header. Since stm32f3xx_it.c is a C file, you can't include it from there.

A quick solution would be to include <stdlib.h> instead. C++ files will happily include that as well.

Generally, headers meant to be included from C++ files also have a .h suffix. Header-only files are sometimes named *.hpp, but the convention is broken. You can rename the suffix if you want, but keeping them all as *.h should be easier and cause no issues.

Combining C and C++ in the same project is messy and usually leads to situations like this. It's one of the worst parts of C++ in my opinion.

Another alternative would be to leave all CubeMX generated files alone and create another *.cpp file which you call to execute your own code.

[Rob.Riggs]

One cannot include C++ headers into a C file. This is true no matter what platform one develops on.

I think it is a bad idea to rename any code files that are generated for you. Maintenance becomes very difficult.

I deal with this in one of two ways: compile both C and C++ code with the C++ compiler; or keep a clear separation of C and C++ code in the project. For embedded development, I find keeping a clear separation between the two works best. I will sometimes have foo.cpp, foo.hpp and foo.h files to maximize flexibility, where the .h file contains just the C interface information.

I do know from experience with other projects that one can convince Eclipse to compile C code with a C++ compiler by updating the file mappings. I have never tried it with code generated by the CubeMX.

[BParh.1]

What about the usage of 'extern' keyword? Which I believe originally created for this problem.

to call c from c++

https://isocpp.org/wiki/faq/mixing-c-and-cpp#call-c

to call c++ from c

https://isocpp.org/wiki/faq/mixing-c-and-cpp#call-c