The Qt container classes QList<T>, QVector<T> etc. require their element types to be copyable. Since C++11, the STL containers require their element type to be copyable or movable only. Why do the Qt containers not support move-only element types?
Asked
Active
Viewed 1,770 times
15
Ralph Tandetzky
- 22,780
- 11
- 73
- 120
-
3Maybe nobody proposed/designed/implemented such an extension? Usually when something isn't done the reason is that nobody did it. – Kerrek SB Sep 15 '15 at 11:21
-
What Kerrek said :) Ultimately, it's people who allow things. You'll be more than welcome to implement binary-compatible emplacement for Qt5, or a whole new thing for Qt6. Get a Gerrit account, warm up your git, and start hacking :) – Kuba hasn't forgotten Monica Sep 15 '15 at 13:18
1 Answers
17
Qt bug #54685 has explicit confirmation from Qt developers that move-only types are not (and will never be) supported because of Qt containers' principle of implicit sharing.
When you copy one Qt container to another, you're not doing a deep copy—the containers share their contents internally. Only when a modifying function is called on a container does it detach, creating its own local copy of the contents. This allows Qt containers to be passed around through signals and slots (which is necessarily by value) without the performance plummetting.
This would of course be impossible when the contained type is move-only. And the ability to pass containers around by value (without copying their contents) is fundamental to Qt's meta-object mechanism, so I do not think it could be redesigned. Qt APIs rely on implicit sharing and pass containers around by value even where a move-only container would be passed by reference, so there is no easy way out.
Angew is no longer proud of SO
- 167,307
- 17
- 350
- 455
-
Directly connected slots are invoked without copying. Queued connections are handled with copying as many times as there are slots (so 0 or more times), but that's an arbitrary choice. One could have just one copy kept in a refcounted container, and these could be all moved in should the types be movable. I've been eyeing that code for a long time now and I might start working on a patch one day. – Kuba hasn't forgotten Monica Sep 15 '15 at 13:21
-
1Obviously, containers with non-copyable elements cannot be copyable themselves. In consequence, there is no implicit sharing necessary. The containers can stay copyable though, if the element types are copyable. Therefore, existing functionality is not reduced and signals and slots work as before. – Ralph Tandetzky Sep 16 '15 at 06:44
-
1@RalphTandetzky The problem is that current Qt APIs and processes *rely* on implicit sharing and pass containers by value even where a container without implicit sharing would be passed by reference. – Angew is no longer proud of SO Sep 16 '15 at 07:32
-
-
-
I don't yet understand "This would of course be impossible when the contained type is move-only.". Does the "This" refer to "Only when a modifying function is called on a container does it detach, creating its own local copy of the contents"? It appears to me that the need to detach will never arise for move-only types, since at the instant of trying to copy, a compile time error will arise. – Johannes Schaub - litb May 27 '17 at 13:21
-
@JohannesSchaub-litb Yes, "This" refers to "detach-on-modify." The last paragraph explains why it's a fundamental limitation for Qt: they rely on copying the containers when passing them around (and especially when sending them through signals/slots). So such a move-only container would be useless in Qt. – Angew is no longer proud of SO May 29 '17 at 08:34
-
@angew I still don't understand. Why does it have to be useful for qt rather than for its users? In my case I have uses for it, and the fact that Qt developers don't have uses for it prevents the move-only list? Do libraries exist to be used only by themselves? – Johannes Schaub - litb May 29 '17 at 16:14
-