On Tuesday 21 July 2015 17:11:42 Bubke Marco wrote: > Thiago Macieira <[email protected]> > > > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
