[Development] Qt containers and non-copyable types (was: Why can't QString use UTF-8 internally?)

[Thiago Macieira]

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