[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Thiago Macieira thiago.macieira at intel.com
Tue Jul 21 20:44:55 CEST 2015


On Tuesday 21 July 2015 17:11:42 Bubke Marco wrote:
> Thiago Macieira <thiago.macieira at intel.com>
> > > What about the conversion of std::vector to QVector and back. Do we get
> > > zero copy conversion?
> > 
> > Can't be done.
> 
> What about wrapping QVector around std::vector.

Can't be done either if we want to keep the implicit sharing and also avoid an 
extra allocation or extra indirection.

> In that case std::vector
> could be used in the internal implementation and application code.
> Interface would be still using QVector. Many developers I met who rejected
> Qt cited the argument what Qt is a closed island and not very operable with
> code which is using the standard library. What have made Qt productive 20
> years ago is maybe not a good advice for the future.

Please choose 3 of the 4:
 1) data compatibility (including moves) with std::vector
 2) implicit sharing
 3) access to the data is as indirect as a plain array
 4) one heap allocation (aside from "short vector optimisation")

You can't have all three, unless we get std::vector to store the reference 
counting for us.

QVector is currently 2+3+4.

1+3+4 would be a simple wrapper around std::vector, most likely deriving from 
it and adding extra methods for our convenience and API compatibility.

1+2+3 would be to allocate the reference counter on the heap (optimised to a 
slice allocator, probably), outside of std::vector's control. Since 
std::vector allocates, that's two heap allocations.

1+2+4 is not possible (not that I can see).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list