Uther (./24) :
Je ne dis pas que QtCore ne peut pas avoir d’intérêt, il y a des choses intéressantes dedans, je trouve juste dommage qu'elle soit la base de tout Qt et qu'on se trouve obligé de la subir même si on fait quelque chose qui pourrait très bien s'en passer.
Ce n'est pas dommage du tout, ce serait horrible si on devait subir les conteneurs STL dans les APIs. Il y a des développeurs (notamment Marc Mutz) qui voudraient tout remplacer par la STL, mais heureusement, il y a des développeurs qui s'y opposent. Il est maintenant autorisé dans Qt d'utiliser les conteneurs STL en interne (parce que si on les utilise de manière optimale, ils ont tendance à être plus rapides), mais pas dans les APIs.
Le problème avec les conteneurs STL est que l'absence de partage implicit fait qu'il faut toujours faire attention à éviter les copies, tout le bordel des moves et swaps rajoutés dans le C++11 ne sert qu'à ça. Ça donne du code difificilement lisible, alors que les conteneurs Qt peuvent être traîtés comme des scalaires sans perte d'efficacité.
Warpten (./25) :
QMultiMap -> (unordered_)?multimap
Seulement
multimap,
unordered_multimap correspond à
QMultiHash.
Les conteneurs tries de la STL sont, pour autant que je sache, quasiment tous des hash map, des arbres binaires ou des listes liees (ou se comportent comme tels), donc y a rien a bouger en mémoire, juste des pointeurs a changer.
Ça ne veut pas forcément dire que le tri par insertion dans ce conteneur sera plus rapide qu'un tri d'une liste (surtout une
QList, qui est un tableau de pointeurs – je ne comprends pas pourquoi tout le monde se plaint de
QList, le tableau de pointeurs est le meilleur compromis possible entre un vecteur et une liste chaînée).
./24 
Rien que QString est une aberration a mon sens. Certes, y a l'unicode, mais on a aussi std::wstring
La taille de
wchar_t n'est pas standardisée, donc ce n'est pas portable.
ou encore std::u(16|32)string, exotiques mais bien definis (Ce ne sont que des specialisations de std::basic_string<...>. Meme sices types n'ont aucune notion d'encodage, mais c'est voulu, puisque le C/C++ ne voit les chaines de caracteres que comme des tableaux de bytes...
C'est déjà une bonne raison de ne pas les utiliser. Et ensuite,
QString est partagé implicitement,
std::string ne l'est pas (il l'était dans d'anciennes versions de
g++, mais le standard C++11 l'interdit, donc
g++ a cassé l'ABI pour rendre
std::string moins efficace
).
Et WTF? 
On ne peut pas faire autrement, il n'y a pas de varargs non-POD en C++.
Je suis en revanche d'accord pour dire que <iostream> et les differentes versions de <fstream> ne sont que des horreurs. Pour avoir essaye d'ecrire mes propres facet, c'est absolument inutilisable.
Toute la STL est une grosse horreur, tout va ensemble et tout est également nul.
Uther (./29) :
Le problème c'est que je voudrais parfois faire de l'IHM, ou autre sans avoir a subir le framework et les contraintes qui vont avec.
Alors en réalité, ton problème n'est pas que Qt s'appuie sur QtCore, mais que la STL se veut une bibliothèque standard, mais ne propose toujours rien pour l'IHM.
La STL est pourrie et incomplète.
Uther (./31) :
Je sais bien que pour certain projets, Qt, dans sa philosophie, n'est pas l'outil qu'il me faut, mais le problème est que l'outil qu'il me faut n'existe pas et que Qt est ce qui s'en rapproche le plus.
À mon avis, ce que tu cherches est
gtkmm – c'est un binding C++ pour un pur toolkit graphique (GTK+) et ça utilise la STL (
std::string, conteneurs etc.).
)
Rien que 
).
