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
