Un peu de calme, s'il te plait avant que ça ne dégénère, on peut discuter calmement.
Ben oui, C est Turing-complete, merci du renseignement.
On tourne en rond, c'est le fait que le C soit Turing-complet qui fait que la gstion des chaines n'a rien à faire dans la stdlib. Par contre les primitives d'ouverture de fichiers ou de gestion des signaux par exemple, que le C soit Turing-Complet ou pas, tu ne peut pas le faire sans l'aide d'une bibliothèque bas-niveau.
Ce sont des primitives qui sont la pour abstraire le système, qui sont indispensable et qui on leur place dans la stdlib, au contraire de la gestion des chaines.
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
Relis ce que j'ai écrit et tu verra que je n'ai jamais dis que la norme avais changé la gestion des chaine de caractères et c'est bien ce que je lui reproche et que je répette depuis plusieurs commentaires.
La norme pouvais le changer tout comme et à changé d'autres choses tout aussi importantes. Et le truc c'est que les gens on adopté la norme, et on changer leurs habitudes pour tout ce que la norme avait changer, donc, on en serait pas la si la norme avait changé la gestion des caractères.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
Et ? Ma remarque était juste la pour dire que ces fonctions ne sont pas des primitives bas-niveau mais déjà des fonctions plus haut niveau, la preuve étant que l'on trouve partout des versions en C avant d'en avoir des version en assembleur.
À moins que ta remarque ne soit pour me convaincre que les chaines terminées par 0 c'est nul car il faut des optimisations de fou pour avoir des perfs qui ressemblent vaguement à une autre implémentation. Parce que si c'est ça, je désespère que tu n'ais toujours pas compris que je suis d'accord là-dessus.
[^] # 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.
Ben oui, C est Turing-complete, merci du renseignement.
On tourne en rond, c'est le fait que le C soit Turing-complet qui fait que la gstion des chaines n'a rien à faire dans la stdlib. Par contre les primitives d'ouverture de fichiers ou de gestion des signaux par exemple, que le C soit Turing-Complet ou pas, tu ne peut pas le faire sans l'aide d'une bibliothèque bas-niveau.
Ce sont des primitives qui sont la pour abstraire le système, qui sont indispensable et qui on leur place dans la stdlib, au contraire de la gestion des chaines.
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
Relis ce que j'ai écrit et tu verra que je n'ai jamais dis que la norme avais changé la gestion des chaine de caractères et c'est bien ce que je lui reproche et que je répette depuis plusieurs commentaires.
La norme pouvais le changer tout comme et à changé d'autres choses tout aussi importantes. Et le truc c'est que les gens on adopté la norme, et on changer leurs habitudes pour tout ce que la norme avait changer, donc, on en serait pas la si la norme avait changé la gestion des caractères.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
Et ? Ma remarque était juste la pour dire que ces fonctions ne sont pas des primitives bas-niveau mais déjà des fonctions plus haut niveau, la preuve étant que l'on trouve partout des versions en C avant d'en avoir des version en assembleur.
À moins que ta remarque ne soit pour me convaincre que les chaines terminées par 0 c'est nul car il faut des optimisations de fou pour avoir des perfs qui ressemblent vaguement à une autre implémentation. Parce que si c'est ça, je désespère que tu n'ais toujours pas compris que je suis d'accord là-dessus.