[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [4diac-dev] 回复: CSinglyLinkedList improvements
|
On 4/29/22 11:31, Jörg Walter wrote:
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 I
never had an opportunity to work with it so I don't have any
experience with it.
we use boost for the test framework. But never looked beyond
that.
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:
* use std::thread and synchronization mechanisms from STL,
that can be ported to embedded devices with not too much
effort
Here I'm not sure. It definitly is worth a look. But I have no
experience about it.
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?