cs_Kaid
Messages postés949Date d'inscriptionmardi 2 octobre 2001StatutMembreDernière intervention 8 juillet 2006
-
8 juil. 2006 à 20:51
aminesoft1
Messages postés9Date d'inscriptionmardi 11 mars 2008StatutMembreDernière intervention16 juin 2008
-
4 juin 2008 à 07:31
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
aminesoft1
Messages postés9Date d'inscriptionmardi 11 mars 2008StatutMembreDernière intervention16 juin 2008 4 juin 2008 à 07:31
good job
cs_samana
Messages postés8Date d'inscriptionvendredi 7 mai 2004StatutMembreDernière intervention12 septembre 2006 1 août 2006 à 21:47
Concrètement, sans rentrer ds les détails techniques du code (manip de chaîne de caractères, portabilité windows<->unix ...) c'est une sorte de parseur (comme pour les fichiers XML avec stylsheet XSL en gros).
Joli travail. Je le mets de côté au cas où...ça peut être utile.
cs_vicenzo
Messages postés178Date d'inscriptionmardi 16 août 2005StatutMembreDernière intervention25 août 20101 14 juil. 2006 à 09:29
Effectivement free() s'en moque... Mais le sprintf NON !! et va foutre le bordel à l'addresse pointée par ficout.... Et le free générer eventuellement une erreur car sprintf aura ecrit plus d'octets que prévu ou insérer des valeurs tordues et donc le free() sous certaines implémentations (dont VC) aura parfois du mal à libérer la mémoire car celle ci n'est plus valide...
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 juil. 2006 à 00:24
free() se moque de savoir ce qu'il y a à l'adresse spécifiée, le désallocateur system libère le bloc partant de l'adresse donnée à free et basta, aucun besoin que soit une chaine avec zero final ou autre.
cs_vicenzo
Messages postés178Date d'inscriptionmardi 16 août 2005StatutMembreDernière intervention25 août 20101 13 juil. 2006 à 22:18
Quelques petites remarques ... :
* BOOL n'est pas un type de donnée ni une classe d'allocation mais juste une macro... Est il donc nécessaire de l'inclure dans le tableau MotType ?
* Fonction main : l'appel direct à argv[1] sans avoir tester le argc est franco ! En effet, 99% des implémentations usuelles placeront, si aucun paramètre n'est fourni, un pointeur null dans argv[1]. Mais ce comportement n'est pas prévu et défini par la norme et sous un quelconque compilo C venu de mars, cela peut planter l'appli...
* dans la fonction BaliserFichier() :
..
ficout= (char*) malloc(strlen(fichier)+4);
sprintf(ficout, "%s.htm", fichier);
..
AIE ! lors du free(ficout), sous VC++ crash en debug ! Pourquoi ? car le buffer ficout ne contient pas de zéro terminal. Il faut faire :
malloc(strlen(fichier)+4 + 1)......
* dans la fonction Envoi() :
..
memset(mot,0,200); -> vaut mieux : memset(mot,0,sizeof(mot));
..
* pareil pour les taille de MotsCles (17) et MotsTypes (19) : ces valeurs sont utilisées à plusieurs endroits... Un define ou un static const serait moins source d'erreurs lors d'enrichissement ultérieurs de la source.
Ce sont des petits détails ... mais bon ca peut toujours servir !
Sinon j'aurai bien vu un tableau de structure avec comme champs le caractère, le code couleur, le code fonction à appeller afin de minimiser la liste des else if de la boucle principale....
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 20123 13 juil. 2006 à 15:01
Super. En ce sens et sur ce point, GCC est plus tolérant, et VC++ plus conforme.
On n'a oublié aucun compilateur ni aucune plateforme? Test:
// Retourne 1 si le mot est pourpre, 2 s'il est bleu, 0 si mot normal (noir)
unsigned short EstUnMotCle(char* str)
{
unsigned short m;
for (m=0; m<17; m++) if (strcmp(MotsCles[m] ,str)==0) return 1;
for (m=0; m<19; m++) if (strcmp(MotsTypes[m],str)==0) return 2;
return 0;
}
cs_vicenzo
Messages postés178Date d'inscriptionmardi 16 août 2005StatutMembreDernière intervention25 août 20101 13 juil. 2006 à 10:30
Le code compile sous VC++ en apportant une légère modification du source... On peut critiquer VC++ a bien des niveaux (surtout au niveau du support C++ , de l'implémentation des librairies standard, etc...) mais son compilateur C est tout de même pas mal fichu...
Le code de la source plante sous VC car il n'est pas "ANSI C". En effet, dans la fonction BaliserFichier() un tableau de char est déclaré en fin de bloc (char ficout[strlen(fichier)+4];)... Ce qui est strictement illégal en ANSI C où toutes les déclarations doivent être effectuée avant toute expression exécutable... En remontant la déclaration du tableau en début de bloc, tout compile et fonctionne correctement. Mais dans ce cas, on appelle strlen() avant même d'avoir tester le pointer "fichier"... Donc revoir un peu le code de début de fonction....
J'espère que cela peut aider...
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 20123 10 juil. 2006 à 21:12
memset() est défini dans string.h, pas besoin de macro c'est une fonction ANSI.
Chers Code::Blockers si vous essayez la mise à jour faudra virer GetTimeOfDay(), en attendant la prochaine MAJ, qui sera portable.
CADRATURE
Messages postés25Date d'inscriptionmercredi 26 novembre 2003StatutMembreDernière intervention13 juin 2009 10 juil. 2006 à 12:02
Avec CodeBlocks 1.0 (et mingw32-gcc.exe 3.4.4) , ça marche.
En ajoutant ceci: ....
/*
Pour faciliter le portage d'application UNIX ou pour faciliter le
travail de développeurs habitués au monde UNIX, les macros suivantes
permettront une 'migration' aisée :
#include <memory.h> // Prototypes des fonctions memcpy et memset
katsankat
Messages postés571Date d'inscriptionvendredi 30 décembre 2005StatutMembreDernière intervention12 juillet 20123 10 juil. 2006 à 11:37
Salut :)
Allons-y pour memset(), bien vu. Pour win32, je me penche sur la question dès que la version linux est solide. Essaye de débuguer en modifiant la routine cout().
Bonne remarque sur la colorisation des chiffres, en cours d' implémentation!
Merci Kaid, ça marche super (ici il traite 8600 octets en 4 ms, soit 2150 octets par milliseconde).
J'ai corrigé quelques erreurs, mise à jour bientôt, hisoire de mériter la note!
psyphi
Messages postés51Date d'inscriptionlundi 16 août 2004StatutMembreDernière intervention12 août 2010 10 juil. 2006 à 11:24
Source intéressante, qui peut se révélée bien utile.
Remarque sur le code: remplace tout tes bzero par memset(&mot,0, 255*sizeof(char)).
Regarde dans la man page de bzero, dans le paragraphe conformité, il conseil d'utilisé memset.
Pour ce qui est de l'utilisation, ca se compile bien avec codeblocks sous windows, mais quand j'utilise le programme il me génère un fichier .html de 0 ko :/ .
cs_neria
Messages postés319Date d'inscriptionvendredi 21 février 2003StatutMembreDernière intervention16 février 2009 9 juil. 2006 à 11:53
C'est un code très interessant. Par conte ce serait sympa que ton prog charge un fichier de config personalisable qui contient les couleurs des mots clés, chaînes, nombres ...
cs_Kaid
Messages postés949Date d'inscriptionmardi 2 octobre 2001StatutMembreDernière intervention 8 juillet 20061 8 juil. 2006 à 20:51
Si ton objectif est de trouver un équivalent à GetTickCount() pour connaitre le temps d'exécution de ton programme, tu peux utiliser la fonction gettimeofday() qui retourne la date du système en secondes et micro-secondes.
4 juin 2008 à 07:31
1 août 2006 à 21:47
Joli travail. Je le mets de côté au cas où...ça peut être utile.
14 juil. 2006 à 09:29
14 juil. 2006 à 00:24
13 juil. 2006 à 22:18
* BOOL n'est pas un type de donnée ni une classe d'allocation mais juste une macro... Est il donc nécessaire de l'inclure dans le tableau MotType ?
* Fonction main : l'appel direct à argv[1] sans avoir tester le argc est franco ! En effet, 99% des implémentations usuelles placeront, si aucun paramètre n'est fourni, un pointeur null dans argv[1]. Mais ce comportement n'est pas prévu et défini par la norme et sous un quelconque compilo C venu de mars, cela peut planter l'appli...
* dans la fonction BaliserFichier() :
..
ficout= (char*) malloc(strlen(fichier)+4);
sprintf(ficout, "%s.htm", fichier);
..
AIE ! lors du free(ficout), sous VC++ crash en debug ! Pourquoi ? car le buffer ficout ne contient pas de zéro terminal. Il faut faire :
malloc(strlen(fichier)+4 + 1)......
* dans la fonction Envoi() :
..
memset(mot,0,200); -> vaut mieux : memset(mot,0,sizeof(mot));
..
* pareil pour les taille de MotsCles (17) et MotsTypes (19) : ces valeurs sont utilisées à plusieurs endroits... Un define ou un static const serait moins source d'erreurs lors d'enrichissement ultérieurs de la source.
Ce sont des petits détails ... mais bon ca peut toujours servir !
Sinon j'aurai bien vu un tableau de structure avec comme champs le caractère, le code couleur, le code fonction à appeller afin de minimiser la liste des else if de la boucle principale....
13 juil. 2006 à 15:01
On n'a oublié aucun compilateur ni aucune plateforme? Test:
// Retourne 1 si le mot est pourpre, 2 s'il est bleu, 0 si mot normal (noir)
unsigned short EstUnMotCle(char* str)
{
unsigned short m;
for (m=0; m<17; m++) if (strcmp(MotsCles[m] ,str)==0) return 1;
for (m=0; m<19; m++) if (strcmp(MotsTypes[m],str)==0) return 2;
return 0;
}
13 juil. 2006 à 10:30
Le code de la source plante sous VC car il n'est pas "ANSI C". En effet, dans la fonction BaliserFichier() un tableau de char est déclaré en fin de bloc (char ficout[strlen(fichier)+4];)... Ce qui est strictement illégal en ANSI C où toutes les déclarations doivent être effectuée avant toute expression exécutable... En remontant la déclaration du tableau en début de bloc, tout compile et fonctionne correctement. Mais dans ce cas, on appelle strlen() avant même d'avoir tester le pointer "fichier"... Donc revoir un peu le code de début de fonction....
J'espère que cela peut aider...
10 juil. 2006 à 21:12
Chers Code::Blockers si vous essayez la mise à jour faudra virer GetTimeOfDay(), en attendant la prochaine MAJ, qui sera portable.
10 juil. 2006 à 12:02
En ajoutant ceci: ....
/*
Pour faciliter le portage d'application UNIX ou pour faciliter le
travail de développeurs habitués au monde UNIX, les macros suivantes
permettront une 'migration' aisée :
#include <memory.h> // Prototypes des fonctions memcpy et memset
#define bcopy(source, dest, len) memcpy(dest, source, len)
#define bzero(area, len) memset(area, 0, len)
VOIR
http://support.microsoft.com/default.aspx?scid=kb%3Bfr%3B458620
*/
10 juil. 2006 à 11:37
Allons-y pour memset(), bien vu. Pour win32, je me penche sur la question dès que la version linux est solide. Essaye de débuguer en modifiant la routine cout().
Bonne remarque sur la colorisation des chiffres, en cours d' implémentation!
Merci Kaid, ça marche super (ici il traite 8600 octets en 4 ms, soit 2150 octets par milliseconde).
J'ai corrigé quelques erreurs, mise à jour bientôt, hisoire de mériter la note!
10 juil. 2006 à 11:24
Remarque sur le code: remplace tout tes bzero par memset(&mot,0, 255*sizeof(char)).
Regarde dans la man page de bzero, dans le paragraphe conformité, il conseil d'utilisé memset.
Pour ce qui est de l'utilisation, ca se compile bien avec codeblocks sous windows, mais quand j'utilise le programme il me génère un fichier .html de 0 ko :/ .
9 juil. 2006 à 11:53
8 juil. 2006 à 20:51