mixing code c and c++

[vbruno1]

Posted on December 12, 2016 at 12:03

Hi guys.

I'm trying to write a mixing project code c and c ++.

The aim would be to take advantage of high-level libraries written in C ++ and we link  these in c.

You have experience about? When having to import in C and libraries c++ and classes, where you use polymorphism and subclasses are defined, you have ideas or experience on how to act?

I work in the IAR environment and am facing this problem by

https://www.iar.com/support/tech-notes/compiler/mixing-c-and-c/

For example I should link the library in the attached file.

Thank you for answers.

#class #mix-c-and-c++

[Alan Chambers]

Posted on December 12, 2016 at 13:33

I write all of my code on STM32s in C++. I'm using IAR. There are no problems calling C APIs such as CubeHAL or the Standard Peripheral Library, or <Whatever>OS. This is not surprising because C is almost always valid C++. I don't use any third party C++ libraries, but can't imagine that being difficult. Basically, just write a C++ project and it'll all work out. I would avoid STL. I don't use exceptions or RTTI either, but suspect these are not as expensive some people claim. 

I typically implement drivers and other application objects (FSMs, protocols, etc.) as Myers singletons to ensure that they are initialised once, in the correct order, and globally available, but this is just preference. I usually give them abstract interfaces to hide the implementation and facilitate unit testing.

[vbruno1]

Posted on December 12, 2016 at 14:19

Thank you for answer.

But in my case I write the main in c and not in cpp. I think that this complicate the write queues, wrapper code.

[Alan Chambers]

Posted on December 12, 2016 at 14:26

Why is main() in C? I think there is no advantage to this. Writing C wrappers for C++ APIs is a pain. It can be done, of course, but I would not recommend it.

[vbruno1]

Posted on December 12, 2016 at 14:49

Because the most API are writted in C. Today, We need include new funtionsw derived by qt (c++)  in c. 

You have no idea on how to link the classes in c?

[Alan Chambers]

Posted on December 12, 2016 at 16:36

It does not matter that most APIs are in C. You can include both C and C++ compilation units in the same program. Well written C APIs include &sharpifdef CPP extern 'C' {...} around the declarations so that the names are not mangled when the headers are included in C++ units. There is an expectation that they will be so included. This means the C can be compiled as C and the linker will be able to match the symbols declared in the C++ units to the symbols defined in the C units. Consequently, any C++ program can make use of (probably) any library which is written in C. This is by design and has been done routinely since the 1980s.

C++ is (almost) a proper superset of C. Calling C from C++ is trivially easy. Calling C++ from C is not. This involves hiding all the C++ness of the code. You can always put extern 'C' functions in your C++ units to allow those functions to be linked to C. You can put whatever C++ code in them you like, since the functions will be compiled by a C++ compiler. However, you are probably going to find it very difficult to make good use of classes, polymorphism, templates and all the rest of it, since none of these abstractions exist in C at all. They are essentially the whole reason that C++ was created in the first place.As I have said, I write exclusively in C++ for STM32s. I routinely make use of the Standard Peripheral Library and have sometimes used FreeRTOS and CubeHAL, all of which are written entirely in C.

[valentin]

Posted on January 24, 2017 at 19:47

Hi

Chambers.Alan

‌,

could you please give an example of a typical workflow of creating a new project including cubeHAL and FreeRTOS?

Are you first creating a blank C++ project and then merging the generated Cube+RTOS project files manually? Or is there a more elegant way?

I'd love to transition over to C++ but have only tested one blank project generated by TrueStudio using STL to see whether I could include the Eigen library. Worked like a treat but I do like HAL&FreeRTOS so I'd be really curious about that.

[Alan Chambers]

Posted on January 26, 2017 at 14:52

I can't really answer this, because the framework I'm using at the moment was developed before I ever heard of HAL or CubeMX. My experience of FreeRTOS is limited, because most of my projects do not require threads.

I don't use HAL at all in any of my code. I do use the CubeMX GUI to help me design the pin out and select peripherals. It's quite good at spotting conflicts and so on, and can produce a detailed report which is useful for your electronics engineer when he's designing your board.

I originally developed a simple C++ framework with a cooperative scheduler, asynchronous signals and slots, software timers and so on, and then added a collection of peripheral drivers which encapsulated all the necessary SPL calls. A lot of those drivers have been re-used on many projects, maybe with some pin (and other resource) changes.

When I need to develop a new peripheral driver, I configure the peripheral and any pins in CubeMX and generate the project to have a look at what the initialisation code and so on does. Of course, this is in HAL and needs to be translated to SPL. I do not compile the generated files into my project at all.

Before Cube, I searched this forum for examples (tips hat to Clive One - you are amazing, sir), and modelled my code around those. This may still be the more useful approach.

Regarding C++, just do it. There is simply no reason not to do so if your platform has a reasonable C++ compiler. Others might argue with this, but am yet to hear a convincing case. I have encountered no difficulties whatsoever in using C++ on STM32s. I choose not to use STL, exceptions and RTTI, but there is no reason why they should not work. Don't know anything about Eigen, but give it a spin on a Discovery board and see what happens.

[valentin]

Posted on February 06, 2017 at 20:32

Thanks, I did give it a spin and it worked. Flawlessly, out of the box. Amazing

[valentin]

Posted on February 11, 2017 at 21:06

Update: This is actually even easier than I thought.

After creating the original C project (and having worked with it for 2 months now) I found out that I can just convert it using the eclipse/truestudio built in converter feature (file - new - other - convert project).

This worked perfectly well with a full blown HAL + FreeRTOS + USB + FATFS project.

All I had to do was copy the symbols and directories from the C compiler over to C++. And I changed the main.c name to main.cpp. Don't know yet whether that makes a difference though.

But the C++ compiler is so much better as it is more tedious about clean&proper coding. I found some places where I've been a bit slack before and the C compiler just didn't bother.

So in short, the workflow:

1. Create CubeMX project

2. Import to TrueStudio (in my case, haven't tested anything else yet)

3. Convert to C++ and copy compiler settings from C. All easily doable in the GUI settings part

4. rename main.c to main.cpp

5. done, start coding/including C++ code

6. Don't forget to add the C++ wrapper to your header files (that got me a couple of times).