On Friday 27 January 2012 18:28:26 you wrote: > On Friday 27 January 2012 18:02:02 André Pönitz wrote: > > On Friday 27 January 2012 17:49:01 ext Jonas M. Gastal wrote: > > > On Friday 27 January 2012 09:42:19 Charley Bay wrote: > > > > > /me wonder why we still even care about QT_NO_STL > > > > > > > > > > > > > > > Embedded? > > > > > > > > +1 > > > > > > > > Further, half of C++ developers *hate* STL. (Long story, off-topic > > > > for > > > > here.) > > > > > > > > --charley > > > > > > So? It's not like we are telling them to use, just having Qt use it.... > > > > The #includes pull in a few tens of thousands heavily templated code > > which used to have visible impact on compile times, for the dubious > > benefit of being able to access things like > > > > QString fromStdString(const std::string &s) > > > > I am not sure how the situation looks nowadays. > > And this is because we want to support compiling Qt with QT_NO_STL that we > were forced to put that function in the header. > If we were able to have QString::fromStdString in qstring.cpp we would just > include <string> from qstring.cpp instead of from the headers.
Honestly, I'd be perfectly fine with QString::fromStdString disappearing [which is a quite bad API anyway, most notably because of the unclear encoding] and handling the the cases in qvector.h etc by a template functions (similator to what std::vector has). I understand at VC6 times this was not possible, but should work on all supported platforms nowadays. Now, the only problem is the "mostly-SC promise:, so I guess it won't happen... Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
