[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
This strongly depends on the use case. std::list is good when you insert and remove often. We mostly don't have that. Also we often store pointers. In that case
std::list has 200% overhead. Also std:vector has a nice feature that you can sort it and find things faster. Therefore many people recommend std:vector over
std::lists. I think we can get some memory and speed enhancemetns with std::vector.
The problem with Big-O complexity estimation is that the constant
factors matter a lot for small problem sizes. I recall that at CPPCON
someone once did measurements and was able to show that std::vector
always wins below a certain list size.
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 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.
It is possible in theory, but it is a lot of custom work; out-of-the-box
support is rare. I rather imagine a future "C++11" architecture layer
that could unify posix, win32, and some select FreeRTOS targets. More
exotic targets would continue using their present code.
* use std::chrono - in the current implementation I never know what time unit to expect. And I know I'm not the only one because of a bug in OPC UA I found
some time ago.
For me the same as for std::thread
I think this is a safe suggestion. As long as we don't actually try to
read system timers but only use std::chrono as type system, it should
work on any device.
Regards,
--
Dr.-Ing. Jörg Walter
Gruppenleiter | Group Manager
Distributed Computation and Communication
OFFIS e.V. - Institut für Informatik
FuE Bereich Produktion | R&D Division Manufacturing
Escherweg 2, 26121 Oldenburg - Germany
Phone/Fax.: +49 441 9722-729 / -282
Mobile: +49 176 18811064
E-Mail: joerg.walter@xxxxxxxx
URL: http://www.offis.de
Registergericht: Amtsgericht Oldenburg VR 1956
Vorstand: Prof. Dr. Sebastian Lehnhoff (Vorsitzender),
Prof. Dr. techn. Susanne Boll-Westermann,
Prof. Dr.-Ing. Andreas Hein, Prof. Dr.-Ing. Wolfgang H. Nebel
Unsere Hinweise zum Datenschutz sind abrufbar unter:
https://www.offis.de/datentransparenz.html
