C++ wrappers

[Giovanni]

Hi,

You should work using subversion trunk code, 16.1 is a stable branch and will not receive any enhancement, only bug fixes.

Other questions are likely explained here: http://chibios.org/dokuwiki/doku.php?id ... tyle_guide
The document is meant for C, it could require changes in order to address C++ too.

Giovanni

[helmut]

Hi,

I just stumbled over a trouble which I was expecting when rebasing to trunk.
'trunk' as svn://svn.code.sf.net/p/chibios/svn/trunk@9602 just does not compile RT-STM32F407-DISCOVER-G++,
making it hard to test my changes.

Questions 2, 4, 9 and probably 10 are still open.
Helmut

[helmut]

Hi Jovanni,

just went through the coding style (again). I just wonder: Is there a reason for pressing C89
it is just ANCIENT, it might be legitimate not to go C11, but at least I know of no single C-compiler,
that does not support C99 (which is 17 years old )

Helmut
PS: I don't want to start a flame war here, I'm just curious.

[Giovanni]

Hi,

Products are meant to be portable, if you go outside the ARM perimeter there are proprietary compilers that do not support C99.

Giovanni

[helmut]

Hi,

I'm having hard times to rebase the wrappers to trunk, stumbling over compile errors again and again ...

Code: Select all

../../../os/hal/src/hal_usb.c: In function 'usbStop':
../../../os/hal/src/hal_usb.c:324:3: error: 'spip' undeclared (first use in this function)
   spip->config = NULL;
   ^
../../../os/hal/src/hal_usb.c:324:3: note: each undeclared identifier is reported only once for each function it appears in
make: *** [build/obj/hal_usb.o] Error 1
helmut@daredevil:~/work/tpd02/chHALE/ChibiOS/demos/STM32/RT-STM32F746G-DISCOVERY-LWIP-FATFS-USB$

Helmut

[Giovanni]

Hi,

Fixed that error, it was caused by a recent change.

Giovanni

[Prof. Dr. YoMan]

Hi,

I just want to point on this: https://community.arm.com/groups/tools/ ... itten-in-c

Gaining C++11 compatible threading and lots of STL functionality is really nice.

[Giovanni]

Interesting, still a proposal but I think we should keep an eye on it and try to influence it for the better.

I think that the core should stay written in C and provide a C++ wrapper, current approach. I don't see advantages in writing directly in C++ and it would impact portability.

Giovanni

[helmut]

Hi,

Fixed that error, it was caused by a recent change.

Giovanni

Hi,
in which commit?

... OK, just saw it its 9610, sorry.

The question now is, how is often is the github mirror updated?

Helmut

[Prof. Dr. YoMan]

It is not only a proposal. Check the git-repos on github.
http://micro-os-plus.github.io/cmsis-plus/ and some others.

From what I know from Liviu it already runs in the simulator and passes the CMSIS-RTOS test suite.
And there is a working version with FreeRtos as sheduler. He is answering mails pretty fast. Maybe ask direcly (with link to this thread).

From my point of view the step to C++11 and above is the only possible solution, because this is the first "complete" version of C++ which is broadly compatible on different compilers and which got a reeeeealy got Lib and API.

Every thing is very well though. Check the books "A Tour of C++" by Stroustrup, "The C++ Standard Library" by Jusuttis and
http://isocpp.github.io/CppCoreGuidelin ... Guidelines / https://github.com/isocpp/CppCoreGuidelines
and
https://github.com/Microsoft/GSL

uC these days are big enough to handle this well and it is not true that C++ is a memory hog or that everything is done dynamically. Building on templates and C++11 STL one could easily build stuff without any dynamic memory allocation, completely checked static by compiletime.

Great for embedded stuff.

C++11 and above is the way to go.