Korken,
What's the reason for declaring most of the classes final? IMHO it takes out the elegancy from interfacing ChibiOS with C++. For example, with the old wrapper you could derive a class from BaseStaticThread, define a main() member function and call any thread-related function implicitly against the this pointer. Now you have to store a reference to the Thread object and prefix all calls with that member. For now I don't see a reason why these classes need to be final. Without that you would still have the freedom to choose between inheritance or referencing.
Thanks, Szabi
C++ wrappers
- Korken
- Posts: 270
- Joined: Wed Apr 02, 2014 4:09 pm
- Location: Luleå, Sweden
- Has thanked: 5 times
- Been thanked: 6 times
- Contact:
Re: C++ wrappers
szekelyisz wrote:Korken,
What's the reason for declaring most of the classes final? IMHO it takes out the elegancy from interfacing ChibiOS with C++. For example, with the old wrapper you could derive a class from BaseStaticThread, define a main() member function and call any thread-related function implicitly against the this pointer. Now you have to store a reference to the Thread object and prefix all calls with that member. For now I don't see a reason why these classes need to be final. Without that you would still have the freedom to choose between inheritance or referencing.
Thanks, Szabi
This comes from the changes made in the beginning of these new wrappers, and I had the same question as you.
But helmut had good points about it: viewtopic.php?f=3&t=3287&start=50#p27048
Also, your should really not be using virtual inheritance any more. There is a really good talk on YouTube from one of the latest C++ conferences, I will try to find it.
Use a std::variant for all supported types instead or CRTP, I have yet to find a case where I really needed virtual inheritance in embedded.
However, if a use case is found that cannot be within this style, please provide it and we can look at updating the interface.
-
- Posts: 27
- Joined: Sat Mar 28, 2015 2:32 am
Re: C++ wrappers
Hi,
I'm having a problem with the latest trunk, I have a class and a callback typedef like this:
I already have os/various/syscalls.c and syscalls_cpp.cpp being compiled in the Makefile.
I skipped most of the obvious stuff, of course the pointer is init with NULL, there's methods to set it, etc, but whenever I call the callback in the c++ method, I get:
using OSX
Any hint of what I must be doing wrong ?
I'm having a problem with the latest trunk, I have a class and a callback typedef like this:
Code: Select all
typedef void (*MyCbFunction)(int);
class MyClass
{
public:
MyClass();
void somefunc(void);
private:
MyCbFunction _cb;
}
----
MyClass::somefunc(void)
{
// Do stuff, have some pointer func point to _cb etc
if(_cb != NULL)
_cb(10);
}
I already have os/various/syscalls.c and syscalls_cpp.cpp being compiled in the Makefile.
I skipped most of the obvious stuff, of course the pointer is init with NULL, there's methods to set it, etc, but whenever I call the callback in the c++ method, I get:
Code: Select all
/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x10): undefined reference to `_kill'
/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/libg.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
collect2: error: ld returned 1 exit status
using OSX
Code: Select all
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/arm-none-eabi-gcc/20180627/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /Users/build/work/GCC-7-build/src/gcc/configure --target=arm-none-eabi --prefix=/Users/build/work/GCC-7-build/install-native --libexecdir=/Users/build/work/GCC-7-build/install-native/lib --infodir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/Users/build/work/GCC-7-build/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/Users/build/work/GCC-7-build/install-native/arm-none-eabi --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --with-gmp=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-mpfr=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-mpc=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-isl=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-libelf=/Users/build/work/GCC-7-build/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-lstdc++ -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2018-q2-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)
Any hint of what I must be doing wrong ?
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: C++ wrappers
Hi,
Strange, those are in syscalls_cpp.cpp, are you sure the module is linked with the application? try disabling the linker garbage collection and/or LTO.
Giovanni
Strange, those are in syscalls_cpp.cpp, are you sure the module is linked with the application? try disabling the linker garbage collection and/or LTO.
Giovanni
-
- Posts: 27
- Joined: Sat Mar 28, 2015 2:32 am
Re: C++ wrappers
It linked with -fno-lto, but --no-gc-sections (with or without) made no changes.
Note that I had to add syscalls.c to the make file, and of course, syscalls_cpp.cpp is added from chcpp.mk
Note that I had to add syscalls.c to the make file, and of course, syscalls_cpp.cpp is added from chcpp.mk
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 14 guests