BSTRING : GESTION DE CHAINE POUR TOUS COMPILATEURS [GCC(DOS&UNIX), VC++,BORLAND.
xarier
Messages postés
688
Date d'inscription
jeudi 26 décembre 2002
Statut
Membre
Dernière intervention
19 mai 2005
-
15 juil. 2004 à 18:05
magic_Nono Messages postés 1878 Date d'inscription jeudi 16 octobre 2003 Statut Membre Dernière intervention 16 mars 2011 - 5 avril 2005 à 09:08
magic_Nono Messages postés 1878 Date d'inscription jeudi 16 octobre 2003 Statut Membre Dernière intervention 16 mars 2011 - 5 avril 2005 à 09:08
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/19668-bstring-gestion-de-chaine-pour-tous-compilateurs-gcc-dos-unix-vc-borland
https://codes-sources.commentcamarche.net/source/19668-bstring-gestion-de-chaine-pour-tous-compilateurs-gcc-dos-unix-vc-borland
5 avril 2005 à 09:08
sinon, et bien la source a continué a se développer grace à une utilisation intensive et la contribution d'autres développeurs que je remercie au passage
et merci à Tanu pr avoir validé le fonctionnement sous unix.
tout ça nous amène à une nouvelle version postée ce jour
Magicalement
Nono.
6 déc. 2004 à 12:46
#include "bidule.h" //cherche un en-tête utilisateur
La distinction est importante, elle détermine où le compilateur va d'abord chercher l'en-tête
et la librairie, et donc laquelle primera s'il y a un conflit de nom.
6 sept. 2004 à 19:27
les CString prenaient en charge la comparaison avec un caractere =>
résolu en rajoutant ceci ds le header
____
#ifdef B_Visual
//deb: rajouté pr régler PB avec les MFC
bool operator==(const char s)const{return operator==((BString) s);}
bool operator!=(const char s)const{return operator!=((BString) s);}
bool operator<=(const char s)const{return operator<=((BString) s);}
bool operator<(const char s)const{return operator<((BString) s);}
bool operator>=(const char s)const{return operator>=((BString) s);}
bool operator>(const char s)const{return operator>((BString) s);}
//fin:rajouté pr régler PB avec les MFC
#endif// B_Visual
6 sept. 2004 à 15:04
le level warning 4... en précisant de considérer les warning en tant qu'erreurs
sinon, quelles rq à faire sur la lib actu??
et si j'ai pas utiliser des new/delete, c'est a cause de l'absence d'opération type réalloc (toujours tout recopier est une perte de tsp)
+++
Nono.
25 août 2004 à 15:40
permet ss visual d'afficher des msg durant la compile: comme les warning etc
les /* st signalés pr qd ils st déja ds des com
par exemple, il aprécie moyennement /*/, alors que....
C pratique
//* 1/ ou 2
mon truc stable
/*/
celui testé
// */
pr le modal, je V voir => quelle fic, quelle ligne???
sinon, no newline at end of file => po grav
j'aV deja remarqué que gcc les signale en les ignorant
25 août 2004 à 13:16
25 août 2004 à 13:11
//* 2 / pour visual 1 sinon
Pour les Warnings, je compile toujours avec le flag -Wall, c'est surement pour ca que j'en ai plus que toi. Pour resumer les Warnings que j'ai:
> Ignoring #pragma message
Il doit pas connaitre, c'est peut-etre un pragma specifique a MS? Je ne me suis jamais vraiment plongé dans les pragma, donc je ne sais pas.
> /* within comment
> statement with no effect
(modal)
> no newline at end of file
Voila, je crois que c'est tout... Est-ce qu'il existe un equivalent a -Wall avec VC++? Ca fait tellement longtemps que je ne l'ai pas utilisé...
J'essaierai de recompiler avec ta modif mais je suis pas sur que ca marche.. Hmm... Je verrai ca.
A bientot
++
Soilwork
25 août 2004 à 11:55
25 août 2004 à 11:54
et je suis tjs en level 4 de VC6...
pour les stdafx, il y a un truc specifique:
je les encadre en général ainsi :
//* 2 / pour visual 1 sinon
#include "stdafx.h"
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif /* _DEBUG */
lol je l'ai po fait pr BString, voilà, C corrigé
dc, vu que tu n'utilise po le stdafx, met alors 1 / pour commencer...
ui, perso, j'ai tjs utilisé soit VC soit Borland (& po JBorland effectivt)
je ne verifiais po avec djgpp (gcc) mais, ça passait...
pour le ULARGE_INTEGER
qui fait parti des nouveautés,
je l'encadre avec un define de B_Visual
AnsiString , qui appartient a Borland C++...
pour les 10 fichiers :
Table_d_exceptions.txt est en fait un commentaire...
ne sert qu'au développeur (et n'est certainement po tt à fait à jour...)
dc ça fait 9 fichiers
les macros de gestion mem sont ensemble
global est le seul que j'inclu ds mon prj qd je n'ai besoin que de mes bibli basiques
la gestion des exception et des fenetres a plutot intéret a etre separée du reste
et si je n'ai po utilisé les exception standard, j'ai utilisé une classe en héritant afin de les gérer comme on me l'a appris dans mes études
et pi, ben, C tt, on a fait le tour.
Magicalement.
Bonne continuation....
25 août 2004 à 11:41
Bon je vais pas te mettre mon log de compilation, ca serait un peu long, avec tous les warnings. On va juste regarder les erreurs :
> BException.cpp:18:20: stdafx.h: No such file or directory
Bon, ca c'est pas nouveau, et c'est précisément l'erreur que je ne peux pas corriger.
> Globals.hpp:123:17: vcl.h: No such file or directory
Ca c'est un peu plus vicieux... C'est a cause de ce passage dans le fichier Globals.hpp:
#ifdef _MSC_VER // compilateur Microsoft (Visual)
#define B_Visual
#else /* _MSC_VER// compilateur Microsoft(Visual) */
#ifdef _WIN32 // sous Windows
#define B_JBuilder
(...)
#endif
En gros, ca veut dire que si on est sous Windows, soit on utilise Visual, soit on utilise Builder (C++ Builder, soit dit en passant, pas JBuilder qui est l'IDE de Borland pour Java et non C++, mais c'est juste un detail!).
Enfin, en tout cas, j'utilise G++ sous Windows (avec le Minimalist GNU for Windows, aka MinGW, ou bien en utilisant Cygwin), donc je n'ai pas la VCL de Borland, bien sur, d'où l'erreur.
Mais je peux la corriger en commentant cette ligne qui m'est inutile.
>BString.hpp:82: error: syntax error before `)' token
[ BString(const ULARGE_INTEGER in); ]
Il ne connait pas ULARGE_INTEGER, je suppose que ca doit etre défini dans le fichier StdAfx...
>BString.hpp:100: error: syntax error before `&' token
[ BString(const AnsiString& in); ]
Il ne connait pas AnsiString, rien de plus normal. Résoudre la deuxieme erreur resout aussi celle-ci.
Voila pour les erreurs de compilation. Ta classe n'est pas aussi portable que tu l'affirmes, mais tu peux encore arranger tout ca!
Mais bon, le meilleur moyen pour que quelque chose soit portable, c'est de faire comme moi : n'utiliser que du C++ standard, norme ANSI et tout ca ;) Je pense que ma classe CString peut se compiler avec a peu pres n'importe quel compilateur (G++, CC, borland, visual). Enfin, je n'ai jamais essayé, mais normalement il ne doit pas y avoir de problème, je crois.
Cela dit, je maintiens que 10 fichiers pour une malheureuse chaine de caractères, c'est un peu (beaucoup) trop!! Et dire que tu me reproches d'avoir quelques fonctions "en double" ;)
Bonne continuation!
++
Soilwork
25 août 2004 à 09:39
je l'ai laissé en suspent...
et comme ça fait un plus de 6 mois que je n'utilise que zindoz...
Bon, j'espere que tu sera satisfait par toutes les recentes (moyennement récentes en fait) modif...
+++
25 août 2004 à 09:35
Sinon, je te rappelle quand meme une petite chose : le titre que tu as toi-meme donné à cette page :
BSTRING : GESTION DE CHAINE POUR TOUS COMPILATEURS [GCC(DOS&UNIX), VC++,BORLAND...]
No comment, comme tu dis... ;)
PS : et Globals.hpp alors? ;)
25 août 2004 à 09:30
Par contre je vais peut-être retirer ce que j'ai dit au sujet de la bonne idee du MinMajDifferentes.. A en voir le code de l'operateur == :
// !! je ne regarde pas la casse sous windows
//(...)
#ifndef B_UNIX
if(!minMajDifferentes)
result=stricmp( c_chaine, s); //_stricmp
else
#endif /* !B_UNIX */
result=strcmp( c_chaine, s);
D'abord, je ne vois pas l'interet de mettre en place un mecanisme de gestion de la casse si tu ne l'utilises pas toujours. D'ailleurs, pourquoi est-ce que Windows ne pourrait pas prendre en compte la différence entre majuscules et minuscules? Certes, l'OS ne fait pas la distinction quand il s'agit de noms de fichiers, mais dans d'autres circonstances c'est différent. Pour gérer des mots de passe, ca peut servir par exemple (cryptés ou non). Enfin bref... De toute facon je ne comprends pas vraiment ton code:
Que signifie la constante B_UNIX, lorsqu'elle est définie? Qu'on travaille sous Unix? Ca serait logique, mais si c'est ca... le test (#ifndef B_UNIX) regarde si B_Unix n'est pas definie, ce qui veut dire qu'on travaille sous Windows (bon, ok, y a pas que Windows et Unix dans la vie, lol. Ca veut donc dire qu'on ne travaille pas sous Unix). Donc le code qui vérifie minMajDifferentes s'exécute sous Windows, mais pas sous Unix!
Enfin, j'ai peut-etre mal regardé, je suis un peu naze ce matin, mais bon, je crois pas... A moins que B_UNIX ait un autre sens, bien sur.
En tout cas, bonne journée et bonne continuation!
++
Soilwork
25 août 2004 à 09:27
pour le stdafx... c'est du standard VisualC++
pour accélérer la compilation...
y a tt plein de post la dessus si tu veux te renseigner.
En gros, VC refuse de compiler si on utilise les mfc si ça y est po
sinon, ben svt je fais appel à winFormat pour les affichages dans des fenetres mfc dc avec des variables CString...
pour les noms, et bien get ,is et set sont des préfixe std
et celle que tu cite a effectivt ete corrigée.
Merci pour cette attention & à très bientot
Bruno.
25 août 2004 à 09:11
Par exemple, le booléen qui indique si on doit prendre en compte la casse ou non. J'avais eu cette idée aussi pour ma classe CString mais en fait ca ne convenait pas vraiment à ce que je voulais faire donc j'ai laissé tomber cet aspect.
Interessante aussi l'idee du constructeur a partir d'un AnsiString de Borland ou d'un CString de MS, meme si ca me semble bizarre d'utiliser plusieurs classes de chaine dans un meme programme. Je suppose que c'est utile si on souhaite utiliser des fonctions qui retournent des AnsiString/CString, pour les convertir en BString.
Par contre, au niveau de la presentation du code... Pas la moindre ligne de commentaire pour indiquer ce que font les fonctions dans le header.. S'il faut s'amuser a chercher dans le CPP pour savoir ce que fait une fonction exactement, c'est pas gagné! D'autant plus que les noms ne sont pas spécialement significatifs... (ex : convertTxtMisEnForme, ou encore winFormat?). Et puis il y a une typo dans un nom de methode, ca fait assez mal! [setMinMajDifferntes] Enfin, je suppose (j'espere) que tu l'as corrigée depuis..!
Passons aux choses un peu plus sérieuses.. à vrai dire, au premier coup d'oeil, je me suis dit que ca commencait plutot mal :
Dans le header : #include "globals.hpp"
Dans le cpp: #include "stdafx.h"
Hmm, outre le fait que je n'aime pas trop le nom de fichier "stdafx.h" (mais bon, tu appelles tes fichiers comme tu veux), j'ai une question : Ou est-ce que tu as caché ces deux fichiers? S'ils sont necessaires a ta classe, il est logique de les inclure dans le zip, non? Ou au moins d'indiquer où les trouver!
Je présume que c'est dans un de ces fichiers que tu définis par exemple les macros FREE et ALLOUEn, j'en arrive donc a ma 2eme remarque : Il me semble vraiment bizarre qu'une classe aussi simple et "bas niveau" que celle qui gere des chaines de caractères nécessite d'autres inclusions (non standard, i.e. autre chose que des fichiers du genre string.h, ctype.h, etc...)!
++
Soilwork
15 juil. 2004 à 18:05
voila je te pose 10/10;)