Em terça-feira, 3 de maio de 2016, às 17:00:15 PDT, Olivier Goffart escreveu: > Because of the convention that we do not want our ABI to depends on the > STL's ABI. So we can't use standard container in the signature of > exported functions.
Which has saved our hides twice in the past few years already. Once with Apple's switch to libc++ and more recently with GCC/libstdc++'s breaking of the std::string ABI. > The closest we have to unique_ptr in Qt is QScopedPointer. > With the difference that QScopedPointer is not movable. > Personally, i think we should add a move constructor to QScopedPointer, but > this has already been discussed there and the concensus was against it: > http://lists.qt-project.org/pipermail/development/2013-September/012882.htm > l Either we should reopen the discussion or create a QUniquePointer. (Or we > should allow std types in our ABI) The problem with using the C++11 features of the Standard Library is detecting what is supported. There is no monotonically-increasing version number for some of the implementations (read: libstdc++), so we don't know which one we may be compiling against. For example, GCC achieved full C++11 *language* support in version 4.8.1, but the Standard Library support lagged behind and *still* is incomplete in some areas: https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html Compare with: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/ status.html#manual.intro.status.iso And that's not even bringing Android and QNX into the mix, which replace the GPLv3-licensed libstdc++ with a more permissively-licensed implementation (Dinkumware, Apache STLport, libc++). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
