J'ai écrit une fonction qui remplace la virgule par un point dans une chaine de caractères pour ensuite permettre de faire un
calcul.
Pour copier une chaine dans une autre chaine, j'utilise memcpy.
Est ce nécessaire d'écrire
memcpy(ch, c, sizeof(char) * taille);
ou bien je peux me contenter d'écrire
memcpy(ch, c, taille);
Toutes critiques sur la fonction seront les bienvenues.
Merci.
Alain CROS
#include <string.h>
int convstrnum(int taille, char *c)
/* Remplace, dans une chaine de caractères représentant un chiffre,
la virgule par un point.
Retourne :
la position de ce point dans la chaine (base 1).
0 si pas de point.
-1 si pas un chiffre (la chaine reste inchangée).
*/
{
int i = 1, j = 0, k = 0;
char ch[taille + 1];
char *pch = ch;
memcpy(ch, c, sizeof(char) * taille);
ch[taille] = '\0';
while(*pch != '\0')
{
if((*pch < '0') || (*pch > '9'))
switch(*pch)
{
case '.':
j = (++k == 2) ? -1 : j;
break;
case ',':
*pch-- = '.';
j = i--;
break;
default:
j = -1;
}
if(j == -1)
break;
*pch++;
i++;
}
if(j != -1)
memcpy(c, ch, sizeof(char) * taille);
return(j);
}
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private>
Mais Java est écrit en C, non ?
-- Richard
Harpo
Charlie Gordon wrote:
Il est important effectivement de nommer les variables correctement. i est un nom correct pour l'indice d'une boucle simple loopIndex est un nom débile pour cette variable.
Tout à fait d'accord, mais moins la boucle est simple plus ça se discute.
if ( blqh ) blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test avec des espaces, ou pire encore les point-virgule de fin d'instruction...
Ce ne sont pas des espaces, ce sont des tabs ! (je plaisante) Je parlais du non usage des accolades.
quel style horrible.
Les goûts et les couleurs... Personnellement, je trouve cela plus lisible.
if ( blqh ) { blurb ; }
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs
Qu'est-ce qu'il a mon accent ? je n'ai pas honte de mon terroir ! Nettoie plutôt ton écran ;-)
faites ce que je dis, je m'y mets bientôt ;-)
En fait, je viens juste (la semaine dernière) d'admettre que ce style que je n'aimais pas est meilleur que celui que j'utilise, sans nuire à la lisibilité il diminue le nombre de lignes donc augmente le nombre de lignes tenant sur une page d'éditeur et donc, en fin de compte augmente la lisibilité. Si je commets encore un programme en C, je prends ce style.
Leur convention pour le positionnement des accolades est horrible.
Là d'accord...
Charlie Gordon wrote:
Il est important effectivement de nommer les variables correctement.
i est un nom correct pour l'indice d'une boucle simple
loopIndex est un nom débile pour cette variable.
Tout à fait d'accord, mais moins la boucle est simple plus ça se
discute.
if ( blqh )
blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test
avec des espaces, ou pire encore les point-virgule de fin
d'instruction...
Ce ne sont pas des espaces, ce sont des tabs ! (je plaisante)
Je parlais du non usage des accolades.
quel style horrible.
Les goûts et les couleurs...
Personnellement, je trouve cela plus lisible.
if ( blqh ) {
blurb ;
}
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs
Qu'est-ce qu'il a mon accent ? je n'ai pas honte de mon terroir !
Nettoie plutôt ton écran ;-)
faites ce que je dis, je m'y mets bientôt ;-)
En fait, je viens juste (la semaine dernière) d'admettre que ce style
que je n'aimais pas est meilleur que celui que j'utilise, sans nuire à
la lisibilité il diminue le nombre de lignes donc augmente le nombre de
lignes tenant sur une page d'éditeur et donc, en fin de compte augmente
la lisibilité.
Si je commets encore un programme en C, je prends ce style.
Leur convention pour le positionnement des accolades est horrible.
Il est important effectivement de nommer les variables correctement. i est un nom correct pour l'indice d'une boucle simple loopIndex est un nom débile pour cette variable.
Tout à fait d'accord, mais moins la boucle est simple plus ça se discute.
if ( blqh ) blurb ;
Je n'ai pas vu Alain séparer les parenthèses des expressions de test avec des espaces, ou pire encore les point-virgule de fin d'instruction...
Ce ne sont pas des espaces, ce sont des tabs ! (je plaisante) Je parlais du non usage des accolades.
quel style horrible.
Les goûts et les couleurs... Personnellement, je trouve cela plus lisible.
if ( blqh ) { blurb ; }
ça éventuellement, sans les espaces inutiles, ni l'accent d'ailleurs
Qu'est-ce qu'il a mon accent ? je n'ai pas honte de mon terroir ! Nettoie plutôt ton écran ;-)
faites ce que je dis, je m'y mets bientôt ;-)
En fait, je viens juste (la semaine dernière) d'admettre que ce style que je n'aimais pas est meilleur que celui que j'utilise, sans nuire à la lisibilité il diminue le nombre de lignes donc augmente le nombre de lignes tenant sur une page d'éditeur et donc, en fin de compte augmente la lisibilité. Si je commets encore un programme en C, je prends ce style.
Leur convention pour le positionnement des accolades est horrible.
Là d'accord...
Harpo
Pierre Habouzit wrote:
résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Pour cela un gain de 5 à 10 % est anecdotique, quelqu'un qui utilise des outils de bureau voit peu de différence s'il obtient ses résultats en 0,55 s au lieu de 0,5 s lorsqu'il clique.
Mais la vraie vie ne se limite pas au bureau. Si on prend un programme qui fait des prévisions météorologiques, s'il met plus de 24 heures à prévoir le temps du lendemain, cela limite son intérêt. 10 % de gain n'améliorera pas suffisamment mais c'est quand même -aussi- bon à prendre.
Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!!
Java, ça me dit quelque chose... Ca existe encore ?
Pierre Habouzit wrote:
résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes
souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un
traitement de texte et autres applis avec des cycles de calculs courts
dans le temps) la différence est ultra minime.
Pour cela un gain de 5 à 10 % est anecdotique, quelqu'un qui utilise des
outils de bureau voit peu de différence s'il obtient ses résultats en
0,55 s au lieu de 0,5 s lorsqu'il clique.
Mais la vraie vie ne se limite pas au bureau.
Si on prend un programme qui fait des prévisions météorologiques, s'il
met plus de 24 heures à prévoir le temps du lendemain, cela limite son
intérêt. 10 % de gain n'améliorera pas suffisamment mais c'est quand
même -aussi- bon à prendre.
Et puis de toute facon, plus personne ne fait du C, ni même de C++
aujourd'hui. Quelle idée, maintenant il y a Java !!!
Java, ça me dit quelque chose... Ca existe encore ?
résultats sensiblement meilleurs (un gain de l'ordre de 5 à 10% si mes souvenirs sont bons).
Pour des applis que j'appelerais "de la vraie vie" (ie un tableur, un traitement de texte et autres applis avec des cycles de calculs courts dans le temps) la différence est ultra minime.
Pour cela un gain de 5 à 10 % est anecdotique, quelqu'un qui utilise des outils de bureau voit peu de différence s'il obtient ses résultats en 0,55 s au lieu de 0,5 s lorsqu'il clique.
Mais la vraie vie ne se limite pas au bureau. Si on prend un programme qui fait des prévisions météorologiques, s'il met plus de 24 heures à prévoir le temps du lendemain, cela limite son intérêt. 10 % de gain n'améliorera pas suffisamment mais c'est quand même -aussi- bon à prendre.
Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!!
Java, ça me dit quelque chose... Ca existe encore ?
Emmanuel Delahaye
Richard Delorme wrote on 26/09/05 :
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private>
Mais Java est écrit en C, non ?
Gni ? Tu veux dire la JVM ? Ben, faut demander à Sun (JRE). Ils publient leurs sources ?
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today; those that understand binary, and those that dont."
Richard Delorme wrote on 26/09/05 :
<private>
Et puis de toute facon, plus personne ne fait du C, ni même de C++
aujourd'hui. Quelle idée, maintenant il y a Java !!!
</private>
Mais Java est écrit en C, non ?
Gni ? Tu veux dire la JVM ? Ben, faut demander à Sun (JRE). Ils
publient leurs sources ?
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"There are 10 types of people in the world today;
those that understand binary, and those that dont."
<private> Et puis de toute facon, plus personne ne fait du C, ni même de C++ aujourd'hui. Quelle idée, maintenant il y a Java !!! </private>
Mais Java est écrit en C, non ?
C++ afaik
-- ·O· Pierre Habouzit ··O OOO http://www.madism.org
Targeur fou
Salut,
Targeur fou wrote on 23/09/05 :
char * tmp = malloc(lg+1);
Ca fout la trouille!
Quoi ça ? Le fait d'utiliser un malloc ?
Non, la suite qui en découle qui est hyper tordue...
Meu non ! Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration de la chaine si nécessaire.
Il n'y a pas besoin de créer une chaine locale pour remplacer un caractère dans une chaine modifiable.
OK. Mais quand tu as besoin de restaurer la chaine initiale si besoin au cas où celle-ci est tordue, on pense d'abord à effectuer sauvegarde/traitement/restitution, c'est moins sioux que la mise à jour de l'entier n de ton programme, qui est joli je suis d'accord, mais qui est sioux pour un débutant. En conception, je ne suis pas certain que ce soit la première solution qui vienne à l'esprit, même pour une "bête" en C. On est dans le cas où la bibliothèque standard du langage permet des opérations de copie et donc de réaliser des sauvegardes et on est bien en droit de l'utiliser. Il était tout à fait possible d'envisager la solution de ne pas faire de sauvegarde de données dans la fonction, facile pour un gas qui fait de l'embarqué, moins pour le débutant ou M. trucmuche qui fait du C en info. de gestion.
A+ Regis
Salut,
Targeur fou wrote on 23/09/05 :
char * tmp = malloc(lg+1);
Ca fout la trouille!
Quoi ça ? Le fait d'utiliser un malloc ?
Non, la suite qui en découle qui est hyper tordue...
Meu non !
Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration
de la chaine si nécessaire.
Il n'y a pas besoin de créer une chaine locale pour remplacer un
caractère dans une chaine modifiable.
OK. Mais quand tu as besoin de restaurer la chaine initiale si besoin
au cas où celle-ci est tordue, on pense d'abord à effectuer
sauvegarde/traitement/restitution, c'est moins sioux que la mise à
jour de l'entier n de ton programme, qui est joli je suis d'accord,
mais qui est sioux pour un débutant. En conception, je ne suis pas
certain que ce soit la première solution qui vienne à l'esprit, même
pour une "bête" en C. On est dans le cas où la bibliothèque standard
du langage permet des opérations de copie et donc de réaliser des
sauvegardes et on est bien en droit de l'utiliser. Il était tout à
fait possible d'envisager la solution de ne pas faire de sauvegarde de
données dans la fonction, facile pour un gas qui fait de l'embarqué,
moins pour le débutant ou M. trucmuche qui fait du C en info. de
gestion.
Non, la suite qui en découle qui est hyper tordue...
Meu non ! Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration de la chaine si nécessaire.
Il n'y a pas besoin de créer une chaine locale pour remplacer un caractère dans une chaine modifiable.
OK. Mais quand tu as besoin de restaurer la chaine initiale si besoin au cas où celle-ci est tordue, on pense d'abord à effectuer sauvegarde/traitement/restitution, c'est moins sioux que la mise à jour de l'entier n de ton programme, qui est joli je suis d'accord, mais qui est sioux pour un débutant. En conception, je ne suis pas certain que ce soit la première solution qui vienne à l'esprit, même pour une "bête" en C. On est dans le cas où la bibliothèque standard du langage permet des opérations de copie et donc de réaliser des sauvegardes et on est bien en droit de l'utiliser. Il était tout à fait possible d'envisager la solution de ne pas faire de sauvegarde de données dans la fonction, facile pour un gas qui fait de l'embarqué, moins pour le débutant ou M. trucmuche qui fait du C en info. de gestion.
A+ Regis
Charlie Gordon
"Emmanuel Delahaye" wrote in message news:
Harpo wrote on 26/09/05 :
Java, ça me dit quelque chose... Ca existe encore ?
N'a pas été engloutie par le Tsunami ?
A moins que ce soit Matra...
Chqrlie.
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> wrote in message
news:mn.d4887d591886c5c6.15512@YOURBRAnoos.fr...
Harpo wrote on 26/09/05 :
Java, ça me dit quelque chose... Ca existe encore ?
Java, ça me dit quelque chose... Ca existe encore ?
N'a pas été engloutie par le Tsunami ?
A moins que ce soit Matra...
Chqrlie.
Harpo
Targeur fou wrote:
Meu non ! Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration de la chaine si nécessaire.
Il est préférable, car moins dispendieux, d'éviter de modifier une donnée lorsqu'on ne doit pas le faire. L'OP semble bien l'avoir compris, pour une 10aine de char ce n'est pas grand chose, mais si on prend cette habitude, pour des 10aines de pages ça commence à compter. Il est stupide de faire et défaire alors qu'on peut ne rien faire pour le même prix en plus simple.
Targeur fou wrote:
Meu non !
Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration
de la chaine si nécessaire.
Il est préférable, car moins dispendieux, d'éviter de modifier une
donnée lorsqu'on ne doit pas le faire.
L'OP semble bien l'avoir compris, pour une 10aine de char ce n'est pas
grand chose, mais si on prend cette habitude, pour des 10aines de pages
ça commence à compter.
Il est stupide de faire et défaire alors qu'on peut ne rien faire pour
le même prix en plus simple.
Meu non ! Sauvegarde chaine modifiable, traitement a 2 balles, puis restauration de la chaine si nécessaire.
Il est préférable, car moins dispendieux, d'éviter de modifier une donnée lorsqu'on ne doit pas le faire. L'OP semble bien l'avoir compris, pour une 10aine de char ce n'est pas grand chose, mais si on prend cette habitude, pour des 10aines de pages ça commence à compter. Il est stupide de faire et défaire alors qu'on peut ne rien faire pour le même prix en plus simple.
