> Sent: Monday, November 05, 2018 at 9:42 AM > From: rol...@logikalsolutions.com > To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com> > Cc: interest <interest@qt-project.org> > Subject: Re: [Interest] Chasing a standard > > > Quoting Jean-Michaël Celerier <jeanmichael.celer...@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. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
