Reprise du message précédent :

 
Merci HelloWorld, pour cette intéressante lecture en perspective. J'ai pas encore tout lu, mais je cerne déjà un peu mieux la question.

Pour le débat char* / string, je pense que la programmation demande avant tout de la rigueur, et pas des classes qui permettent de compenser une éventuelle lacune dans ce domaine.
 
Parce que dans ce cas, la chasse aux sources d'erreur est sans fin : le jour où plus personne ne saura ce qu'est un char*, on crachera sur les classes string parce qu'on peut sortir de la string en faisant myString[47869] alors que myString contient "Bonjour" ...
 
Ben oui, il y a des risques ! Pour moi, la solution est avant tout l'attention et la rigueur.

oui. vas y, conduit sans ceinture, suffit de faire attention ...

Dans un programme, tu as la possibilité de tout contrôler. Les erreurs techniques (ram, cpu, etc) sont ingérables (à ma connaissance) et c'est pas une classe qui sauvera la situation.
Dans une voiture, tu es soumis aux pannes techniques, aux erreurs des autres conducteurs etc ... Les erreurs ne proviennent pas que de toi.
Donc je pense que ton exemple est mal choisi.
 
Je suis simplement d'accord avec DrMaboul quand il dit :
 

 
 
Voila

je suis consterné par tant de bêtises : comme l'a déjà dit chrisbk, y a qu'en C++ ou les gens refuse d'utiliser le type string ... que des cons ...
 
d'ailleurs, conduis sans ceinture, sors moi le statistiques d'accident du au matériel, tu es ridicule ... et cherche dans le dictionnaire le mot 'abstraction' ...
 
 
allez branlez-vous bien avec vos char*

Taz> Euuh t'as quel âge ?

Y'a les fonctions de lecture de fichier à prendre en compte. Moi j'avais testé les string vs les char * dans un prog qui ne fait que de la manip de string (vous savez le programme des fournmis, chaque ligne est construite à partir de la précédente :
1
11
21
1211
111221
...
Mon but était justement de montrer la médiocrité des string...
ben ho surprise la différence était de l'ordre de 5 à 10%. Moins de 10% de perf en moins pour un code bcp moins long et bcp bcp plus lisible, ce jour là, j'ai basculé du côté des string.
 

C'est ça. T'as développé bcp de soft toi ? Dans un gros soft, avec plein de choses à penser, t'a sautre chose à fouttre que de te préocupper de la taille de ton buffer char *. Et les char * voilà comment ça finit :
http://gaim.sourceforge.net/security/index.php?id=0
"Ben oui, il y a des risques ! Pour moi, la solution est avant tout l'attention et la rigueur". Elle est bien bonne celle là. Quand y'a un risque, la solution idéale c'est d'éliminer le risque. Et là c'est le cas, on a std::string.
Vas-y, écris moi une fonction de ce genre avec les char *:

C'est simple, beau, propre, lisible, fiable.
Le truc courant en C c'est :

C'est typique en C, archi courant. Et regarde ça :
NoName => 6 caractères + \0
taille de name : 1000 carcatères, ouai c'est la fête, venez parler de performance et tout et tout après.
 
Ne pas se prendre la tête sur ce genre de stupidités, c'est se permettre de mieux se concentrer sur le prog en général et son algo, et c'est là qu'on gagne en performances et en fiabilité, par en utilisant les char *.

 
L'allocation dynamique est assez utilisée dans le cas des char*.
 

 
Voila les char* ne sont pas nul bien au contriares je pense que les deux méthodes ont leurs avantages. Faut pas etre si catégorique HelloWorld  ca te perdra un jour d'etre si sur de toi!!!

HelloWord> Je suis bien d'accord avec toi (un peu moins d'arrogance et j'étais encore plus d'accord ^^) : je n'ai pas dit qu'il ne fallait surtout pas utiliser des string et n'utiliser QUE des char* !
 
Je pense juste qu'il faut évaluer les avantages et les inconvénients de chaque avant de faire un choix. Pour une grosse applic en C++ (ce que je n'ai jamais fait, pour répondre à ta question), j'utiliserais des strings. Mais pour mes contrôleurs d'automates et mes systèmes embarqués, bah je suis bien contraint d'utiliser des pointeurs et la seule solution pour ne pas faire d'erreur est bien de faire attention. Evidemment, la partie interne du programme peut fonctionner avec des strings, mais il viendra fatalement un moment où je devrai les convertir en char*.
 
La programmation ne se limite pas aux programmes bureautiques : il y a d'autres domaines d'application où les besoins sont différents.
 
 
Voila, c'est tout ce que je dis ! Pas besoin de se mettre dans de tels états (je pense surtout au dernier post de Taz =/ ) pour ce genre de discussion.

 
Et on sait tous que les debutants la maitrise sans probleme. J'espere que tu delete() bien le caca qu tu laisse derriere toi
 
 

 
y'a strdup qui existe. (sauf qu'apres fo faire free() dessus )
Pis ton joli code (porcin), la, si un jour tu fais pas cette recopie (parce que hein, c'est chiant de tjs devoir taper ca), mais que tu te contente de garder ton petyt ptr sur char *, ben t'auras l'air achement fin lors du free/delete.
 

 
Perso je veux plus en voir dans mon C++. C'est un nid a emmerde, et qu'on ne me sorte pas des "Faux savoir coder" ou "Suffit d'etre propre", c'est du pipeau. Un pointeur vers un char * qui t'arrive dans les mains, tu ne sais jamais si tu peux le garder tel quel, si il faut dupliquer la chaine, si le voisin a pas freer() le pointeur que t'as passé ou je ne sais quoi. Pourquoi vouloir absolument se compliquer la vie ? le C++ est deja bien assez touffu comme ca sans que l'on se sente obligé d'en remettre une couche.
 
Tu dirais quoi en Java ou en c# si j'utilisais un char[] pour faire mes strings ?
 
je sais pas pour helloworld, mais moi si je suis catégorique, c'est que j'ai eu trop d'emmerde avec ces char * pour ne pas les hair.

 
Déja il n'y a pas que les debutant qui utilise ca renseigne toi mon grand.
Ensuite ne t'inquiete pas  si je code parfois avec des char* c'est que je libère ma mémoire.
 

 
REmarque: Ca n'est pas mon code mais l'exemple de helloword.
 
 
En tout cas relatvise plus tu peux pas tout connaitre donc reste calme. T'enflamme pas. En plus tu parles de java et les appli de java ne sont pas les même que les appli C++.
Bref soit plus humble face a tes connaisssances.
 
++

J'ai horreur qu'on m'appelle mon grand.
 
 
 

 
Ouais c'etait une comparaison hein, tu comprends ?
genre  
char * => char[]
std::string => String
 
tu sois l'idée ? En java ton string tu le fais avec quoi ?
 
 

 
gnagna

J'ai pas voulu être arrogant, j'ai été piqué à vif en quelque sorte
Pour le reste, on est dans la catégorie C++. Même dan sun prog embarqué en C++, char * n'a pas sa place selon moi.
 
 

En fait mon exemple renvoie "NoName", mais l'idée est que ça renvoit une string différente à chaque appel (genre NoName0, NoName1, ...).
Donc si tu pouvais refaire une version qui tient compte de ce fait.
Mais même avec ce que tu as fait je vois pas du tout du tout l'avantage par rapport à string, vu que c'est exactement ce que fait std::string, sauf que c'est fait en une seule ligne (une affectation) et qu'en plus ça gère le delete...

 
Tout le problème est pourtant là. La fonction de HelloWorld génère un gros bug potentiel par exemple. Forcément, si on n'est pas capable d'écrire correctement une fonction de quatre lignes avec des char*, mieux vaut utiliser des objets strings.
 

 
Pour ma part, faisant du C, j'utilise les char* à gogo et la dernière fois que j'ai eu un leak, c'était sur une structure entière  (rien à voir avec les char* donc) et parce qu'un matin la tête dans le cul j'avais interverti l'initialisation de deux variables. Il suffit d'être au clair avec soi-même pour ne pas avoir de problèmes. Et du reste, ce n'est pas un problème spécifique aux char* mais à l'allocation dynamique.

En fait tout est là je pense. Tu ne vois pas le probleme des char * parce qu'il semble que tu les utilises correctement.
Malheureusement, et c'est ma petite expérience qui parle, tu es plus proche de l'exception que de la généralité.
Pas plus tard que y'a quelque jours je me suis tapé cette gestion de char * à la MAX_LEN = 1000 dans un prog C++, et le tout enrobé de macros, évidement. Fonctions à appeler dans le constructeur des classes, fonction à appeler dans le destructeur, ... et tout ça plantait royalement, impossible de tracer une macro au debugger, bref, juste 1 journée de perdue à s'arracher les cheveux sur 1 seul bug.
Si on est si susceptibles, c'est que nous on l'a vécu ce moment où toute la théorie du char * merveilleux s'écroule et laisse place à trou sans fond où tu finis par déprimer. Le jour où ça t'arriveras et que tu verras que si le mec avait remplacé ses char * par des std::string :
- y'aurait pas de bug
- ça serait bcp plus lisible
- ce serait plus performant
toi aussi tu partiras en croisade sur les forums à combattre les char *.

Donc réglons ce problème en se passant de l'alloc dynamique et en utilisant string.
CQFD.
 

Ca aussi c'est de la belle théorie. Etre au clair avec soit même c'est facile je te l'accorde. Mais dans le monde moderne t'es pas seul sur un projet, et être au clair avec les autres, c'est une autre histoire. C'est logique pour toi parce que c'est ton code. C'est précisement à cause de cela que c'est illogique pour un autre. Le meilleur moyen de mettre tout le monde d'accord sur un probleme, c'est de virer le problème. Pas de fonction à appeler, pas de désallocation à faire et tout va bien pour tout le monde.
Selon moi, un bon programmeur ne programme pas pour lui mais pour les autres. Plus ton code est simple, moins il y a de choses à avoir en tête et meilleur il est, toujours selon moi.

 
vous vouliez dire en utilisant VB, je présume...

Pourquoi pas. Mais qu'est-ce que ça vient faire là ?

 
Ca vient faire là que si vous virez tout ce qui fait l'avantage du C/C++, à savoir la technicité, pour ne vous concentrer que sur l'algo, alors autant faire du VB (ou du php si vous préférez): plus de problèmes de mémoire à gérer, de pointeurs qui peuvent se barrer en couille, de '\0' à ne pas oublier après le strncpy , ...

C et C++ c'est 2 choses différentes. Je sais pas ce que tu entends par la technicité (le fait de sentir son ego renforcé parce qu'on est le maître de la mémoire de son ordinateur ? ), mais j'ai peur que ce soit ce que "les autres" reprochent à ces 2 langages.
Si j'utilise c'est essentiellement à cause / grâce aux templates et à la programmation générique. Je n'utilise pas de pointeurs, au pire des shared_ptr, et sinon c'est des références.
Fait de l'Automation en C pour voir. Tu auras une autre vision de VB ensuite.
Et PHP, je vois pas le rapport.

 
 
D'après mon expérience, les pires programmeurs dans un projet ne sont pas les débutants, mais les programmeurs expérimentés qui croient tout maitriser et qui utilisent des idiomes obsolètes et des algos/structures pourris pour "optimiser" leur code.
 
Ceux-là, il faut les tuer.
 
J'ai vu à maintes reprises les effets ravageurs de leur code, qui régulièrement à fait perdre 6 mois à 1 an-homme pour réécrire A PARTIR DE ZERO tout leur code (généralement après qu'ils soient partis ou qu'on les ait virés).
 
Autrement dit, ces parasites font perdre 1 à 2 ans-hommes au projet.

 
Désolé, mais même dans la plupart des applications embarquées (j'en ai fait pas mal, avec des contraintes mémoires assez limitées, et j'en fais encore), je ne vois pas trop l'intérêt de s'emmerder avec des char* (sauf dans quelques algos bien ciblés que l'on va de toute façon tester à fonds).
A quel cas particulier penses-tu ? Il faut vraiment que l'appli soit critique pour que ça en vaille la peine, parce que généralement, on peut gagner bcp en réfléchissant un peu plus aux algos et aux structures que l'on utilise.

 
  Et tjrs dans ce monde moderne, où on a tjrs moins de temps pour développer que ce qui est nécessaire pour faire un code parfaitement propre et testé, le code dégueu est malheureusement plus souvent la règle que l'exception. Mettez la-dedans un nid à bugs qu'est le char *, et il va inévitablement se propager de méthode en méthode, et     pour peu qu'on ne fasse pas du test exhaustif avec couverture, random, etc, on n'est jamais certains qu'un loup ne se cache pas qq part. Personnellement, je n'appelle pas ça du code industriel.

 
Plutôt le fait que chaque instruction pourrait potentiellement entraîner un joli coredump parce que l'implémentation du langage ne passe pas la moitié de son temps à vérifier que le programmeur ne lui demande pas de faire de conneries.
 

 
Je suis d'accord.
 

 
Ben php rapport que pas de types à gérer, pas de pointeurs, pas d'allocation dynamique, pas de technicité.

=> langages interprétés en général. Ce qui m'a surpris, c'est que PHP/C++ c'est pas le même domaine.

 
D'après la mienne, une brebis galeuse reste une brebis galeuse, quelle soit débutante ou expérimentée, et c'est le genre de choses qui se voit vite.
 

 
J'ai vu à maintes reprises des types passer des semaines entières à expliquer à des newbies comment coder 'correctement' en C (pas de manière optimisée, hein, juste sans faire trois bugs à chaque ligne). J'ai d'ailleurs démissionné de mon dernier travail dans l'industrie parce qu'on m'avait encore refilé deux nouveaux sortant à peine de l'école alors que j'avais demandé deux brutes pour un projet critique. Moralité: ils ont réécrit je ne sais combien de fois le code des newbies. Aux dernières nouvelles, le projet n'était toujours pas fonctionnel et le budget avait littéralement explosé.

 
Bon, el mariachi a bien résumé la position des pro-strings en qualifiant de nid à bugs le char*. Pour moi, ce sont les langages C/C++ qui sont des nids à bugs si j'adopte cette vision. Alors on peut tortiller du cul et se dire que, bon, on va faire sauter:
- tous les appels au runtime C
- tous les appels système
- tous ce qui ressemble d'un peu trop près à un pointeur
- tout ce qui est gestion mémoire
- ...
 
mais avec ce qui reste au final, je ne vois pas où se trouve l'intérêt de faire du C/C++. Autant programmer une machine à laver.

ce que je comprends pas c'est que si on doit faire un programme qui fais du traitement de chaines de caracteres, pourquoi serait-il mal d'utiliser des char* pour le gains de performance ? (comme ca ete dit on perd par rapport à std::string sur strlen et quand on enchaine des strcat mais ca c'est largement contournable)  
 
 

tu ne gagneras rien, et surtout il te faudra énormément plus de temps pour obtenir un programme de même qualité, performance et suretê/fiabilité

comment ca je gagnerais rien, tu veux dire que ca sera pas  plus performant?

non.

 
Même avec la stl du VC6 ?

 
idem : quand t'as une appli gigantesque qui utilise du char* de partout et que bien sur y a des memleaks de partout, mais que tu peux pas forcement faire des frees dessus parce qu'il pourrait être utiliser à un autre endroit que soupsonnait même pas, tu maudits les char* (et surtout les abrutis qui savaient pas les utiliser)

 
c'est joli ca et le const non ?

const ou pas, c'est pourri

Si, ton programmes plantera plus vite.

Un programme C++ correct respecte à peu de choses près ce que tu viens de dire (smart ptr, conteneurs de la STL, ...)
Ce qu'il reste (en C++) ? Les templates et la STL, déjà. C'est ce qui, malgré tout, permet d'être assez productif en C++.

Bon, je ne nie pas l'intérêt des structures/objets strings mais affirmer que le char*, c'est pourri/moisi/caca, c'est complètement niaiseux. S'il y en a qui veulent continuer à troller là-dessus, qu'ils envoient leurs remarques aux développeurs du kernel de linux ou de gcc: leur code moisi/pourri/caca en est truffé et je suis sûr qu'ils seront ravis de recevoir vos lumières avisées sur le comment du pourquoi d'un code est correct ou non.

hhaha ben vas-y écris leur savoir s'il préferait pas avoir un type C string, on va bien rigoler

 
Oui, ils préféraient aussi ne pas avoir de pointeurs, pas de mémoire et que la programmation se résume à appuyer sur trois boutons, comme sur une machine à laver. C'est le rêve de tout développeur ça, n'est-ce pas taz?

 
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