Discussion :

[imperio]

Tu me fais perdre la foi des compilateurs. Pour le moment pas de problemes a deplorer (j'ai pas update gcc depuis... un certain temps ). Bref, tu viens de me convaincre de pas le faire tout de suite !

[JolyLoic]

C'est, par exemple, la raison pour laquelle les *fstream prennent le nom du fichier sous la forme d'un const char *, afin de ne pas rajouter de dépendance vis à vis de std::string

C'était une mauvaise raison, et ça a été corrigé en C++11

Le problème de la fonction split, c'est qu'elle devrait fournir plusieurs chaines au départ d'une seule et qu'il est hors de question de risquer d'en perdre une au passage.

Il faudrait donc placer les sous chaines dans une collection, mais laquelle un vecteur une liste un set une pile ou une file

Quelle que soit la solution envisagée, il y aurait toujours quelqu'un pour estimer que ce n'est pas la bonne

Il y a une proposition pour ajouter un split au standard (et un join), elle est arrivée trop tard pour C++14, mais je compte bien qu'elle soit là dans un TS, et au pire pour C++17.

Une version qui retournerait des string_view serait aussi appréciable.

[JolyLoic]

Même sous linux, tu as le problème avec les bibliothèques statiques et dynamiques écrites en C++...

Pour l'instant, la seule ABI pour laquelle il existe une spécification standard, c'est l'ABI C.

Il existe tout de même l'ABI Ithanium (http://refspecs.linux-foundation.org/cxxabi-1.83.html) qui est utilisée dans pas mal d'endroits, et l'ABI microsoft du moment qui est un standard de fait auquel d'autres compilateurs essayent de s'accrocher...

Il est donc "tout à fait possbile" (attention, je ne dis pas que c'est systématique, hein ) que l'ABI C++ change d'une version de VS ou de Gcc (ou de clang ou de n'importe quel compilateur C++ ) à une autre.

Ca dépend de la politique du créateur du compilateur. Certains ne veulent pas se restreindre, et s'autorisent à la changer à chaque version. D'autres ont la même depuis 15 ans, quitte à ne pas supporter des aspects du langage qui demanderaient de la modifier.

Et je peux dire que la question de savoir si une modification du langage impose ou pas une modification de l'ABI est omniprésente lors des discussions de normalisation.

[imperio]

C'était une mauvaise raison, et ça a été corrigé en C++11

Il y a une proposition pour ajouter un split au standard (et un join), elle est arrivée trop tard pour C++14, mais je compte bien qu'elle soit là dans un TS, et au pire pour C++17.

Du coup ils ont choisi quel conteneur ? vector ? list ? Autre ? Qu'est-ce qu'un TS par ailleurs ?

Une version qui retournerait des string_view serait aussi appréciable.

Qu'est-ce que tu entends par string_view ?

Il existe tout de même l'ABI Ithanium (http://refspecs.linux-foundation.org/cxxabi-1.83.html) qui est utilisée dans pas mal d'endroits, et l'ABI microsoft du moment qui est un standard de fait auquel d'autres compilateurs essayent de s'accrocher...

Pourquoi ils essayent de s'accrocher ? Ils rajoutent des nouveaux trucs en permanence ou ils passent leur temps a changer la structure deja existante (ou les deux) ?

[koala01]

Pourquoi ils essayent de s'accrocher ? Ils rajoutent des nouveaux trucs en permanence ou ils passent leur temps a changer la structure deja existante (ou les deux) ?

Ben, comme toujours, il y a deux cas:

Soit l'ABI est stable, et il y a donc des modifications (nouvelles fonctionnalités) que l'on refuse d'apporter pour ne pas avoir à la modifier

Soit l'ABI (celle utilisée par le compilateur de microsoft, par exemple) est susceptible de changer "sans préavis" car elle ne dépend que "du bon vouloir" de l'éditeur d'un compilateur et l'éditeur de compilateur qui essaye de suivre cette ABI fait "tout son possible" pour la respecter le plus rapidement possible.

Et quand on sait que "certaines firmes" ont des habitudes de communications disons... particulières (), il est parfois "assez difficile" de suivre les changements qu'elles ont apporté à leur ABI