Skip to main content

[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.

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

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:

Back to the top