C'est une mauvaise façon de faire pour parcourir une chaîne
A la place, si on tient absolument à utiliser strlen() :
size_t taille = strlen(mot);
for (size_t mot = 0; i <= taille_mot; i++) {
....
}
Pourquoi ? Parce que
le calcul de strlen(mot) se fait en parcourant le mot.
c'est un calcul qui prend un temps proportionnel à la taille du mot
si on le met dans la condition du for(;;) il sera refait à chaque tour, et il nous coûtera un temps proportionnel au carré de la taille. Chaine de taille 1000 => des millions d'opérations.
Rremède : comme c'est une valeur qui ne changera pas au cours de l'exécution de la boucle, normalement (*); on calcule la valeur et on la met dans une variable (caching) avant la boucle. Comme ça c'est fait.
[...]
Un autre remède est de le laisser en l'état car les compilos modernes savent très bien détecter et extraire les expressions constantes, quand on leurs demande et qu'on les renseigne bien.
Mais c'est clairement plus classique de le sortir soi-même, c'est vrai.
Il peut le faire par exemple pour for(int i=0; i<a+b; i++) si il infère que a et ne changent pas dans la boucle (*). Mais là strlen(mot) peut changer parce que mot peut changer.
(*) a condition que ça soient des variables locales, parce que sinon un autre thread pourrait y toucher en parallèle...
- Edité par michelbillaud 26 octobre 2021 à 20:36:03
Telle quelle, la seconde fonction n'est pas buggée à mon avis. La fin de chaîne est garantie. Si on enlève le strcpy et change la limite du for par i <= strlen(mot) ça va marcher.
Le Tout est souvent plus grand que la somme de ses parties.
Telle quelle, la seconde fonction n'est pas buggée à mon avis. La fin de chaîne est garantie. Si on enlève le strcpy et change la limite du for par i <= strlen(mot) ça va marcher.
C'est un langage très rudimentaire, même en le comparant à ce qui existait en 1972. Et en plus il est très mal défini, sa norme laisse un nombre invraisemblable de comportements indéfinis.
Un des objectifs était d'avoir un tout petit compilateur pour un petit langage, qui suffirait à remplacer la plupart du code bas niveau qui s'écrivait en assembleur. Pour écrire des applications, il y avait déjà Fortran (54), Cobol (61), PL/I (64), ... pour ne parler que des poids lourds.
---
pour revenir à un sujet précédent, quand on compile
void rempl1(char string[], char a, char b)
{
for (size_t i = 0; i < strlen(string); i++) {
if (string[i] == a) {
string[i] = b;
}
}
}
avec gcc avec optimisation plein-pot (-O3), on constate que le code généré appelle strlen dans la boucle, dans le cas où le caractère a a été remplacé. C'est le mieux que puisse faire l'optimisation.
Le code en assembleur, en enlevant les directives pour lire plus facilement
rempl1:
.LFB0:
// prologue de la fonction élagué
call strlen@PLT // appel strlen
testq %rax, %rax
je .L1
xorl %ebx, %ebx
.L5:
cmpb %r13b, 0(%rbp,%rbx)
je .L11 // si trouvé -> L11
addq $1, %rbx
cmpq %rax, %rbx
jb .L5
.L1:
// ... sortie de la fonction
ret
.L11:
movb %r12b, 0(%rbp,%rbx) <--------
movq %rbp, %rdi // remplacement
addq $1, %rbx
call strlen@PLT // on rappelle strlen
cmpq %rax, %rbx
jb .L5 // et on retourne dans la boucle si i < ...
// ... sortie de la fonction
ret
le code est bien sur different avec
void rempl2(char string[], char a, char b)
{
size_t length = strlen(string);
for (size_t i = 0; i < length; i++) {
if (string[i] == a) {
string[i] = b;
}
}
}
mais le mieux, c'est de tester sur le caractère sentinelle
void rempl3(char string[], char a, char b)
{
for (size_t i = 0; string[i] != '\0'; i++) {
if (string[i] == a) {
string[i] = b;
}
}
}
rempl3:
.LFB2:
jmp .L32
.L23:
addq $1, %rdi
.L32:
movzbl (%rdi), %eax
testb %al, %al
je .L33
.L25:
cmpb %al, %sil
jne .L23
movb %dl, (%rdi)
movzbl 1(%rdi), %eax
addq $1, %rdi
testb %al, %al
jne .L25
ret
- Edité par michelbillaud 31 octobre 2021 à 11:05:33
Il faut prendre le C pour ce qu'il est … et ce pour quoi il a été construit à l'époque. Il a juste eu un succès phénoménal, ce qui est à la fois une bonne chose et une mauvaise chose je suppose.
Pour autant ces évolutions ne sont absolument pas des soins palliatifs, il évolue comme il peut en traînant plus d'un demi siècle d'héritage et le boulet de la «compatibilité c++».
Certaines évolutions lui seront clairement hors de portée (je pense) comme l'ownership, les template, … mais il fait le job quand il est utilisé à bon escient.
Ensuite s'il ne faut qu'un type string natif pour avoir un vrai langage … tu peux toujours écrire ta propre bibliothèque pour ça, ou, à défaut, en choisir une parmi celles qui en proposent.
qu'il était fourni avec les premières versions d'unix distribuées gratuitement
qu'il était utilisé comme support d'enseignement prog systeme dans les universités américaines (parce que ci-dessus)
donc il s'est popularisé. Ce n'était pas forcément le langage de choix, je me rappelle qu'on développait plutôt sous PL/M sur CP/M, par exemple. Chez Apple, il y avait des variantes de Pascal.
Ce qui a contribué ensuite à son succès, c'est son adoption par Microsoft, période DOS et début de Windows. Jusqu'à ce qu'ils se décident à passer à C++ (puis passer à Java parce que c'était trop pénible pour la programmation plan plan, et suite aux embrouilles avec SUN, à C#)
De nos jours, l'évolution de C est quasiment bloquée. Il faudrait retrouver la rédaction exacte dans les minutes du WG, mais en gros l'ambiance c'est on arrête les dégats, et on n'introduit pas de nouveautés à part pour régulariser la compatibilité avec C++. On peut dire que C++ est un boulet pour C, l'inverse est vrai aussi depuis le début.
Thriving in a Crowded and Changing World: C++ 2006–2020, B Stroustrip, proceedings HOPL IV.
Pour les chaines, c'est vrai qu'on peut se faire une bibliothèque. Mais bon, avec n'importe quel langage de programmation, on peut toujours se faire une bibliothèque pour faire des trucs qui ne sont pas dans le langage. Y a t-il une bibliothèque pour C permettant d'utiliser facilement et efficacement les chaînes, et si oui pourquoi n'est elle pas arrivée dans la bibliothèque standard ?
- Edité par michelbillaud 31 octobre 2021 à 11:34:13
qu'il était fourni avec les premières versions d'unix distribuées gratuitement
qu'il était utilisé comme support d'enseignement prog systeme dans les universités américaines (parce que ci-dessus)
donc il s'est popularisé. Ce n'était pas forcément le langage de choix, je me rappelle qu'on développait plutôt sous PL/M sur CP/M, par exemple. Chez Apple, il y avait des variantes de Pascal.
Ah … tu parles de tous ces beaux «vrais» langages à l'imparfait … et nous continuons à parler du C au présent
michelbillaud a écrit:
[...]
De nos jours, l'évolution de C est quasiment bloquée. Il faudrait retrouver la rédaction exacte dans les minutes du WG, mais en gros l'ambiance c'est on arrête les dégats, et on n'introduit pas de nouveautés à part pour régulariser la compatibilité avec C++. On peut dire que C++ est un boulet pour C, l'inverse est vrai aussi depuis le début.
[...]
Bloquée en un sens, disons que ça reste un langage ancien qui a du mal à intégrer des concepts nouveaux et très récents (enfin plus ou moins).
Que C soit un boulet pour le C++, je vais aller jusqu'à dire que je m'en fous éperdument. Ceux qui font C++ n'avaient pas qu'à la vouloir cette «compatibilité» … ah ben si il fallait bien pouvoir s'insérer dans la base existante … En revanche que la «compatibilité illusoire» passe dans l'autre sens, et, pour moi, un non sens.
michelbillaud a écrit:
[...]
Pour les chaines, c'est vrai qu'on peut se faire une bibliothèque. Mais bon, avec n'importe quel langage de programmation, on peut toujours se faire une bibliothèque pour faire des trucs qui ne sont pas dans le langage. Y a t-il une bibliothèque pour C permettant d'utiliser facilement et efficacement les chaînes, et si oui pourquoi n'est elle pas arrivée dans la bibliothèque standard ?
- Edité par michelbillaud il y a environ 1 heure
pourquoi ? ptêt parce que le besoin ne s'en fait pas ressentir pour faire de C un «vrai» langage .
Je ne dis pas que c'est le meilleur, mais c'est certainement le plus couronné de succès. Quoi que tu en dises, les langages phares vont et viennent mais C reste … enfin pour l'instant.
Pour les chaines, c'est vrai qu'on peut se faire une bibliothèque. Mais bon, avec n'importe quel langage de programmation, on peut toujours se faire une bibliothèque pour faire des trucs qui ne sont pas dans le langage. Y a t-il une bibliothèque pour C permettant d'utiliser facilement et efficacement les chaînes, et si oui pourquoi n'est elle pas arrivée dans la bibliothèque standard ?
- Edité par michelbillaud il y a environ 1 heure
pourquoi ? ptêt parce que le besoin ne s'en fait pas ressentir pour faire de C un «vrai» langage .
Je ne dis pas que c'est le meilleur, mais c'est certainement le plus couronné de succès. Quoi que tu en dises, les langages phares vont et viennent mais C reste … enfin pour l'instant.
Bah, moi j'en dis rien, Lisp, Fortran et Cobol sont toujours là et donc il n'y a aucune conclusion à tirer que C soit toujours là. A part chute d'une météorite, je ne vois pas pourquoi un langage disparaîtrait du jour au lendemain. Il y a des milliards de lignes écrites avec, des gens qui se servent des programmes, on peut pas les jeter à la poubelle.
Le point important, c'est que si on a une application/un utilitaire à développer de nos jours, on va un peu plus réfléchir qu'il y a 20 ans avant de se précipiter sur C ou C++ pour la réaliser. Ce qui a tendance à ramener les deux langages vers la niche dont on les imprudemment laissés sortir.
Pour les chaines, c'est vrai qu'on peut se faire une bibliothèque. Mais bon, avec n'importe quel langage de programmation, on peut toujours se faire une bibliothèque pour faire des trucs qui ne sont pas dans le langage. Y a t-il une bibliothèque pour C permettant d'utiliser facilement et efficacement les chaînes, et si oui pourquoi n'est elle pas arrivée dans la bibliothèque standard ?
- Edité par michelbillaud il y a environ 1 heure
pourquoi ? ptêt parce que le besoin ne s'en fait pas ressentir pour faire de C un «vrai» langage .
Je ne dis pas que c'est le meilleur, mais c'est certainement le plus couronné de succès. Quoi que tu en dises, les langages phares vont et viennent mais C reste … enfin pour l'instant.
Bah, moi j'en dis rien, Lisp, Fortran et Cobol sont toujours là et donc il n'y a aucune conclusion à tirer que C soit toujours là. A part chute d'une météorite, je ne vois pas pourquoi un langage disparaîtrait du jour au lendemain. Il y a des milliards de lignes écrites avec, des gens qui se servent des programmes, on peut pas les jeter à la poubelle.
[...]
Bah si tu dis que le C n'a pas de type string natif alors que d'autres «vrais» langages le proposent … Et C est le seul langage de cet âge qui est toujours dans toutes listes des langages les plus utilisés/adoptés/… que ce soit les stats sur github/tiobe/… ou ailleurs.
On ne redéveloppe effectivement que rarement des solutions implémentée depuis fort longtemps ; mais à ma connaissance, il y a bien plus de nouvelles solutions développées en C qu'en lisp/fortran/cobol …
À nouveau je ne dis pas que C est meilleur que tout, mais son succès comme sa longévité ne sont pas anecdotiques et dues au hasard.
michelbillaud a écrit:
[...]
Le point important, c'est que si on a une application/un utilitaire à développer de nos jours, on va un peu plus réfléchir qu'il y a 20 ans avant de se précipiter sur C ou C++ pour la réaliser. Ce qui a tendance à ramener les deux langages vers la niche dont on les imprudemment laissés sortir.
> C est le seul langage de cet âge qui est toujours dans toutes listes des langages les plus utilisés/adoptés/… que ce soit les stats sur github/tiobe/… ou ailleurs.
L'indice tiobe mesure le nombre de requêtes faites sur les moteurs de recherche pour appeler au secours sur les langages de programmation. Soit essentiellement l'activité des débutants qui n'arrivent pas à faire leurs exercices.
Et ça tombe bien, C est encore (malheureusement) souvent employé comme premier langage pour l'enseignement à des gens qui ne programmeront plus jamais de leur vie (l'usage de C n'est pas de nature à leur donner envie). Avec le succès que l'on constate :-/ par exemple en regardant les questions qui sont posées sur ce forum.
Les projets Cobol ne se retrouvent pas sur github, parce que c'est pas là qu'on va y trouver le code "d'un grand acteur du service bancaire", (*) ou "du service de l'énergie" qui ne tiennent pas vraiment à publier leurs oeuvres :-) Et c'est pas le le type d'application passionnante qu'on va développer le soir à la chandelle pour en faire profiter les copains. Par contre il y a 90% de chances que ça serve à faire ta paie à la fin du mois, pour gérer tes sous à la banque et pour t'envoyer tes factures. Ou ton dossier si tu es à pole emploi.
C est sûrement plus utilisé (pour l'instant) que Cobol et Fortran - et beaucoup moins que Java, C#, Javascript, PHP etc mais les stats de Github et Tiobe, c'est pas vraiment des indicateurs pertinents.
> À la naissance de C il n'y avait pas de niches …
ne serait-ce que la première phrase du résumé, c'est parfaitement clair que si (jeu de mot)
The C programming language was devised in the early 1970s as a system implementation language
et il est apparu parce que Thomson n'avait à sa disposition qu'un PDP7 avec 8k mots de 18bits, sans logiciel utile. Et qu'il voulait un compilo qui tourne dessus, sans avoir à faire du dev croisé depuis une grosse machine.
A L'époque, au moins 4 niches
calcul scientifique
informatique de gestion
"intelligence artificielle" (ça existait déjà à l'époque)
et programmation système
à quoi s'ajoute le secteur des "langages à vocation pédagogiques" (Pascal, Basic) dont l'emploi a débordé un peu.
(*) il y a quelques décennies (1979), j'avais été le premier programmeur cobol (job de vacances) d'une caisse départementale d'une banque (le gros du boulot se faisait à l'échelon régional), et j'avais développé une petite chaine d'applications. En cobol 74 implanté partiellement (ouch !). 30 ans plus tard, mon successeur - qui a fait carrière dans la banque - m'a trouvé sur internet et m'a dit que l'appli existait encore, en évolution constante, évidemment. Les programmes qui servent à quelque chose, ça a la peau dure. Et non, personne n'a eu l'idée de les convertir en C.
- Edité par michelbillaud 31 octobre 2021 à 16:35:26
Du coup on oublie le «les vrais langages ont un type string natif» ?
Les vrais langages qui sont là pour développer facilement des applications, on n'oublie pas. Même C++ en a, std::string.
L'insuffisance notoire de C de ce côté là a une conséquence tragique : les débordements de tampon, et les problèmes de sécurité qui en découlent.
Qui se produiraient moins souvent si les programmeurs C (dont on ne peut pas supposer qu'ils soient moins compétents que les autres) n'avaient pas à jongler avec des ersatz de chaînes. Tout programmeur fait un certain pourcentage non nul de conneries, that's life, les chaînes C (le fait de devoir compenser leur absence, plutôt) donnent juste des occasions supplémentaires de se planter. Et ça marche.
- Edité par michelbillaud 31 octobre 2021 à 18:13:17
La version longue, c'est que les mots ont un sens dans un contexte.
Par exemple, quand on dit langage, ça parle de langues, de théorie des langages, de faculté d'énoncer des choses, de langage de programmation etc.
Vrai langage de programmation, aussi. Ca va de langage de programmation qui existe vraiment (certains langages n'ont jamais été implémentés), langage utilisé en vrai par les professionnels pour faire des trucs utiles (pas brainfuck et autres trucs pour acnéiques). Là c'était dans le sens de langage adéquat pour programmer facilement la plupart des applications, puisqu'on parlait de faire des trucs avec des chaînes.
- Edité par michelbillaud 1 novembre 2021 à 12:15:38
c'est bien de préciser le sens que tu donnes à «vrai» langage … parce qu'humour ou non, dire de C que ce n'est pas un «vrai» langage est un peu fort de café, surtout lorsqu'il s'agit «d'avoir un type string natif». Car la présence ou non de type string natif n'a pas grand chose à voir avec «programmer facilement la plupart des applications».
Dans ce cas, si tu as un environnement classique pour les app desktop comme gtk par exemple, tu n'as plus à te soucier de l'existence ou non d'un type string en C.
Quoique tu as sans doute raison, il vaut mieux utiliser du javascript qui est un des langages les plus utilisés par les professionnels actuellement.
Typescript corrige les problèmes de typage de Javascript, c'est un langage intéressant (avec les quelques bizarreries héritées de Javascript).
Mais bon, il ne se prête pas vraiment à un certain nombre de choses, du calcul scientifique intensif à l'informatique de gestion en passant par la programmation système bas niveau.
Quand on dit "il vaut mieux utiliser ceci cela", il est préférable de préciser pour quoi faire.
- Edité par michelbillaud 1 novembre 2021 à 15:08:40
Ca va de langage de programmation qui existe vraiment (certains langages n'ont jamais été implémentés), langage utilisé en vrai par les professionnels pour faire des trucs utiles (pas brainfuck et autres trucs pour acnéiques).
[...]
- Edité par michelbillaud il y a environ 6 heures
White Crow a écrit:
[...]
Quoique tu as sans doute raison, il vaut mieux utiliser du javascript qui est un des langages les plus utilisés par les professionnels actuellement.
[...] C est sûrement plus utilisé (pour l'instant) que Cobol et Fortran - et beaucoup moins que Java, C#, Javascript, PHP etc [...]
- Edité par michelbillaud 31 octobre 2021 à 16:35:26
après je ne sais pas moi … où est-ce que tu vas trouver du javascript ? réfléchissons … ah oui ! le web ! mais pas uniquement, toute application à base d'electron aussi !
Ensuite comme tu le dis, on peut largement agréger typescript et deno pour en faire un acteur majeur de la vie quotidienne de tout un chacun (enfin du moins en occident et an Asie).
Et comme selon toi, javascript possède un type string natif, c'est donc un «vrai» langage nous pouvons en arriver à la conclusion que javascript est un «vrai langage utilisé par des professionnels pour faire des truc utiles facilement» ; alors que C … non.
Tu dis non seulement que ce n'est pas un «vrai» langage car il ne possède pas de type string, et qu'on ne peut rien y faire facilement.
Ça se trouve, quand michebillaud dit que le C n'est pas un vrai langage, c'est pour rire, pour le descendre de son piédestal (c'est un langage souvent considéré comme incontournable) en caricaturant un de ses défauts ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.