salut
je voudrais savoire comment faire une fonction
qui enleve des espaces de trop à une messge
ex: Salut le monde ...
le bon est : Salut le monde ...
-----
salut
je voudrais savoire comment faire une fonction
qui enleve des espaces de trop à une messge
ex: Salut le monde ...
le bon est : Salut le monde ...
Bonjour.
Remarque préliminaire: ce que tu demandes ne relève pas de l 'électronique, mais d' un logiciel.
Du coup, tu vois que tu n'es pas dans le bon forum....
Et enfin, enlever des espaces où? dans un document? dans une chaîne de caractères recus par un programme (lequel?)...
Et pour conclure: je ne vois pas de différence dans tes deux phrases.
Conclusion de la conclusion: pour avoir une réponse, il faut être précis.
A+
Il n'y a que dans le dictionnaire où 'réussite' vient avant 'travail'.
Code:/* fonction qui suprime les espaces successifs et n'en laisse qu'un seul. Usage ; DelSpace(chaine_Originale, chaine_Traitée); */ DelSpace(char *source, char *dest) { char i,flag, p; flag=0; /* Détecteur d'espace */ p=0; /* pointeur chaine recomposer sans espace doublon */ for (i=0 ; i < strlen(source); i++) { if (source[i] != ' ') flag = 0; /* pas d'espace copié */ if (flag == 0) dest[p++] = source[i]; /* si ok copier */ if (source[i] == ' ') flag = 1; /* espace détecté */ } dest[p]='\0'; /* terminer la chaine copiée */ }
Bonjour
Suppression des espaces superflus en raccourcissant la chaîne d'origine (chaîne à zéro terminal).
Code:void DelSpace(char* str) { char c, *p, *q; p = q = str; do while ((c = *p++) == ' ') ; while (*q++ = c); return; }
Bravo , sincèrement PA5CAL vraiment la maitrise total du C.
Mais de quoi couler, voir dégouter n'importe quelle débutant, une astuce sur chaque ligne sans aucun commentaire.LOL comme d'hab LOL
Code:void DelSpace(char* str) { char c; /* caractère lu */ char *p, *q; /* pointeur source, destination */ p = q = str; /* initialise les 2 pointeurs sur le 1er char */ /*Astuce, p et q sont ici que des pointeurs et seulement des pointeurs */ do /* faire tant que le '\0' fin de chaine n'est pas copié */ while ((c = *p++) == ' ') ; /* mettre le char source dans c */ /* incrémenter après le pointeur source */ /* si c == ' ' , continuer Astuce ici, la valeur copier sera dans c donc l'espace ne sera copier qu'une fois */ while (*q++ = c); /* copier le char source vers la destination */ /* incrémenter le pointeur destination après copie */ /* Test du Do while , Astuce , sous entendu si != 0 continuer */ return; }
Ouaip. Désolé pour le manque de commentaires. Et merci de les avoir rajoutés.
Par contre, je ne sais pas s'il faut vraiment parler d'astuce. Il s'agit selon moi seulement d'une utilisation spécifique, mais normale, du langage C.
Cela permet de s'approcher un peu plus du langage machine, et d'aider un peu les compilateurs qui auraient du mal à faire des optimisations (j'aurais même pu spécifier "register" pour la variable "c", si j'avais eu la garantie que cela était supporté par le compilateur).
Ne pas faire appel à ces soit-disant "astuces" reviendrait à utiliser le langage C comme n'importe quel autre langage de haut niveau, comme le Basic, le Pascal ou le Fortran. On y perdrait tout l'avantage de ce langage à la puissance souvent insoupçonnée.
On m'oppose souvent le motif qu'une telle approche n'est pas très lisible. Je pense que c'est faux, car c'est un point de vue qui suggère que le C se lit comme les autres langages, ce qui n'est pas le cas. Or, avec l'habitude, ces soit-disant "astuces" se lisent couramment et sans heurt (comme on lirait une partition de musique après quelques années de pratique). Pour ma part, après 20 ans de métier, je lis plus vite le code C (même très "tarabiscoté") que les commentaires qui l'accompagnent.
Mais ça n'empêche pas de devoir documenter le code, ce que je n'ai pas fait, et je m'en excuse encore.
Ok pour le terme "Astuce" un peu exagérer.
Le code que j'ai proposé était du type "bourrin" mais adapté à un débutant.
J'admet que le tien est mieux.
Je pense que le
avec un (c != 0) sous entendu méritait vraiment un commentaire.Code:do while (*q++ = c);
Dailleurs le code éclaté , ne génére pas plus de code asm.
Le gain de place est dans le code C exclusivement, avec une lisibilité diminuée.
J'ai lu ton code 3 fois avant de tout comprendre, j'imagine un débutant, il devra le lire 50 fois avant de tout pigé et encore pas sur.
Notamment l'utilisation des pointeurs, hyper simple ici , mais qui déroute la majorité des débutants.
Je ne vois pas trop l'intérêt de faire du C sans utiliser les pointeurs. Et ça vaut également dans le forum d'électronique, puisque la programmation en C des µcontrôleurs impose leur utilisation pour accéder aux ressources.Notamment l'utilisation des pointeurs, hyper simple ici , mais qui déroute la majorité des débutants
Il ne faut pas en avoir peur puisqu'il s'agit simplement d'un accès à la mémoire. Les utilisateurs de l'adressage indirect des µprocesseurs ne seront donc pas dépaysés.![]()
A+
Dernière modification par Jack ; 28/03/2007 à 20h37. Motif: mauvaise manip
Et finalement, tant qu'à optimiser, autant se passer du pointeur q![]()
A+Code:void DelSpace(char* str) { char c, *p; p = str; do while ((c = *p++) == ' ') ; while (*str++ = c); return; }
Une coupe Champ pour Jack![]()
ça me rappel le bon temps ...
Avec l'esprit ambiance K&R !
Mais pour répondre à ton post sur les pointeurs , j'ai vu des gars, diplome d'ingé en poche , utiliser des pointeurs non alloués et non initialisés , et insistés en disant "je ne fait pas d'erreur",
d'ou ma remarque sur les pointeurs...![]()
bonsoir,
juste sur le coup du register c'est un peu drole de croire que c'est d'actualite ... la logique d'optimisation aujourd'hui
n'est plus dans les langages mais dans le processeur ...
et bien malin celui qui pourrait croire que les optimisations d'il y a 20 ont encore aujourd'hui un interet ...
a+
Pas d'accord, les 2 sont importants.bonsoir,
juste sur le coup du register c'est un peu drole de croire que c'est d'actualite ... la logique d'optimisation aujourd'hui
n'est plus dans les langages mais dans le processeur ...
et bien malin celui qui pourrait croire que les optimisations d'il y a 20 ont encore aujourd'hui un interet ...
a+
Maitriser le langage comme le disais PA5CAL, permet de générer des codes compacts,très proches de ce que génère une compilation assembleur, même si les capacités mémoires sont de plus en plus conséquentes, c'est une discipline de l'esprit que tout bon développeur organisé doit avoir.
Ce qui se conçoit bien s'énonce clairement comme dis le dicton, et en programmation c'est une règle pour éviter les programmes à l'arrache que l'on rencontre trop souvent.
Ce n'est pas rendre service aux plus jeunes de leur faire croire que la qualité d'écriture est passé de mode, un peu comme si on décidait de tous écrire en langage sms sous prétexte que ça reste lisible et compréhensible (bien que parfois c'est très limite).
Personnellement je ne vois pas ou est l'incompatibilité entre bien écrire du code et profiter des optimisations matérielles.
@+
Ça c'est vrai dans certains cas très particuliers de code, sur certains processeurs très récents. Mais c'est faux dans la grande majorité des cas.
Même pour ces processeurs récents, dont l'optimisation matérielle n'est possible qu'au niveau des portions de code et de données qui leur sont visibles à un instant donné, il existe des techniques d'optimisation logicielles, qui font d'ailleurs l'objet de notes détaillées et assez conséquentes de la part des constructeurs. Et vouloir s'en passer conduit à des résultats proprement catastrophiques en terme de performance, que même la passe d'optimisation des compilateurs n'est pas en mesure d'atténuer de manière suffisante.
Par exemple, il est difficile de corriger une mauvaise utilisation des différents niveaux de cache, et carrément impossible de corriger une erreur dans le choix d'une méthode de calcul.
Pas d'accord.et bien malin celui qui pourrait croire que les optimisations d'il y a 20 ont encore aujourd'hui un interet
D'abord, il serait faux de croire qu'il n'existe qu'une seule sorte d'optimisation, qui serait en quelque sorte universelle et qui évoluerait avec le temps.
Pour chaque cas particulier, représenté par un processeur, un environnement matériel et logiciel et une fonction à réaliser, il existe des techniques spécifiques. Penser le contraire mènerait à ne pas terminer totalement la démarche d'optimisation.
J'admets que dans ce sens, les mêmes optimisations qu'on appliquait il y a 20 ans ne peuvent plus être appliquées de manière strictement identiques sur des configurations de conception récente. Mais ça ne signifie pas que les buts recherchés et les concepts qui permettent d'y parvenir soient foncièrement différents.
De plus, une part importante des microcontrôleurs actuels repose sur des architectures qui datent de plus de 20 ans (plus de 30 ans pour certains). Pour eux, les principes d'optimisation à mettre en oeuvre sont de ce fait toujours les mêmes aujourd'hui.
J'aurais dit dans le compilateur qui, je le confirme, ne sait pas tout faire.... la logique d'optimisation aujourd'hui
n'est plus dans les langages mais dans le processeur ...
A+