[Interest] Chasing a standard

[roland at logikalsolutions.com]

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.

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