Why did you stop working on this impressive body of code?

[andygikling]

I really like what you've done here.

I'd love to use and contribute to this. I worry about using though because it appears you are not really working on it anymore?

Zephyr needs further C++ support (my opinion).

Is there something fundamentally or logically wrong with this library? You too busy at your day-job or what?

[lowlander]

Hey @andygikling sorry for the slow reply, I don't get much msgs here and most of the time I notice them months to late, like yours.

I really like what you've done here.

I'd love to use and contribute to this. I worry about using though because it appears you are not really working on it anymore?

If you want to contribute, feel free to do so, if I am slow here you could try to ping me on discord (LowLander) or email me directly. Let me find some time to bring it up to the latest version of Zephyr and toolchain.

Zephyr needs further C++ support (my opinion).

It should just have been written in C++ ;-)

Is there something fundamentally or logically wrong with this library?

Don't think so, some things are tricky (for example trying to avoid dynamic memory allocation, and the massive use of macros in Zephyr) and some ppl have different opinions on if you should just use std:: and not "invent" new things like zpp:: , but that is just a matter of taste I guess.

You too busy at your day-job or what?

Yeah I had some projects where Zephyr + C++ might have been an option, but that kind of went another way, so my focus went to other "pay the rent" kind of work.

[andygikling]

@lowlander

I really appreciate your response!

Ok great - thanks for the direction. I'll test this further and let you know if I have any questions!

@lowlander if stuff like this goes through, then you wouldn't have to invent as much: zephyrproject-rtos/zephyr#43729

A similiar effort from the mbed folks (although of course centered on mbed-os) is the extra cpp support for different compilers https://github.com/ARMmbed/mbed-os/tree/master/platform/cxxsupport

and Thread stuff, but centered on their cmsis code https://github.com/ARMmbed/mbed-os/blob/master/rtos/source/ThisThread.cpp

[lowlander]

@jrobeson std::thread and std::mutex, all have less functionality than Zephyr offers, for example stack size, time outs, etc. so then you end up with the question how to add that , because adding it to std:: makes it not std:: anymore. So my choice was not to start with std:: at all, of course that also has disadvantages. (seems the mbed ppl made the same choice with mstd::)

Another big difference is error handling , std:: needs exceptions, I didn't want that, so I experimented with other ways of error handling (not always easy when wanting the RAII concept)

providing nicities on to of threads (and others) is nice. I hope that it can somehow be interoperable when zephyr does add support for `std::thread' though.

As far as mbed goes, those folks didn't wanna create a whole new target and provide a toolchain like zephyr does. They also explicitly supported arm clang, iar, and other compilers, so it wasn't even reasonable for them to try.

[ShaharHD]

First of all, this is an impressive project!

@jrobeson std::thread and std::mutex, all have less functionality than Zephyr offers, for example stack size, time outs, etc. so then you end up with the question how to add that , because adding it to std:: makes it not std:: anymore. So my choice was not to start with std:: at all, of course that also has disadvantages. (seems the mbed ppl made the same choice with mstd::)

What about std::timed_mutex as he's offering timeouts etc., those capabitlies? can we assume std::thread and std::mutex will behave teh same and if timing is required, the timed varinets will supply this capability?

Another big difference is error handling , std:: needs exceptions, I didn't want that, so I experimented with other ways of error handling (not always easy when wanting the RAII concept)

Exceptions are not a must. Look at ETLCPP which avoids exceptions.

[lowlander]

providing nicities on to of threads (and others) is nice. I hope that it can somehow be interoperable when zephyr does add support for `std::thread' though.

I really didn't want to do anything std:: because you would have to be 100% standard conform and that was certainly not doable. Also Zephyr has features that can not easily be mapped to std:: C++.

So not sure what to do with the project, it is of no use when you want to build C++ that was not designed for Zephyr (and uses things like std::thread) so for my own little projects it is fine but of limited use to the zephyr project.

The zephyr project probably will have to create a 100% POSIX threading API to get std:: C++ support without tuning the compiler to much.