wchar_t est indéfini et dépendant de la plateforme. Tout le contraire de ce qui est pratique à utiliser (i.e. un truc bien défini et constant quelque soit la plateforme)
wchar_t a très peu d'intérêt, et maintenant que le C++ peut définir des litéraux UTF-8/16/32, je pense qu'il n'en a plus du tout. Poubelle.
Ensuite, UTF-32 est très facile à manipuler (tout caractère peut être défini par un seul Uint32). Et comme SFML est faite pour bosser sur des PCs relativement à l'aise niveau mémoire, et qu'elle n'implique en général pas des chaînes de caractères énormes, je ne vois pas l'intérêt de se priver d'une telle facilité d'utilisation.
Ma philosophie c'est d'optimiser ce qui pose problème. Avec de tels raisonnements ("
pourquoi pas X étant donné que Y consomme plus de mémoire/CPU/... ??") on se retrouve vite à bosser sur des trucs inutiles, et à finir avec une API pas pratique. Et puis en allant au bout du raisonnement, pourquoi ne pas bosser en assembleur directement ?
