Il 20/12/19 16:05, Vitaly Fanaskov ha scritto:
I'm not totally sure I understand this point. What do you mean by "memory management"?Inside of containers you need to allocate and de-allocate memory. If container is passed across a library boundary, there is a question what version of new/delete should be used. But this can be "easily" solved by providing allocators. Probably.
And this isn't a problem. All over Qt we pass ownership of objects, and we have the full 2x2 matrix of "Qt creates object"/"user create object" vs "Qt destroys object"/"user destroys object". All of this uses plain new and delete.
Binary compatibility of stdlib is not an issueSo, you think that this is easy to achieve binary compatibility with many C++ compilers and standard libraries we have? For example, if Qt is built with one version of MSVC, but used in a program build with another version of MSVC. This is nice if there are some guarantees at least for main platforms. I heard that gcc and clang give some guarantees, but this not enough, I think.
That is, IMNSHO, 100% not Qt's problem. That ship has sailed, by the way; Qt doesn't care any more (and shouldn't care again) about stdlibs binary compatibility. We now expose std:: datatypes in Qt ABI.
consistency for containers shouldn't really be eitherRegarding consistency, it's not only containers' implementation. This is also about Qt APIs consistency: if it will be decided using std::* containers, they should be used instead of all Qt containers, but not instead of some of them. I guess, we should provide more or less solid user experience.
Sorry if I wasn't clear, but I was not saying to use std::* containers in our APIs, in lieu of QHash; I was wondering why not to use it in its _implementation_ (while fully keeping QHash APIs, behaviors, and so on).
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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
