Re: [4diac-dev] 回复: CSinglyLinkedList improvements

[Alois Zoitl <alois.zoitl@xxxxxx>]

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

This is one thing that I meant. The other point is that in our lists we mostly search for elements. Using sorted inserts and search on sorted std::vector is
AFAIK always outperforming std::list because of random access. I'm not sure if it was Herb Suttner or Scott Meyers but one of both had a rule of thumb that at
first you should always use std::vector and using any other STL container needs a dedicated justification. I would go with that rule also for new code in 4diac
FORTE.

> 
> 
> > > 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,