Unless someone speaks up within the next week with a very good reason we shouldn't do this, I'd like to declare that the -no-stl option is no longer supported.
I talked to João and Lars last Friday and we agreed there's really no point in
trying to keep code working without STL. There's hardly any real benefit -- the
ones I listed months ago amount to, at most, less than 100 kB.
We'd like to remove the option altogether, eventually, and the tests for
QT_NO_STL. But we don't need to do that now. We can just declare the option is
not supported and no one should use it.
The only noticeable side-effect of this change (aside from possibly longer
build times) is that compilers that *still* default to non-C++98-compliant STL
implementations will start facing compilation issues. I'd like to declare that
we WILL NOT accept #ifdefs for those compilers. C++98 support is mandatory as
of Qt 5.0 in STL and template support. Compilers that default to pre-C++98 STL
should get their act together. (the only case I know of is Sun Studio and
there are not one but two STL implementations available for it that are
compliant)
I've just accepted and approved a contribution that uses #include <memory>
unconditionally.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
