Non, ça c'est ta vision idyllique du langage C. En pratique le langage n'exprime pas tout ce qui est calculatoire, et c'est bien pour ça qu'on a notamment des fonctions de manipulation de chaînes (manipuler des chaînes, c'est aussi du calcul) dans la bibliothèque standard.
J'ai un peu de mal à comprendre ce que tu dis là. Tu dis que le langage n'exprime pas tout ce qui est calculatoire et que donc ils ont mit dans la stdlib les fonctions de manipulations de chaines pour palier à ce problème.
Le truc c'est que, comme tu le dis, la manipulation de chaine c'est purement calculatoire, et je te met au défi de me trouver une seule fonction de manipulation de chaine dans la stdlib qui ne peut pas être codé en C pure sans la stdlib.
Sur les 22 fonctions définies par string.h dans le standard, les sul soucis que tu vas avoir sont :
- strcoll et strxfrm qui sont liée à la gestion des locales, mais avec les primitive définie dans locale.h qui contient des fonction plus bas-niveau il n'y a plus de problèmes.
- strerror qui est une fonction systeme plus qu'une fonction de manipulation de chaine puisqu'elle sert à traduire un code d'erreur système en un message d'erreur.
Toutes les autres sont triviales à coder en C pur et j'irais même plus loin, presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Seule les vrai fonctions non calculatoire qui sont des appels systèmes ne peuvent être codée en C pure et nécéssite un petit bout d'assembleur. Et celles là mérittent vraiment leur place dans une lib bas-niveau.
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Ce n'est pas hors-sujet du tout. Ce qui est utiliser actuellement c'est la version standard et pas la version de base. La norme à changé beaucoup de choses et les gens ce sont adaptés, à part dans de vieux codes on ne voit plus les anciennes version des prototypes de fonctions.
Donc si la norme à pus changer ce genre de choses elle aurait très bien pus changer la stdlib afin que celle-ci n'incite plus les dev à utiliser cette convention.
Il faut bien voir que cete convention c'est imposée et perdure encore aujourd'hui par ce que c'est la manière la plus simple de gérer les chaines de caractère de façon portable car si tu veux une autre gestion il te faut soit tout recoder à la main, soit utiliser une lib qui n'a pas pus se déveloper suffisament et être largement diffuser car une solution simple et pas trop muvaise éxistait.
Le comité de normalisation était la justement pour virer toutes les merdes des différentes versions du C, et s'il ont réussit sur certains points, ce n'est pas le cas pour la stdlib ou ils en ont encore trop laissé.
[^] # Re: Humm...
Posté par beagf . En réponse à la dépêche Sortie de la version 2.11 de la bibliothèque standard C GNU (glibc). Évalué à 1.
J'ai un peu de mal à comprendre ce que tu dis là. Tu dis que le langage n'exprime pas tout ce qui est calculatoire et que donc ils ont mit dans la stdlib les fonctions de manipulations de chaines pour palier à ce problème.
Le truc c'est que, comme tu le dis, la manipulation de chaine c'est purement calculatoire, et je te met au défi de me trouver une seule fonction de manipulation de chaine dans la stdlib qui ne peut pas être codé en C pure sans la stdlib.
Sur les 22 fonctions définies par string.h dans le standard, les sul soucis que tu vas avoir sont :
- strcoll et strxfrm qui sont liée à la gestion des locales, mais avec les primitive définie dans locale.h qui contient des fonction plus bas-niveau il n'y a plus de problèmes.
- strerror qui est une fonction systeme plus qu'une fonction de manipulation de chaine puisqu'elle sert à traduire un code d'erreur système en un message d'erreur.
Toutes les autres sont triviales à coder en C pur et j'irais même plus loin, presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Seule les vrai fonctions non calculatoire qui sont des appels systèmes ne peuvent être codée en C pure et nécéssite un petit bout d'assembleur. Et celles là mérittent vraiment leur place dans une lib bas-niveau.
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Ce n'est pas hors-sujet du tout. Ce qui est utiliser actuellement c'est la version standard et pas la version de base. La norme à changé beaucoup de choses et les gens ce sont adaptés, à part dans de vieux codes on ne voit plus les anciennes version des prototypes de fonctions.
Donc si la norme à pus changer ce genre de choses elle aurait très bien pus changer la stdlib afin que celle-ci n'incite plus les dev à utiliser cette convention.
Il faut bien voir que cete convention c'est imposée et perdure encore aujourd'hui par ce que c'est la manière la plus simple de gérer les chaines de caractère de façon portable car si tu veux une autre gestion il te faut soit tout recoder à la main, soit utiliser une lib qui n'a pas pus se déveloper suffisament et être largement diffuser car une solution simple et pas trop muvaise éxistait.
Le comité de normalisation était la justement pour virer toutes les merdes des différentes versions du C, et s'il ont réussit sur certains points, ce n'est pas le cas pour la stdlib ou ils en ont encore trop laissé.