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.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
