[Development] The future of QtAlgorithms

André Pönitz andre.poenitz at nokia.com
Mon Jan 30 10:43:43 CET 2012


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'



More information about the Development mailing list