On 02/02/2020 17:34, Alberto Mardegan wrote:
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote:Il 01/02/20 12:44, Alberto Mardegan ha scritto:On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote:About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name?A Qt-ish API!Example?A data() method :-)
Upstream is settling on the convention of having data() on things that also have size(). Smart pointers lack the latter so they don't have the former.
Is it questionable? Sure. In principle, data() on smart pointers may actually be added (in the sense that it would be 100% backwards compatible). Do you happen to have a proposal for it?
Is this a difference so big and important to justify diverging from it? I am very unconvinced.
It's not clear to me what you mean by "alias"; if you mean a subclass, then I'd be against it, because there's a (very small indeed) risk that in the future the STL adds some methods that might conflict with ours, or would not be Qtish enough.I mean a type alias: using QUniquePointer = std::unique_ptr;It still bring the risk of the STL adding some weirdly named methods (such as empty()) which we don't want to have in a Qt class.
And in fact I am NOT proposing to add such an alias at all, but to use std::unique_ptr as-is.
1) It's still NIH;Which is not bad per se, in absolute terms.
* If it's worth economically is a question for who pays the bills. * If it's worth technologically: I still don't see a use case that* I can tell you for sure it's not worth from a learning (and teaching) point of view.
2) The probability of future C++standards adding features that won't be available in the Qt counterpart is 100%;They could be added, and the effort should be minimal (copy the code from STL).
There's no "code from STL". The Standard is a specification, not code. If you meant to copy from an _implementation_: it has not happened in the last 9 years (see the examples I brought in the other email), what grounds do you believe it will start now? (Not to mention the legal problems associated with this.)
3) Explain why Qt should raise arbitrary interoperability barriers literally "for the sake of it";We can easily provide static fromStdUniquePtr and toStdUniquePtr methods, and there wouldn't be a barrier.
We could also use std::unique_ptr directly and there would be even less of a barrier. I asked why put this barrier in the first place, not how to reduce this barrier. (And I also asked about shared_ptr)
4) Please justify the teachability efforts involved in explaining all of the above to Qt users.You can explain it to our users by saying that we want a consistent API, and that while Qt is interoperable with the STL, it can be used without it (and as an alternative to it).
Qt cannot be used without a Standard Library. The question for the future is how do we make the maximum out of it.
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
