[Interest] Chasing a standard

[Jason H]

> Sent: Monday, November 05, 2018 at 9:42 AM
> From: roland at logikalsolutions.com
> To: "Jean-Michaël Celerier" <jeanmichael.celerier at gmail.com>
> Cc: interest <interest at qt-project.org>
> Subject: Re: [Interest] Chasing a standard
>
> 
> Quoting Jean-Michaël Celerier <jeanmichael.celerier at gmail.com>:
> 
> >> As I said a couple of times, we do not intend to break APIs in any major
> > way when moving towards Qt 6. That also implies that our container API is
> > there to stay. But where we can streamline/align with standard C++ in good
> > ways, we probably should try to do that.
> >
> > It's not only about breaking APIs but also breaking current observable
> > behaviour - i.e. performance. Currently if you're passing data across
> > threads - e.g. compute something in a thread and pass the result to the
> > main thread to display it - you generally pass a QVector / QList /
> > QWhatever that does implicit sharing, because the signal-slot mechanism
> > will do a copy of the object in any case across threads and doing two
> > atomic operations for a QVector copy is cheaper than creating a new
> > std::vector, calling malloc, and copying 500 ints however you look at it.
> > What is the option if Qt opts out from this ? put everything in shared_ptr
> > ?
> 
> Very good catch.
> 
> Battery powered embedded systems in the medical and industrial world  
> have wretched dynamic memory allocation. If the underlying  
> implementation does away with shallow/no-copy passing between threads  
> for some std:: version which requires giahugic (given 512 MEG total  
> working RAM) data sets with sluggish allocation (if enough memory  
> exists at all) this is an extreme price.

Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))

I've also attributed failures on long-running commodity hardware (RaspberryPis) to the memory fragmentation issue of dynamic memory. Interestingly, this is why other languages (C#, Java) have dynamic memory consolidation capability (i.e. Mark & Sweep, "Handles" (^) in the .NET C++ CLR). But as the JPL standard shows, you do not need to create non-deterministic garbage collection in your language. While I attributed this to failures on a Pi, I have actually researched and concluded that this indeed was the case on an embedded application on a PPC 860. Removing dynamic memory and reverting to fixed-arrays eliminated the crashes after months of run-time.  Unfortunately this is nearly impossible on a Pi with it's much larger software ecosystem.