On Wednesday 11 February 2015 11:31:10 Matthew Woehlke wrote: > On 2015-02-10 19:44, Thiago Macieira wrote: > > ... they aren't useful because we'll never accept movable-but-not-copyable > > objects. An implicitly shared container implies a copyable contained > > object. > Wouldn't you just disable sharing (and indeed, copying the container at > all) if the type is non-copyable? (Isn't this what happens with > std::vector? I'd have to think yes...)
That would be required, but the problem is that it can't be easily implemented. Every non-const accessor function has a call to detach(), which requires the copy constructor. The best we could do in a Qt container for a non-copyable type is a const container. You'd have to create it in the constructor and NEVER modify it again. No emplace_back. > > For QVector, we might have to switch to qint64 or to qintptr or some other > > name for a *signed* integer type. > > If it has to be signed, ssize_t (okay, same as qintptr I guess, so > really I'm just voting against an always-64-bit type) would seem > preferable. (Why does it need to be signed? For methods that return 'not > found' I'd expect the all-1's value, a la std::string. Where do you > actually need a negative *value*, e.g. -N, not just -1?) There are a couple of functions that search backwards if you give them negative values. Also because we use signed everywhere and the warnings about comparing signed and unsigned are annoying. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development