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?
* Is it just going to be an alias, to be more Qtish? Then why QSharedPointer is NOT going to be an alias? * Is it not going to be an alias? NIH all over again?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;
If we can resue the STL implementation, that's a good thing, but it should be an implementation detail; and I don't think we should care about NIH, when we are talking of classes that are unlikely to pose a great maintenance burden.
1) It's still NIH;2) The probability of future C++standards adding features that won't be available in the Qt counterpart is 100%; 3) Explain why Qt should raise arbitrary interoperability barriers literally "for the sake of it"; 4) Please justify the teachability efforts involved in explaining all of the above to Qt users.
Cheers, -- 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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
