"At best, Qt would simply wrap around some STL components if they're present, but (1) I don't expect any useful standardization until somewhere around 2012, (2) I don't expect compiler support to be there for a long time, (3) Qt, especially in the embedded department, is intended to REPLACE STL, not USE STL.
Qt is supposed to provide a consistent API and behavior across platforms; Qt is still going to have to provide those behaviors on platforms that don't have good compiler/library support for it yet. Therefore, Qt will either have to have two versions of the code -- one that uses STL, one that doesn't -- and have to try to keep them always behaving the same way, or it can just not try to worry about using STL and just make sure to remain COMPATIBLE.
Qt can't remove classes without breaking API, so at best it won't be until Qt5, but at the same time, Qt is replacing a lot of STL's uglier classes. You can't compare std::string to QString. You can't even compare std::wstring to QString. You can try to compare std::vector with QList or QVector, but Qt just offers MUCH better APIs for them, as well as a lot more useful functions.
C++0x may be useful for Qt's internal implementation when it's available, but the C++0x STL won't be any more helpful to Qt than the C++98 STL."
For more about C++0x, see here.
Note: ahigerd is an independent programmer, not a Nokia employee.
Update (11/Nov): Fixed last sentence in quote.

2 comments:
Your quote ends wrong, he didn't end the sentence there. It also results in a grammatically incorrect sentence.
"C++0x may be useful for Qt's internal implementation when it's available, but the C++0x STL won't be any more helpful to Qt than the C++98 STL."
Love,
ChrisInAJar
@chrisinajar: Thanks for the correction.
Post a Comment