Uther (./420) :
Ceci dit, Ils auraient quand même pu faire un effort pour intégrer proprement ce qui est standard.
Par pitié, non! L'implémentation Qt est généralement beaucoup plus simple à utiliser que l'implémentation STL: partage implicit (copie à l'écriture), noms de méthodes plus clairs, API plus complète (la STL est souvent minimaliste, il n'y a souvent pas de méthode pour les opérations en O(n) ou plus, mais il arrive qu'on ait besoin de les utiliser et que changer de conteneur n'est pas la bonne solution pour une raison ou pour une autre, et il manque aussi souvent des surcharges simplifiées comme un
std::sort sur le conteneur entier, sans devoir passer les itérateurs
begin et
end à chaque fois) etc.
Qt a déjà déprécié certaines choses au profit de la version STL et à chaque fois, ça a empiré les choses. Par exemple, la plupart du header
QtAlgorithms a été déprécié, et du coup, à la place de
qSort(foo), il faut écrire
std::sort(foo.begin(), foo.end()).
Ils ont aussi déprécié
Q_FOREACH, le
foreach optimisé pour les conteneurs Qt, en faveur du ranged-
for C++11, qui 1. ne copie pas le conteneur dans une variable
const (comme le fait
Q_FOREACH) et 2. n'utilise pas les méthodes Qt
constBegin et
constEnd, donc les conteneurs Qt voient ça comme une écriture et détachent pour rien (le comportement en 1. est fait pour ne pas recopier les conteneurs non-partagés de la STL, mais il est contreproductif pour les conteneurs partagés de Qt) et à cause de 1., ça foire aussi (les itérateurs deviennent invalides) si le code dans la boucle modifie le conteneur (alors qu'avec
Q_FOREACH, dans ce cas, le conteneur détache et la boucle continue à énumérer le conteneur d'origine). Il existe un workaround,
qAsConst, pour le détachement inutile, mais là aussi, ça fait du code moche à copier-coller. Et
qAsConst ne gère pas les rvalues parce que le futur
std::as_const sous discussion ne les gèrera pas et les mêmes développeurs qui remplacent les fonctionnalités Qt par ces horreurs STL sont passés à volontairement limiter les fonctionnalités de Qt pour ne pas dépasser la STL limitée.
Bref, à mort la STL et non au remplacement de Qt par ses horreurs illisibles!
(je trouve que c'est ce qui amène le plus de discussions et donc qui fait la différence entre yN et un newsfeed ^^)
Par pitié, non! L'implémentation Qt est généralement beaucoup plus simple à utiliser que l'implémentation STL: partage implicit (copie à l'écriture), noms de méthodes plus clairs, API plus complète (la STL est souvent minimaliste, il n'y a souvent pas de méthode pour les opérations en O(n) ou plus, mais il arrive qu'on ait besoin de les utiliser et que changer de conteneur n'est pas la bonne solution pour une raison ou pour une autre, et il manque aussi souvent des surcharges simplifiées comme un std::sort sur le conteneur entier, sans devoir passer les itérateurs begin et end à chaque fois) etc.
Ils ont aussi déprécié Q_FOREACH, le foreach optimisé pour les conteneurs Qt, en faveur du ranged-for C++11, qui 1. ne copie pas le conteneur dans une variable const (comme le fait Q_FOREACH) et 2. n'utilise pas les méthodes Qt constBegin et constEnd, donc les conteneurs Qt voient ça comme une écriture et détachent pour rien (le comportement en 1. est fait pour ne pas recopier les conteneurs non-partagés de la STL, mais il est contreproductif pour les conteneurs partagés de Qt) et à cause de 1., ça foire aussi (les itérateurs deviennent invalides) si le code dans la boucle modifie le conteneur (alors qu'avec Q_FOREACH, dans ce cas, le conteneur détache et la boucle continue à énumérer le conteneur d'origine). Il existe un workaround, qAsConst, pour le détachement inutile, mais là aussi, ça fait du code moche à copier-coller. Et qAsConst ne gère pas les rvalues parce que le futur std::as_const sous discussion ne les gèrera pas et les mêmes développeurs qui remplacent les fonctionnalités Qt par ces horreurs STL sont passés à volontairement limiter les fonctionnalités de Qt pour ne pas dépasser la STL limitée. 
)
