Reprise du message précédent :

 
s'il utilise des char* c'est pas etonnant qu'il y ait des failles de securité par overflow    
 
char* zTagada = new char[strlen(zPouet)]; //et merde un bug  

 
Tiens, t'utilises les std::string entre temps, toi ?

 
Mauvais exemple : les développeurs du noyau, ils ont le temps et les moyens qu'il faut pour réécrire et débugger complètement leur code, c'est à dire tout le temps nécessaire pour un produit de qualité. Quand à ceux de gcc, outre qu'ils ont les mêmes facilités, ils utilisent un GC.
Quand à tes progrmmmeurs, si en plus d'être débutants tu leur conseillais du char* à tout va, pas étonnant que le projet ait explosé les délais.  
Perso, j'utilise les char* là où je n'ai pas le choix, et à des endroits très localisés, mais dès que possible, je store/transmets les chaines de caractère sous forme de string, c'est bcp plus propre.

merci el muchacho

Tout simplement c'est des projets en C, et là y'a pas débat y'a rien d'autre. Donne nous un projet sérieux en C++ qui utilise les char * à la place d'une classe string, et on n'en reparlera.

 
Vous n'allez pas me dire que ces mecs sont infoutus de se faire des structures string avec les fonctions qui vont bien. Tout ce qu'on peut faire en C++, on peut aussi le faire en C, même si c'est parfois compliqué.

 
Bref, si je comprends bien, les programmeurs open-source sont des masos qui choisissent volontairement de perdre leur temps à utiliser des nids à bugs alors qu'ils pourraient utiliser leur temps à optimiser leurs algos. C'est fou ce que le monde comporte comme programmeurs idiots qui n'ont manifestement rien de mieux à faire que de gaspiller leur temps
 
Je viens de jeter un coup d'oeil au source de mysql. Au milieu de milliers de char*, je tombe là-dessus:

 
Plus loin, il y a du free, du malloc, du realloc, du memcpy dans l'implémentation de la classe. Beurk, encore des idiots finis qui font du C en C++... Il faudrait qu'ils songent sérieusement à venir prendre des cours de programmation sur ce forum.

Encore une fois, ton premier exemple est un mauvais exemple :
les programmeurs d'OS utilisent à bon droit le C, puisque ce langage est le meilleur langage pour la programmation bas niveau. Et pour cause, il a été créé justement pour ça, pour écrire Unix. Une fois qu'on fait du C, on fait forcément du char *. Mais si on choisit un langage donné, c'est qu'on estime que sa puissance et ses fonctionnalités sont bien adaptées à ses besoins. Je peux donc te retourner ta remarque et supposer que les milliers de langages qui existent ont été créés en pure perte alors qu'on peut tout faire en C (voire en asm). C'est fou ce que les programmeurs peuvent gaspiller comme temps CPU... seulement voila, on dit souvent que le "programmer cycle" coûte plus cher que le "computer cycle". Tout est question de choix. Si le "programmer cycle ne coûte rien (à part de la sueur et le risque de ne jamais aller au bout si on entreprend un projet au-dessus de ses moyens), comme en open source, on peut tout faire au niveau le plus bas si ça nous chante. Dans le cas contraire, il est bien évident qu'il faut minimiser les risques.
Des exemples, on peut en trouver dans tous les domaines. Si Emacs est tjrs utilisé et tjrs en développement 20 ans après la version 0, c'est uniquement dû au fait qu'il est écrit à 90% en Lisp et non en C. Faire des modifs complexes de code en Lisp est infiniment plus simple qu'en C, comme en témoignent tous les major-modes de l'éditeur. Pourtant, Stallman n'est pas le dernier des programmeurs, mais il continue à bosser dessus alors que si Emacs avait été écrit en C, ce monstre aurait probablement été depuis longtemps abandonné éu profit de ses innnombrables concurrents.
 
Ton deuxième exemple est plutôt un bon exemple, puisque si les auteurs de MySQL écrivent une classe String, cela démontre bien qu'ils ont bien l'intention de l'utiliser, et de limiter au maximum l'utilisation de char*.
Dans une BD, où les chaînes de caractère sont un type fondamental, le choix d'une classe String bien adaptée est une évidence. Dans une BD, s'encombrer de char* aurait été une source de difficultés intarissable. Je suppose que dans le domaine de la BD, une classe String spécifique est nécessaire (pour des raisons de stockage et de recherche rapide, entre autres, je suppose). En l'occurence, après avoir écrit une classe String de qualité, ils ont pu se concentrer sur la qualité des algorithmes qui font la rapidité de la base.

Je pense pouvoir dire sans me tromper que derriere toutes class string ya un tableau de caractères
... ou alors il y a un truc que l'on ne m'aurait pas dit (Mulder?)
 
 

 
prend pas ton cas pour une généralité, tous les programmeurs opensource n'utilisent pas que le C

Bah bah bah. Le C c'est nul. Tout ce qu'on peut faire en C on peut le faire en assembleur, même si c'est parfois compliqué. Et c'est bien plus rapide.  

KDE, wxWidgets, QT, ... ils utilisent une classe string.

L-A-M-E-N-T-A-B-L-E
t'aurais simplement pu dire qu'on était des bouzes parce que std::string utilise en interne des char *, et que new utilise malloc etc...
Moi j'arrête là, on arrivera à rien avec toi.
Au passage, pour ta remarque sur les idiots, c'est aussi valable dans l'autre sens "les mecs qui ont créé le C++, il faudrait qu'ils songent sérieusement à venir prendre des cours de programmation avec DocMaboul."
Tu aimes le C ? Tu aimes les char * ? Ben jette un oeil aux sources de FLEX. FLEX, c'est en C, c'est hyper rapide, ça utilise à font les char *, ouai super !
Oui mais FLEX, à mon avis, il gagne haut la main l'IOCCC (http://www.ioccc.org/)

 
Prout prout prout. Ce que vous dites est vrai mais je n'ai jamais dit que le C++, c'est nul.
 

 
Je vous retourne le compliment. Ecrire une fonction de quatre lignes avec des char* en y foutant déjà un gros bug, effectivement, c'est "L-A-M-E-N-T-A-B-L-E" et j'aurai dû me dire que vous n'aviez pas les compétences requises pour les utiliser et encore moins pour les critiquer.
 

 
Je me suis déjà moqué gentiment de taz avec les appels au runtime C dans la stl, oui.
 

 
Bon débarras. Vous êtes d'une mauvaise foi consternante.
 

 
Ca m'étonnerait fort que les mecs qui codent la stl déblatèrent autant de conneries.

 
Là, je suis tout à fait d'accord avec vous, enfin presque, mais ce n'est pas exactement ce que vous disiez précedemment sur les char*. Auparavant, j'ai lu une critique des char*, pas de l'utilisation qui en est faite ou non dans un contexte donné (je préfère cette version d'ailleurs). Après, il arrive qu'on se fasse une ou plusieurs structures string en C, mais pas pour les mêmes raisons qu'en C++.
 

 
Là, c'est quand même un exemple un peu particulier.
 

 
Ca, je n'en sais rien. Pour l'instant, grep me retourne 15 000 lignes de C contenant char* ou char * et 1800 de C++ contenant String (source de mysql-4.1)
 

 
Je ne pense pas, enfin, pas pour l'instant.

Puisque nous n'avons pas les compétences pour juger les char *, laissons faire ceux qui les ont :
http://www.microsoft.com/france/ms [...] 02004.html

 
C'est justement le bug que l'on trouvait dans votre fonction Après, faut-il réinventer le runtime C pour éviter la possibilité que ces bugs puissent exister, j'ai comme un (gros) doute. Qualifier ça de nettement plus problématique, pour moi c'est vendre sa camelote et rien de plus.

Pas grand chose à voir, (histoire qu'on retire quelque chose d'intéressant de ce topic), mais je viens d'apprendre et de vérifier que la STL de VC 7 contient un petit buffer de 16 octets pour stocker les petites string sans faire d'alloc.

En clair ca veut dire qu'en dehors du C# managed, point de salut?
A+,

 
Il me semble que microsoft souhaite en arriver la

 
Ben si. L'expérience montre que les buffer overflows sont source d'une grande quantité de bugs et de la moitié des failles de sécurité.
 
Exemple :  
"We've delayed products such as Windows Server 2003 for nine months because of security issues," says Howard, whose job is to foster expertise among Microsoft programmers"
http://www.nwfusion.com/news/2004/0419codereview.html
 
Vraiment, le char *, c'est la plaie du C, si la classe string a été une priorité pour les créateurs de C++ (c'est pratiquement la première classe étudiée dans le Stroustrup), ce n'est pas pour rien. Alors pourquoi se passer de cette facilité ?

si la règle du "on ne paie que pour ce qu'on utilise" ne s'était pas appliquée dans ce cas présent, on l'aurait notre type de base string

 
tiens, ca a rien a faire dans ce topic, mais bon, je vais pas en faire un neuf rien que pour ca, pis le char *, on a tout dit dessus, je pense.
Bref, observe plutot et donne moi ton fin avis
 
 

 
tu vois comment faire pour que ca passe ? (nan, on peut rien changer au nom des fonctions / tronche des classes )
(pis non on caste pas en A non plus )

virtual void truc()=0;
 
quoi ? truc() est virtual pure dans C ? donc je comprends pas ...

 
y'a pas a comprendre, truc est virtuelle pure partout

bah alors ou est le problème ?

 
ben le probleme il est que mon supair compilo, soit il rale a cause d'appel ambigu, soit il veut linké en static. Et heuh, le corps de la fonction n'est pas (et ne peut pas etre) accessible au compilo au moment de la compilation.
 
Donc, j'ai l'air d'un con
 

compile nickel avec mes gcc 2.95, 3.3 et 3.4

Mäyrde, désolé, erreur dans l'énoncé
 
 

 
 
vala
 
 
et avec  
 
 

oui et alors ? tu vois quelque part une implémentation de truc() ?

Pour tout dire sur string et char *, faut rajouter que y'a un cas où string ne doit pas être employé : lors d'un catch ( std::bad_alloc & ).
std::string fait en effet une allocation, et si y'a eu bad_alloc juste avant... (idem pas de string dans std::exception)

 
Mais c'est pas son probleme au compilo, je veux qu'il fasse l'appel a travers la v-table

ok, je vois l'erreur. je comprends pas trop que le compilateur gueule pas d'ailleurs. l'opérateur de portée :: implique une recherche dans le référentiel lexical de la classe. ici ça foire au link ... ça aurait du péter avant. la solutioon à ton problème c'est tout simplement que truc soit un A*

moué . Jkiff pas trop mais bon. Y fait chier, franchement, quoi, une vtable c pas fait pour les ienchs
 
bref, toussa pour dire que les char *, c'est caca

quoi tu kiff pas trop ? moi je trouve ça carrémennent plus esthétique

 
Ben, c'est pas si étonnant à mon sens. Il doit juste vérifier que la classe C implémente les virtuelles pures lors d'une instanciation d'un objet de cette classe. Comme il n'y en a pas, il ne gueule pas sur la déclaration foireuse de la classe puisque n'ayant pas d'objet, il n'a pas de vtable à construire pour cette classe.

 
Bonjour, je vais m'incruster dans votre discussion, si ça ne vous dérange pas.
 
En fait, la classe string est loin d'être parfaite: celle que l'on trouve dans la plupart des implémentations de STL a plusieurs problèmes:
 
1. Elle ne fait pas de reference-counting.  
En l'occurence, avec:  
std::string a ("toto" );
std::string b = a;
On a 2 copies de la chaîne ici. Ce ne serait pas le cas si on copiait (et stockait) des char *.
 
2. Elle n'est pas du tout adaptée à un mix ansi-unicode. La plupart des "gros" projets doivent à un moment ou un autre passer à de l'unicode pour pouvoir vivre joyeusement tout autour du monde. Or, std::wstring n'a pas de format défini (c'est de l'UCS-16 sous Visual Studio/Windows, et de l'UTF-32 sous Forte/Solaris), et c'est une galère sans nom que d'utiliser iconv avec la STL.
 
3. std::string n'est pas du tout thread-safe lors de la concaténation (puisque le buffer peut être déplacé à tout moment).
 
 
Donc, il n'est pas choquant pour les gros projets d'utiliser ses propres classes de gestion de strings, plutôt que de réutiliser celles de la STL.
 
Maintenant, pour un projet de taille moyenne, std::string est probablement la meilleure solution. Il faut juste se souvenir de tout passer par référence. :-)
 
Quand aux projets OSS, ils utilisent du C, parce que beaucoup de "hackers" se méfient du C++ en raison de son histoire un peu houleuse (peu portable jusqu'à récemment, compile 2 fois plus lentement, génére de gros exécutables, les compilos ne sont pas disponibles pour tous les unix, etc, etc.). Et les projets qui bénéficieraient de l'utilisation de C++ sont tous faits en Java de nos jours...
 
--pas de sig.

D'abord, std::string ou classe string custom, pas de pblm. std::string a le mérite d'exister, mais elle ne peut pas sattisfaire tout le monde.  
1. ça dépend des STL (celle de VC++ 6 fait du COW & ref. count.) mais normalement elle ne doit pas car le standard ne le permet pas (=> celle de VC++ 7 ne le fait plus).
Le faire avec des char * est pas évident, faut associer à ton char * un compteur... => quand faire le delete ?
2 c'est plutot wcahr_t qui est visé. Une autre classe string unicode va forcément faire un choix, et vu ce que tu viens de dire, ce choix sera adapté ou non à certains compilos. Je ne vois pas trop la spécificité de wstring là dedans.
3. char * non plus et c'est spécifique à chaque implémentation de la STL, mais en général c'est pas le cas. Si on réfléchit c'est normal : le C++ standard ne permet pas de créer des thread, alors... Mais il me semble que pas mal d'implémentations sont + ou - thread safe
http://www.dinkumware.com/libcpp.html
http://www.mvps.org/vcfaq/lang/8.htm
http://www.sgi.com/tech/stl/thread_safety.html

1) c'est un point de vue
2) tu peux ranger ce que tu veux dans tes std::basic_string
3) peut être que je n'ai pas envie de payer pour ça comme je paie en Java quand j'écris "a" + a + "b" + ...

 
Bon, on est globalement d'accord, mais quitte à enc*ler les mouches...  
 
Déjà, la classe string est un ajout tardif à la stl, ce qui est bien dommage. Sans parler des mappings CORBA qui ne l'utilisent pas du tout, etc. Bref, c'est un peu une classe désavouée, ce qui est bien triste vu ses capacités. Mais ça aurait pu être pire, elle aurait pu finir comme les shared-pointers et autres hash-maps...
 
Il me semble que la STL recommendait en fait de faire du COW (copy on write),mais devant les gros problèmes d'aliasing, a préféré jeter l'éponge, comme quasiment toutes les implémentations. Mais je me trompe sans doute...
 
Pour ce qui est de char et wchar_t, c'est implicitement ce que je voulais dire: il n'existe aucun mécanisme (façon java) te permettant de manipuler un type (une classe) unique sans faire de préconception sur son contenu.
std::wstring s = getInputFromXML();
size_t l = s.size();
Ca ne marchera pas si tu n'a pas converti ton entrée vers le type correct de wchar_t. J'aurais aimé une classe qui contienne la chaîne, ainsi que la représentation (8 bits/16 bits, etc.) de la chaîne si nécessaire, avec tout ce qui faut pour convertir d'une représentation à l'autre.
 
Pour ce qui est de la thread-safety, c'est un long débat, et on ne vas pas rentrer dedans, mais grosso-modo, la STL de base n'offre effectivement de solution thread-safe au problème du "producteur-consommateur" que si tu utilises les std::list. Or, une liste de char, c'est un peu abrupt, non ?  

... y aucune notion de thread dans STL alors qu'est-ce que tu veux ...

Pour le COW, l'explication que j'ai lu a plusieurs endroits c'est que c'est en contradiction avec le standard. Je t'avoue que je suis pas allé vérifier
Pour la conversion string <-> wstring je suis d'accord, ca serait cool d'avoir une conversion facile. D'un autre côté mixer les 2 n'est généralement pas une bonne idée, mais y'a tjrs des cas où...
Au lieu de convertir ton type en wchar_t pour pouvoir utiliser wstring, tu peux tout simplement faire ton propre basic_string< ton_type, ...>.
Pour les thread, le débat devrait plutot porter sur le langage que sur la STL. Si C++ permettait de créer des thread il serait aberrant que la STL ne gère pas ça. Mais comme c'est plutot l'inverse...

Bon, déjà pour recadrer mon message initial: certes, char* c'est caca, mais il peut y avoir des fois où on en a besoin pour des usages délicats.  
 
 
Maintenant, le C++ et la STL ne définissent rien au sujet des threads, mais le C++ ne définit pas non plus comment on exécute un programme, où s'affiche (ou ne s'affiche pas) cin, cout et cerr, et définit par contre très bien le mot-clé export qui n'est pourtant pas reconnu par les compilos (à part par EDG/Comeau, et encore...). Ca ne nous empêche pas de faire des programmes qui affichent "Hello World".
 
Le gros problème du C++ à mon sens, c'est qu'on n'a pas su fédérer de  
mouvement de standardisation d'un environnement et de librairies communes aux OS modernes (Windows, Unixes, PDAs, et autres systèmes posix).  
 
Donc, on n'a rien sur le graphisme, les fenêtres, les signaux, les sockets, la mémoire partagée, les threads, les systèmes de fichiers, etc.  Et c'est frustrant, puisque ça cause des gros problèmes de portabilité, alors même que c'est le souci de portabilité qui est au coeur du langage C++.
 
Donc, moi je vote pour une librairie STL2 qui définisse tout ça, en se basant sur Boost, Loki, GLut, Ace, etc. Hé, si le monde Java y arrive, ça doit ête possible pour le C++, non ? (attention, cette phrase est peut-être un troll ).
 

'on ne paie que pour ce qu'on utilise' c'est tout ...
 
Boost c'est une chose, mais le reste, c'est du délire.