| Re: [4diac-dev] 回复: CSinglyLinkedList improvements |
On 2022-04-29 11:03, alois.zoitl@xxxxxx wrote:
On Fri, 2022-04-29 at 10:32 +0200, Davor Cihlar wrote:
So there are no more platforms that doesn't support STL?
AFAIK no. But up to now I'm personally considering STL mostly for new code. Haven't yet found time and need to rework the existing code.
Given that we are about to move beyond C++11, STL is a required dependency anyway. Even when targeting a freestanding C++11 implementation on microcontrollers, there are libraries out there that provide lightweight implementations of the more common STL parts. Not that I would expect this to work out-of-the-box, AFAIK such small targets haven't been tested for a while.
My colleague recently tested something on STM32 and it appeared
to have some potential, but it had unreliable ethernet interface
so he aborted further work on that hardware and we're currently
waiting for our own custom hardware.
Has anyone considered boost? I know it's often times avoided, but it has some more embedded friendly implementations. I.e. lists with static allocation. But Iwe use boost for the test framework. But never looked beyond that.
never had an opportunity to work with it so I don't have any experience with it.
In C++11, there is std::pmr::*, that would be a boost-less alternative to more controlled memory management for constrained targets. Even just some strategically placed vector::resize calls could eliminate any problems that might exist -- and like Alois I doubt that there is a problem in the first place. Don't optimize prematurely, i.e. until you have shown (measured) there is actually a problem.
I didn't know for std::pmr::*. I only saw some "DIY" allocators
that others have made. So thank you for that. :)
My only concern are embedded devices without an MMU. I don't know (yet? :)) how internals of Forte work and how those lists are used. If the memory fragmentation is an actual concern then it would limit the possibilities of an embedded device and a lot of memory would just be unused (to allow headroom on heap).
But if most lists need only a few elements, then everything would be allocated at startup and no reallocations would occur and that would be completely fine with an ordinary std::vector.
So my suggestion for static allocation is only for parts of Forte that are expected to run on embedded devices and only if it poses a thread of memory fragmentation.
But on the other hand, statically allocated lists also guarantee memory consumption. With them you can exactly know how much memory is needed. It can also increase application robustness.
I do understand that it can complicate things quite a bit, and it
also seems like Forte is not exactly designed for embedded device.
It's just a nice possibility to be able to run it on them. So I
guess I just need to wait for that hardware to arrive and collect
some experiences with how demanding Forte on embedded actually is.
I also have some other suggestions:Here I'm not sure. It definitly is worth a look. But I have no experience about it.
* use std::thread and synchronization mechanisms from STL, that can be ported to embedded devices with not too much effort
I think this will not be practical, due to the very different RTOSes that FORTE supports.
An example from personal experience: For FreeRTOS, there is a C++11 compatibility library out there that would allow this, but std::thread depends on thread-local storage. That needs explicit support from all of: device, toolchain, C library, and RTOS. In FreeRTOS, each and every board has a different approach to TLS, often none at all. The C library (newlib, picolibc, ...) must have matching support code, and the compiler must use the same mechanism.
I did that once from scratch for STM32+FreeRTOS, and I don't
remember it being it too hard to do. But I didn't support the
whole standard. Only thread, mutex, chrono, and a few other minor
things. I've made std::thread to act like the real one and it
didn't require TLS. To support stack size I needed to add
specialized functions, outside of C++ standard. I can imagine
implementing condition variables would be a pain, and especially
on many different platforms, but the question is if it's really
needed. Currently Forte uses semaphores instead.
So I'm suggesting using std::mutex and other constructs just as
simple wrappers for OS. It would be just like it's currently
implemented, but with a different namespace and class names (the
C++11 standard ones).
A developer only needs to be aware that if a code needs to run on embedded devices then only a subset of C++11 threading features can be used. Or do you thing it would be too confusing?