On Tuesday, 23 de August de 2011 10:41:42 [email protected] wrote: > >I'm just in doubt about the implications of that and 6: if we use > >qStableSort > >internally, qStableSort is implemented on top of STL and that > >implementation > >makes function calls. > > I don't see this as a problem. We can simply have (actually: keep) our own > implementation of qStableSort that is being used when -no-stl is being set > at configure time. If STL support is enabled, we can use the STL algorithm > instead.
Hmm.... you're right. After rethinking a bit, I think I was making some
confusion on my own requirements, when I wrote the 2+4 clarification. When I
wrote that, I said that non-inline Qt code cannot ever call non-inline STL
code -- meaning that Qt libs would never link to libstdc++ if libsupc++ is
there.
But rereading what I proposed gives me now a different conclusion: if you don't
choose -no-stl (that is, if you choose QT_STL), then Qt is allowed to link to
libstdc++, the same way that a QT_STL application can link to it. The
requirement is that a -no-stl Qt doesn't link to it.
And the other requirement is that QT_STL be binary compatible with QT_NO_STL.
--
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 [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
