3

I want to ask this question again, despite Why do Qt's container classes not allow movable, non-copyable element types? . I have read the following statement by QtCore maintainer Thiago (linked from the linked Stackoverflow question's answer):

Will not be implemented, ever. Copyability is a mandatory requirement due to implicit sharing.

I do not understand this statement: Copyability is a mandatory requirement for implicit sharing, I understand that part. But why is implicit sharing a requirement for a non-copyable QList<T>?

QList already has move-constructors and move-assignment-operators, so assuming that constructing a QList<T> from another temporary QList<T> will not apply implicit sharing, but move the underlying d-pointer, in what cases will implicit sharing arise when only copying/assigning temporary/rvalue QLists around?

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • When it comes to "Qt and why not" evetything points to the decisions made in the past that conflict with newer paradigms. – rubenvb May 27 '17 at 14:16

2 Answers2

1

All Qt container classes are implicitly shared. This is not something negotiable. How else would you want a signal that emits a QList by value be connected to more than one slot? Without move semantics or without implicit sharing you'd get lots of copies flying around. With move semantics all but the first slot will get an empty (well, unspecified moved from) list. So implicit sharing becomes a necessity in the case of the rest of their API details which contains way too much by value, because why wouldn't they? Everything is implicitly shared anyway.

To summarise: I don't think Qt wants to make exceptions to the implementation of any of their containers such as making a move only list not implicitly shared, whereas any other list would have this implicit sharing. The difference in side effects is just too big.

Also note that at least when reading between the lines, they are moving more towards std containers, although having those appear in the API will take more than anyone'd like...

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • But they can just give a compiler error when trying to emit a move-only type (such as a move-only QList). I can already write a move-only type and try to emit a value of it, and will hopefully get an error message (haven't tried). Why would they need to make exceptions for move-only lists? They would still be implicitly shared, but the implicit sharing will never be needed, because a copy will never be done nor allowed. But from what they write in the linked bugreport, even move-only QLists would need to be implicitly shared - I yet need to understand why. – Johannes Schaub - litb May 27 '17 at 14:29
0

It might be because QLists are marked only as reentrant, but not thread safe (definition).

I haven't looked at the source code, but guess that the overhead of maintaining a thread safe QList exceeds to cost of supporting a normal user (of course this is just fake excuses :P).

When T is a pointer or a reference, it might mean that multiple memory spaces have to be synchronized when altering an object in a list - this seems outside the scope of the Qt framework. I can also imagine this becoming complicated for Qt if there is some factory in the main thread instantiating objects. Or when when an object owns references/pointers to threads or callbacks.

Probably shouldn't be responding to any of your questions, but this got longer than a comment.

Community
  • 1
  • 1
vincent
  • 1,370
  • 2
  • 13
  • 29