Firmware Library: C++ Support

budde2 · ‎2008-10-28

Posted on October 28, 2008 at 13:26

budde2 · ‎2011-05-17

Posted on May 17, 2011 at 12:49

Hi,

we are starting at the moment a large project, which will be based on several STM32 microcontrollers. We have decided to use your firmware library.

We will use C++ as programming language. I am a little bit astonished that the firmware library is not really C++ compatible.

All header files are missing the following keyword:

extern ''C''

See e.g.

http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html#faq-32.4

And the header files are using keywords for types, which are already used by C++ itself (e.g. ''bool'').

It would be greate, if you could make the header files C++ conform.

st3 · ‎2011-05-17

Posted on May 17, 2011 at 12:49

Quote:

I am a little bit astonished that the firmware library is not really C++ compatible.

C++ is still not common in the type of small embedded projects where you might expect to find an STM32.

However, as it is a new product, it is a bit remiss that they didn't at least make it compatible! :(

But they are not the only ones:

http://www.luminarymicro.com/component/option,com_joomlaboard/Itemid,92/func,view/id,2918/catid,7/

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:49

look for a c++ build environment posted to this forum. (but it's based on fwlib 1.0.)

picguy · ‎2011-05-17

Posted on May 17, 2011 at 12:49

budde should be able to insert the appropriate C++ corrections into header files. The â€œboolâ€� case is likely as simple s removing the typedef. But he should not have to do it.

I am not using STâ€™s firmware library but have an issue with IARâ€™s assembler vs. C++. The C++ â€œint xyz(void)â€� entry point is â€œxyz()â€� which I can not create in their assembler. Itâ€™s annoying but easy enough to get around. Except that one could then make a prototype for xyz(int) and call my assembler routine. Had I been able generate the xyz() entry point the C++ user would see a linker error and know (or should know) that something is wrong.

Is there an excuse to create an STL multimap in an STM32 application? I canâ€™t imagine one. Yet there is no reason to make it (more) difficult to accomplish. In my applications I never use general purpose memory management. Yet there is no reason why such routines should not exist.