Re: [Qt5-feedback] Changing the definition of -no-stl
Hi Thiago, On Tuesday August 23 2011, Thiago Macieira wrote: Moreover, imagine an embedded device that wants to save space in the minimal base system: they could choose to compile Qt and all of their applications without STL, thus saving a few hundred kilobytes of libstdc++. But user applications could still use STL if they wanted and interoperate with Qt, only triggering the install of that lib. I wonder: have you measured that the size wouldn't be _smaller_ if Qt used the STL instead of its own container classes? :) Here's an idea: 1. Make the QTL name-compatible with the STL (let's call this QtSTL) 2. Use the std::names instead of the QNames everywhere (or make the namespace configurable). Then users had an actual choice: - If you want binary compatibility guarantees, and you don't trust your system STL to maintain it, go with the QtSTL. - Otherwise, pick any of the portable STLs that fit your needs: - minimal code expansion (promised, at least): QtSTL, miniSTL (from MICO) - maximum speed: system STL, EASTL, STLport,... That way, you'd allow competition between the QtSTL and any other STL. And the user would pick the one that best fit their needs instead of being forced to always carry the QtSTL with them, even if the rest of the application uses another STL. You could even lay back and support only compilation against QtSTL officially, I'm sure others would pick up the other STLs, if only you would add that flexibility. What do you think? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Changing the definition of -no-stl
On Thursday, 22 de September de 2011 09:08:02 Marc Mutz wrote: Hi Thiago, On Tuesday August 23 2011, Thiago Macieira wrote: Moreover, imagine an embedded device that wants to save space in the minimal base system: they could choose to compile Qt and all of their applications without STL, thus saving a few hundred kilobytes of libstdc++. But user applications could still use STL if they wanted and interoperate with Qt, only triggering the install of that lib. I wonder: have you measured that the size wouldn't be _smaller_ if Qt used the STL instead of its own container classes? :) No, I haven't, because no one has volunteered so far to rewrite the containers using STL. Here's an idea: 1. Make the QTL name-compatible with the STL (let's call this QtSTL) 2. Use the std::names instead of the QNames everywhere (or make the namespace configurable). Here's another: - rewrite the current Qt containers, using their current names, on top of STL, keeping full source and behaviour compatibility (including reference counting) That way, you'd allow competition between the QtSTL and any other STL. And the user would pick the one that best fit their needs instead of being forced to always carry the QtSTL with them, even if the rest of the application uses another STL. I don't think we're interested in following STL requirements. At least, I am not and I want to spend my time in things that aren't working, instead of rewriting what is. Your blog on the containers was very well written and pointed out many issues that could be improved, sure. Rewriting the Qt containers with their current API and behaviour as a reference-counting layer on top of STL could be the best of both worlds. Maybe for Qt 6. What do you think? Two STLs would never work. You have to pick one for the entire stack -- just ask the Solaris / OpenSolaris / Nevada people. Besides, we're under a guideline to keep source compatibility. Changing *everything* to use STL, including STL behaviour, is a conversation non- starter. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Changing the definition of -no-stl
On Thursday 22 September 2011 09:08:02 ext Marc Mutz wrote: Hi Thiago, On Tuesday August 23 2011, Thiago Macieira wrote: Moreover, imagine an embedded device that wants to save space in the minimal base system: they could choose to compile Qt and all of their applications without STL, thus saving a few hundred kilobytes of libstdc++. But user applications could still use STL if they wanted and interoperate with Qt, only triggering the install of that lib. I wonder: have you measured that the size wouldn't be _smaller_ if Qt used the STL instead of its own container classes? :) Here's an idea: 1. Make the QTL name-compatible with the STL (let's call this QtSTL) 2. Use the std::names instead of the QNames everywhere (or make the namespace configurable). [...] Having the names in sync with the rest of Qt and incompatible convenience functions like contains() are advantages of the Qt Containers. If you don't need or want that, just use the Standard Library containers directly, today. Andre' ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
