[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