C++ on the boards

[BytesGalore]

RIOT now provides a seamless c and c++ handling in the RIOT build system for user applications.
But using c++ on specific boards requires adjustments, e.g. (un)set specific compiler and linker flags, provide/change system calls or even provide a custom tweaked compiler.

Here we can track the progression of board support and discuss related issues.

• Family: native
  • native
• Family: ARM
  • Airfy Beacon
  • Arduino Due
  • cc2538dk
  • f4vi1
  • IoT LAB_M3
  • mbed_lpc1768
  • MSB-IoT
  • MSBA2
  • Mulle
  • OpenMote
  • PCA1000x
  • Phytec phyWAVE KW22
  • Samr21 xpro
  • Spark Core
  • STM32F0discovery
  • STM32F3discovery
  • STM32F4discovery
  • UDOO
  • yunjia-nrf51822
• Family: ATmega
  • Arduino Mega2560
  • Arduino Uno
  • Arduino Duemilanove
• Family: MSP430
  • eZ430-Chronos
  • MSB-430H
  • TelosB
  • WSN430
  • Zolertia Z1
• Family: x86
  • Intel Galileo

[BytesGalore]

Family: ARM compile tests

• pttu w/ MCU lpc2387 (compiles)
• avsextrem w/ MCU lpc2387 (compiles)
• redbee-econotag w/ MCU mc1322x (Does NOT compile, errors)

./RIOT/cpu/mc1322x/include/mc1322x.h:26:10: error: 'struct CRM_struct::<anonymous union>::CRM_SYS_CNTL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:200:66: error: invalid conversion from 'void*' to 'volatile CRM_struct*' [-fpermissive]
./RIOT/cpu/mc1322x/include/mc1322x.h:223:10: error: 'struct TMR_struct::<anonymous union>::TMR_CTRL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:292:69: error: invalid conversion from 'void*' to 'volatile TMR_struct*' [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:332:24: error: 'struct ITC_struct::<anonymous union>::ITC_INTCNTL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:342:9: note: in expansion of macro '__INTERRUPT_union'
...
/RIOT/cpu/mc1322x/include/mc1322x.h:354:66: error: invalid conversion from 'void*' to 'volatile ITC_struct*' [-fpermissive]

[dangnhat]

ping @BytesGalore : do we have any progress on this ? ;-)

[BytesGalore]

no, I haven't tested the implementation for some time if something changed 😊
I will extend the list for with the new boards tomorrow and update it with current results.

[N8Fear]

For AVR I think I can say that there seems is currently no real C++ support on the side of avr-libc. Especially libstdc++ is missing. So while it is possible to use language constructs like classes (I'm not sure if a C++ compiler is included in the default toolchain, Gentoo's crossdev builds one), C++ experience on AVR won't be seamless (without extensive work or switching to another libc, which implies extensive work again ;-) ).

[LudwigKnuepfer]

Arch Linux comes with avr-g++.

[jnohlgard]

@N8Fear It is not really viable to expect a full libstdc++ or similar on a microcontroller platform because of flash and RAM considerations, but there are lighter alternatives for a C++ template library if just the C++ support is there, e.g. http://msharov.github.io/ustl/ (I haven't tried that one yet, but I have been meaning to do it for some time)

[N8Fear]

Ok - in this case: If C++ support means "there is a compiler" AVR should be fine.. ;-)

[dangnhat]

@N8Fear : at least we want some basic object-oriented programming can be done, after that we can consider the support for other stuffs like STL (after evaluate the resource needed and real-time capacity on uCs ). ;-)

For AVR I think I can say that there seems is currently no real C++ support on the side of avr-libc.

IMHO, I think it's the problem with C++ support on that platform in general not specific RIOT. I guess our main goal should be providing the build system to build C++ easily and making sure our source code don't do anything to violate C/C++ compatibility. In other words, it's something like "if some people can use C++ on a platform then they can use C++ with RIOT like normal because our build system can mix their code with RIOT and we don't mess anything up with C/C++ compatibility" ;-)

C++ experience on AVR won't be seamless (without extensive work or switching to another libc,
which implies extensive work again ;-) )

Therefore, if the "normal situation on a specific platform" has some difficulties with C++ then provide the better C++ support for that platform should be nice to have for RIOT but not mandatory. :-)

BTW, arduino can do some C++ programming on avr, right?