CLASSE CSTRING
magic_Nono
Messages postés
1878
Date d'inscription
jeudi 16 octobre 2003
Statut
Membre
Dernière intervention
16 mars 2011
-
2 sept. 2004 à 15:01
Soilwork9 Messages postés 16 Date d'inscription lundi 9 août 2004 Statut Membre Dernière intervention 13 septembre 2004 - 13 sept. 2004 à 08:28
Soilwork9 Messages postés 16 Date d'inscription lundi 9 août 2004 Statut Membre Dernière intervention 13 septembre 2004 - 13 sept. 2004 à 08:28
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/25876-classe-cstring
https://codes-sources.commentcamarche.net/source/25876-classe-cstring
13 sept. 2004 à 08:28
7 sept. 2004 à 23:16
parce que ca n'est pas standard ! iostream.h ca date de l'epoque du c++ pre standard (avant 97), c'est deprecié et ca va disparaitre au prochain standard
maintenant tout est dans le namespace standard, meme lib standard c
7 sept. 2004 à 22:44
Juste un petit mot au sujet des librairies "C" qui sont deprecated.. J'ai juste a remplacer iostream.h par iostream, et les librairies C classiques par leurs equivalents C++ comme je l'avais dit.. Ca change franchement pas grand chose, d'ailleurs c'est deprecated parce qu'ils ont envie que ca soit deprecated... D'ailleurs, est-ce que iostream existe en C? Je dirais que non, alors pourquoi avoir créé iostream.h, pour ensuite dire que c'est deprecated? :)
Bon en tout cas quand j'aurai le temps, je mettrai mes libs à jour pour prendre en compte tes remarques, djl, ca ne me coute absolument rien de toute facon! Sauf cinq minutes de mon temps pour changer quelques include ;)
++
Soilwork
PS : J'avais pas regardé qui était l'auteur du document. Si c'est le createur du C++, alors ok, il a le droit de faire le boss lol! Je retire ce que j'ai dit sur l'aspect pédant du texte :)
7 sept. 2004 à 15:39
un bug amené par les modfis récentes : const:
les CString prenaient en charge la comparaison avec un caractere =>
résolu en rajoutant ceci ds le header
//deb: rajouté pr régler PB avec les MFC
du coup, pr résoudre ce pb, G inclu ds Visual uniquement les lignes suivantes ds le header.
bool operator==(const char s)const{return operator==((BString) s);}
par ex pr cet opérateur: le suivant était choisi
(syntaxe ptet approximative)
friend bool operator(const char& ,const CString&)const
vu que rien ne laissait présagé de cette erreur... ben détecté il y a une semaine seulement...
y avait une différence ! la comparaison de la casse !
voilu
++
Nono.
7 sept. 2004 à 15:30
> tout ce qui est inliner devrais pas poser de probleme
je repete, ce n'est pas un conseil que je donne, je dis juste que tes fonction inline doivent etre definie dans un header (si tu veut qu'elles soit sytematiquement inliner)
c'etait quoi le bug avec les bstring ?
7 sept. 2004 à 15:06
la compile tjs sans pb,
mé pb au linkage...
tjs le mm
sérieu, relis mieu mon exemple
ça me semble logique que Truc soit défini ds B.obj &C.obj
sinon, on fait à l'ancienne & on met ts nos srce ds un unique
et vu que ce sera un cpp, po de pb
& si là tu conseille ça,
ben je comprend plus rien du tout à la prog
ou soit ts mes bouquins étaient nuls de mm que ts mes profs & moi mm
tu vas me faire désespérer...
++
PS' : au fait, tu as vu, G corrigé un bug des BString ammené par une modif récente qu'on a fait ensemble!!!
un conflit entre CString & BString... causé par les const...
m'enfin, réglé!
7 sept. 2004 à 14:53
"et y me semblais bien que definir le tt en fichiers séparés était une des bases de la prog structurée...
"
faudrais savoir ce que tu veux aussi, si tu veux que tes fonctions soit inliner, elles ne peuvent etre compiler separement (puisque leur definition doit etre connue lors de la compilation du source)
moi je fais toujours declaration dans le .h et definition dans le .c (sauf pou les fonctions inline) pour ne pas avoir a tous recompiler a chaque fois, comme le fais make
tu peux pas toujours y echapper en c++, la preuve avec les templates et les fonctions inline
7 sept. 2004 à 14:37
et ce mm si le répertoire contenant les obj sont détruits
si tu relis mon post plus haut, ça me semble logique
et y me semblais bien que definir le tt en fichiers séparés était une des bases de la prog structurée...
++
PS: là G po déplacé la mm classe que + haut, mé le pb est exactement le mm
en gros, y a que les headers inclus une unique fois qui ne me posent aucun pb
7 sept. 2004 à 14:32
les "already defined " n'ont pas lieu d'etre
ca te fais ca a chaque fois que tu recompile tout ?
7 sept. 2004 à 14:25
G viré les .obj
recompilé:
et tjs des erreurs
211 error(s)
dll.obj : error LNK2005: "public: static class BString __cdecl BIBLI_BC::BLang::ELanguesToString(enum BIBLI_BC::ELangues *)" (?ELanguesToString@BLang@BIBLI_BC@@SA?AVBString@@PAW4ELangues@2@@Z) already defined in dgestionliste.obj
dll.obj : error LNK2005: "public: static class BString __cdecl BIBLI_BC::BLang::getTxtLangue(char const *,bool)" (?getTxtLangue@BLang@BIBLI_BC@@SA?AVBString@@PBD_N@Z) already defined in dgestionliste.obj
dll.obj : error LNK2005: "public: static void __cdecl BIBLI_BC::BLang::initTitre(class CDialog *,char const *)" (?initTitre@BLang@BIBLI_BC@@SAXPAVCDialog@@PBD@Z) already defined in dgestionliste.obj
dll.obj : error LNK2005: "enum BIBLI_BC::ELangues BIBLI_BC::iLangageTrtt" (?iLangageTrtt@BIBLI_BC@@3W4ELangues@1@A) already defined in dgestionliste.obj
dll.obj : error LNK2005: "enum BIBLI_BC::ELangues BIBLI_BC::iLangageLogiciel" (?iLangageLogiciel@BIBLI_BC@@3W4ELangues@1@A) already defined in dgestionliste.obj
dll.obj : error LNK2005: "class BHashTable BIBLI_BC::donneesLinguistiquesSoft" (?donneesLinguistiquesSoft@BIBLI_BC@@3VBHashTable@@A) already defined in dgestionliste.obj
dll.obj : error LNK2005: "class BHashTable BIBLI_BC::donneesLinguistiquesTrtt" (?donneesLinguistiquesTrtt@BIBLI_BC@@3VBHashTable@@A) already defined in dgestionliste.obj
pour un ptt apperçu
++
7 sept. 2004 à 13:26
mdr, une recompile suffit...
y me semblait pourtant avoir forcé la recompil...
bon... (& y aV une trentaine de lignes similaires...)
gogo tester...
merci à toi!
7 sept. 2004 à 13:22
pour eviter les includes multiples
#ifndef __HCString__
#define __HCString__
...
ca suffit
"HashTable.obj : error LNK2005: "class BString __cdecl BIBLI_BC::ELangageDeProgToString(enum ELangageDeProg const &)" (?ELangageDeProgToString@BIBLI_BC@@YA?AVBString@@ABW4ELangageDeProg@@@Z) already defined in AnaTrace.obj"
ben c'est un peu logique, ta mis le code dans le header et ta encore les modules objets qui trainnent :D, tu vois le conflit ?
7 sept. 2004 à 13:12
comment résouds tu les inclusions multiples
mettons que j'ai une classe A, ayant 2 membres b et c de classe B et C
soit la classe truc, declarée entierement ds le header
dans ma classe B & ds ma classe C, j'ai des instances de Truc
donc les headers B et C contiennent un include sur Truc mais pas A
là, le compilo va raller car il va trouver deux sortes de Truc, ceux de B & ceux de C
et ces deux Trucs ont été précompilés dans les b.o et c.o
j'espere que vs suivez tjs
sinon, je vais illustrer cet exemple:
Bref, voici l'erreur générée par VC6 & pkoi j'ai abandonné cette idée de tt mettre ds les headers
error LNK2005
detail d'un essai avec MP:
acceleration : nouvelle politique : toutes les bibli sont des headers => inline automatisés.... [ABANDONNE]
=> ne plus inclure les bibli ds les prj...
ABANDONNE car :
> si certains srce ne st pas ds des cpp > compilés plsrs fois
ex=> HashTable.obj : error LNK2005: "class BString __cdecl BIBLI_BC::ELangageDeProgToString(enum ELangageDeProg const &)" (?ELangageDeProgToString@BIBLI_BC@@YA?AVBString@@ABW4ELangageDeProg@@@Z) already defined in AnaTrace.obj
=> Debug/MetaProg.exe : fatal error LNK1169: one or more multiply defined symbols found
7 sept. 2004 à 12:36
"et ajouter la commande inline devant celles qui en ont "besoin" "
mais ca devra toujours etre dans le .h (mais hors de la declaration de la classe)
7 sept. 2004 à 12:27
oui j'utilise VC6, c'est vrai qu'on m'a déjà fait la remarque par rapport aux variable déclarées localement dans les boucles, j'ai donc corrigé cela et je ferai en sorte de ne plus faire ce genre "d'erreur"
concernant le fait que le source ne fait qu'un .h je me pose la question suivante par rapport à ce qu'on m'a dis : les fonctions déclarées dans la classe (comme c'est le cas ici) sont considérées comme "inline" et c'est pour cela qu'à l'origine j'ai tout mis dans un seul fichier, je ne le fait pas tout le temps si ca peux vous rassurer mais je vais surement voir pour changer cela et déclarer les fonctions dans un .cpp et ajouter la commande inline devant celles qui en ont "besoin"
quand aux librairies std, va faloir que je m'y mette
encore merci
7 sept. 2004 à 11:16
si C BS...c'est sur...
n'empeche que ce document est succin.
mais parfaitement ok avec toi, C ds cette voi qu'il faut aller
++
7 sept. 2004 à 11:12
le documenté que j'ai cité, qui est de bjarne stroustrup (le pere du c++, d'ou son assurance que tu as remarqué dans son propre langage :D) a pour but de montrer, en comparant un c-style code avec un pur c++ (comme tu l'a remarqué) que utilisé la bibliotheques standard (ce que tu n'aime pas) te permet d'avoir un code claire, rapide a produire, facile a maintenir ... et performant
ton c++ est deprecated, et aujourd'hui ca ne vaut rien (reconnu nul part ), seul le c++ standard a raison d'etre
rien qu'avec la stl, tu imagine tout ce qu'on peut faire, a quelle point ca facilite la vie du programmeur ?
7 sept. 2004 à 09:14
vraiement bof sur ce doc...
mis a part l'usage des stl, rien d'intéressant à mon gout
+++
7 sept. 2004 à 09:08
sinon c'est vrai que VC6 se fait, vieu, mais bon c'est lui le plus usité... dc faut faire avec
et un intéret de malloc par rapport au new : la présence du realloc!
allé, je file survoler ce pdf...
++
Nono.
7 sept. 2004 à 08:32
Le document que tu cites a plutot l'air de comparer le C et le C++... Les programmes qu'il donne en "C-style C++" sont du C, tout simplement (Pourquoi utiliser malloc dans un programme C++?). En plus je trouve l'auteur un peu arrogant et pédant, mais bon c'est une autre histoire.
Ce que je voulais dire dans mon précédent post, c'est que j'utilise les headers "C-style"(stdlib.h, string.h, et meme iostream.h) plutot que les nouveaux headers C++(iosteram, cstdlib, cstring?). Bon, un jour, je changerai peut-etre ca, comme ca je n'aurai plus besoin de faire taire mon compilateur avec le flag -Wno-deprecated lol
Après c'est vrai que je n'utilise pas les classes standard comme "string", mais c'est simplement parce qu'elles ne me conviennent pas. Pendant un moment, j'ai développé sous C++ Builder et j'utilisais les AnsiString, mais jamais les string. Je préfère faire ma propre classe, qui sera peut-être un peu moins efficace, mais qui conviendra à l'utilisation que je veux en faire.
Matane!
++
Soilwork
6 sept. 2004 à 23:28
http://www.research.att.com/~bs/new_learning.pdf
6 sept. 2004 à 22:45
6 sept. 2004 à 22:20
En tout cas, il vaut mieux prendre de bonnes habitudes dès le début, et NE PAS s'habituer a utiliser le C++ "made in crosoft" qui n'a rien a voir avec le C++ standard ... :( GCC/G++ POWER...
Sinon, personnellement je n'aime pas les librairies standard C++, ni l'utilisation des namespace, donc j'avoue que je prefere utiliser les anciennes librairies C plutot que les equivalents C++ ^_^
Allez, a plus tard
++
Soilwork
PS: Maintenant que j'y repense, ca me choque vraiment, ce comportement de VC++ 6... La portée des variables est une des premières choses importantes à retenir lorsqu'on apprend le C ou le C++, et ils ne sont meme pas capables de l'implémenter correctement dans leur compilo? *choqué*
6 sept. 2004 à 14:54
C bien parce qu'il utilise VC6
avec le 7 ça compilerais po...
et pr le mm raison, il n'y a po ces includes
6 sept. 2004 à 14:48
il manque en effet
#include <cstdlib>
#include <cstring>
et std:: en prefixe (on est en c++)
pour les fonctionnalité, ca serais tres pratique de surchargé les operateurs << et >> sur std::ostream et std::istream
et aussi de definir sont type iterateur pour pouvoir beneficier de certains algo de la stl par ex (c'est peut etre pas le but ?)
6 sept. 2004 à 14:21
Bon, je vois que djl et Nono sont arrivés avant moi pour examiner ton code source, donc je ne vais pas spécialement m'attarder sur celui-ci (mais un peu quand meme ;) ), d'autant plus que la solution que tu as choisie ressemble un peu à celle que j'ai utilisée pour ma propre classe CString, donc je ne vais pas critiquer! lol
Quelques petits détails pour commencer... D'abord, il vaut mieux zipper ton code source et l'uploader sur le site, si tu peux faire tout ca, plutôt que de le mettre directement en texte sur la page, c'est beaucoup plus pratique, pour ceux qui veulent l'utiliser, je trouve.
Ensuite, il vaut mieux séparer ton code en deux parties, un header avec la déclaration de ta classe et de ses méthodes (fichier H ou HPP), et un fichier source CPP avec le corps des méthodes. C'est plus pratique et plus lisible.
Deux petites choses concernant le code, au passage: D'abord, n'oublie pas de mettre les include nécessaires à ta classe (en l'occurence, stdlib et string).
Deuxième chose : dans le constructeur qui prend les N premiers caractères d'une autre chaine, tu marques ceci:
for(unsigned long i=0; i < lengthfromstart ;i++)
this->_pstr[i]=chaine[i];
this->_pstr[i] = 0;
Tu déclares la variable i à l'intérieur du FOR, donc sa portée se limite exclusivement à l'intérieur de cette boucle, qui ne contient qu'une seule instruction. Cela signifie qu'à la sortie de la boucle, pour l'instruction:
this->_pstr[i] = 0;
la variable i n'existe plus! A la place, tu dois écrire:
unsigned long i;
for(i=0; i < lengthfromstart ;i++)
this->_pstr[i]=chaine[i];
this->_pstr[i] = 0;
Et la, ca compile :)
Voila, c'est tout pour l'instant, je crois. Bravo en tout cas, c'est pas mal du tout, ca compile sans problèmes ni Warnings (après les deux petites corrections mineures) et tout a l'air de fonctionner, d'après les quelques petits tests que j'ai faits. Well done!
Si tu veux l'améliorer, tu peux ajouter des méthodes de remplacement, qui sont toujours très pratiques!
Bonne continuation!
++
Soilwork
2 sept. 2004 à 20:14
2 sept. 2004 à 17:32
tu retourne un objet par valeur (appel du constructeur par copie) et dans le context appelant l'objet est ainsi créé mais dans
CString& operator + (const CString *s) const { return *this + s->_pstr; }
tu retourne une refernce sur ce meme objet qui va etre detruit, donc c'est bien ce que je disais
*this + s->_pstr n'est pas *this, il faut
CString &operator + (const char *s) const
2 sept. 2004 à 17:16
concernant le warning, je retourne bien *this, c'est pour cela que je ne comprend pas ce qui ne va pas, voici ce que j'ai mis :
CString& operator + (const CString *s) const { return *this + s->_pstr; }
si je laisse CString au lieu de CString& ca marche, où est mon erreur ?
merci de ton aide
2 sept. 2004 à 17:03
sinon t'aimes pas std::string ?
2 sept. 2004 à 16:39
pour la gestion de taille je vais voir cela, c'est vrai que l'automatiser ne serai pas plus mal, quand à l'augmenter je le ferai si je constate qu'il manque des méthodes réellement utiles
à propos des opérateurs j'y avais songé mais si je met CString& en retour j'obtient un warning :
Warning C4172: returning address of local variable or temporary
comment faire dans ce cas ?
à mon avis c'est moi qui fait quelque chose de travers
en passant j'ajouterai juste un bravo pour tes BString Nono
2 sept. 2004 à 15:29
pour les autres, au moins l'objet en retour (si tu veux que ce soit fonctionnel)
pour la taille, un type non signé (size_t ou unsigned) c'est mieux
2 sept. 2004 à 15:01
ceci dit L est pas mal
mais
"Comme tout programme (surtout les miens ;-p) "
C OK tant que tu met po les MFC sous visual
une classe de mm nom existe
=> po pr tt prg
sinon, je trouve la gestion de taille plutot lourde
autant tout faire automatiquement
et ton idée enlevant un peu de fragmentation n'est po mauvaise
pour l'augmenter, jette dc un oeil a mes BString
+++
Nono.