I did the change to use namespaced functions rather than static classes, please have a look.
There was no difference in size or binary of the tests I made - it should be equivalent to static classes, but following recommended practices.
C++ wrappers
- 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:
- 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:
- 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
Thanks for the update, sounds good!
I just saw all the "bumped" in the bugs section, you have quite some work in queue.
I just saw all the "bumped" in the bugs section, you have quite some work in queue.
- 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
I need to close a release with all bugs fixed before moving to next major step, 17.1 probably...
Giovanni
Giovanni
Re: C++ wrappers
Hi,
it just took too long incorporating the C++ wrappers, so I lost interest a bit (No offense, Giovanni!)
We aren't currently using C++ for our product anymore, so ...
Just a few points (I reviewed Korken's changes a bit):
1) static inlines allow the compiler to optimize a function for each compilation unit individually and forget
about the function afterwards, so you better keep them!
2) passing arguments as const when they are passed by value anyway (like size_t) won't make any difference, there is
no point in having a local copy that is not modifiable (it might even hinder implementation).
3) BaseStaticThread is just no 'good' name for a class: both base and static have multiple meanings depending on
the context, just as ThreadReference was (reference being C++ (and other languages) lingo). Pulling the thread
context out of the thread class makes it necessary to use 2 lines instead of 1 line of code for instantiation, but renders the ThreadReference
class unnecessary, it ends up being a reference to a Thread (&Thread) as expected. Some ChibiOs functions return C-pointers
to threads which would conflict with a Thread in C++ having a workspace member!
Point 3 was one of the largest changes of the C++ wrappers and made the interface a lot more convenient.
Helmut
it just took too long incorporating the C++ wrappers, so I lost interest a bit (No offense, Giovanni!)
We aren't currently using C++ for our product anymore, so ...
Just a few points (I reviewed Korken's changes a bit):
1) static inlines allow the compiler to optimize a function for each compilation unit individually and forget
about the function afterwards, so you better keep them!
2) passing arguments as const when they are passed by value anyway (like size_t) won't make any difference, there is
no point in having a local copy that is not modifiable (it might even hinder implementation).
3) BaseStaticThread is just no 'good' name for a class: both base and static have multiple meanings depending on
the context, just as ThreadReference was (reference being C++ (and other languages) lingo). Pulling the thread
context out of the thread class makes it necessary to use 2 lines instead of 1 line of code for instantiation, but renders the ThreadReference
class unnecessary, it ends up being a reference to a Thread (&Thread) as expected. Some ChibiOs functions return C-pointers
to threads which would conflict with a Thread in C++ having a workspace member!
Point 3 was one of the largest changes of the C++ wrappers and made the interface a lot more convenient.
Helmut
Re: C++ wrappers
> Interesting, still a proposal
As Prof. Dr. YoMan mentioned, µOS++/CMSIS++ (http://micro-os-plus.github.io) is more than a proposal, it is a fully functional RTOS running an Cortex-M devices and on POSIX synthetic platforms.
Some demo projects are available from https://github.com/micro-os-plus/eclipse-demo-projects.
The native APIs are C++, all objects that require dynamic memory use standard allocators, full static builds are possible, basic memory management is handled by C++17 style memory managers, and many more. In addition it has a fully functional C API, built as a 1:1 wrapper for C++ calls.
The current stable version is 6.3.9; the user manual is currently work in progress.
As Prof. Dr. YoMan mentioned, µOS++/CMSIS++ (http://micro-os-plus.github.io) is more than a proposal, it is a fully functional RTOS running an Cortex-M devices and on POSIX synthetic platforms.
Some demo projects are available from https://github.com/micro-os-plus/eclipse-demo-projects.
The native APIs are C++, all objects that require dynamic memory use standard allocators, full static builds are possible, basic memory management is handled by C++17 style memory managers, and many more. In addition it has a fully functional C API, built as a 1:1 wrapper for C++ calls.
The current stable version is 6.3.9; the user manual is currently work in progress.
- 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
It seems that we are more or less in agreement on the C++ wrapper.
I will bump it so it is not forgotten. *bump*
I will bump it so it is not forgotten. *bump*
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 40 guests