cpp support

[robert-b]

There is some basic c++ support.
As an example I simply allocate an existing cpp object:
`
#include <scheduler/schedulerTask.h>

// a simple allocation of an object
task_c my_task;

// fails to allocate
task_c my_task_array[2];
With the following error: Linking REVO Memory region Used Size Region Size %age Used FLASH: 236124 B 896 KB 25.74% FLASH_CONFIG: 0 GB 128 KB 0.00% RAM: 41388 B 128 KB 31.58% CCM: 7808 B 64 KB 11.91% BACKUP_SRAM: 0 GB 4 KB 0.00% MEMORY_B1: 0 GB 0 GB -1.#JC:\cygwin64\tmp\ccBF65ET.ltrans0.ltrans.o:(.rodata+0x350): undefined reference tovtable for __cxxabiv1::__class_type_info'
C:\cygwin64\tmp\ccBF65ET.ltrans0.ltrans.o:(.rodata+0x360): undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'

Is there more planned or in the pipeline?
A correct thing would be to use g++ instead of gcc to prevent library issues.

[robert-b]

the usage of c++ support within inav is bogus.
i fixed the makefile and deleted unneccessary c++ helpers and base class.

[digitalentity]

You're probably talking about de_cpp_glue branch. As you may have noticed the relevant PR #3652 is marked as "in progress" and "do not merge" which implies it doesn't yet work.

[robert-b]

the route you went is totally wrong.
now i can replace the stupid mahony implementation with proven c++ code.

[digitalentity]

You don't want all runtime cpp bells and whistles including dynamic memory allocation in a high performance embedded systems. It will cause code bloat without any real benefit and in fact may cause bugs if used blindly. Having cpp features without having to pull in all STL, RTTI and exception handling is a challenge. If you think you can simply link against bulky cpp runtime lib and be fine - you are welcome to do so, but don't expect other developers to agree with your appoach.

…

On Fri, Aug 17, 2018, 11:40 Robert ***@***.***> wrote: the route you went is totally wrong. now i can replace the stupid mahony implementation with proven c++ code. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3751 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKi_m936m8S_Ar9m9zET0IN11vxnvZtCks5uRo92gaJpZM4V_tcC> .

[robert-b]

if you turn the clock back by a few years, yes, then you are right.
when you look at a deterministic system then a few features are a no go.
during initialization it's another issue.
i don't agree on quite a few things in betaflight and inav.
so i don't expect a huge crowd to follow me ;-)

but a cascaded pid controller within inav would make sense.

[giacomo892]

@robert-b you are free to port a better IMU :)