Salut
 
Bien que programmeur confirmé (s'il en est) en C++, j'ai un peu de mal a vraiment saisir la subtilité entre char[] et char*, et en particulier ce qu'impliquent des cast entre ces deux types.
 
A ma connaissance, ayant un char[], on peut retrouver sa taille avec un truc template compliqué (qui a été décrit sur ce forum je crois), mais avec un char* on peut pas. Donc du point de vue de compilo il doit y avoir une différence importante.  
 
En gros quand doit on utiliser lequel ?
QQun a des infos claires la dessus ?
Merci

 
Apres, il se trouve que du point de vue du compilo, tous les name sont des pointeurs vers char. Exemples :
 

 
edit1 : c'est pas une question de programmeur "confirmé" ca.  
edit2 : cette différence n'a rien d'une subtilité!!!

Leur emploi :  
Le char* sert souvent pour le passage de parametres. Si tu veux une fonction qui compte le nombre de caracteres d'un tableau de char, tu es obligé d'utiliser des char*. Exemple :

Et gare a celui qui me fera un commentaire sur l'intéret ou la fiabilité de ma fonction
 
Le char [n] c'est plutot pour stocker des chaines de caracteres que tu ne connais pas a la compilation.

char* name3 = "John Doe";  provoque une erreur de compilation en C++

Ah? Au temps pour moi alors. Je corrige.

donc ça aussi ça foire int string_length(char* s)

Pourquoi?
Tu veux dire, quand j'appelle la fonction ou quand je la définis..
edit : Au fait Taz j'en profite pour te dire que t'as un peu tendance a exhiber les erreurs des autres sans les corriger. C'est dommage, avec la connaissance que t'as, de n'en faire profiter les autres qu'avec une telle parcimonie  

le prototyp est chiatique

bon, ben voila, ca confirme ce que je dis.

Bon, Taz, je viens de tester avec g++ le code source que j'ai donné, il n'y a ni erreur ni warning. Alors franchement je vois pas ou tu vois un probleme.

parce qu'un compilateur n'est pas le C++ o:o
 
compile donc en g++ -W -Wall -std=c++98 -pedantic
 
 
ton code est pourri

et faites une recherche, j'ai déjà gueulé sur la différence des centaines de fois
 
 
et pas un couillon pour me dire que tab n'est pas une l-value

je SAIS ce qu'est une l-value. Seulement il se trouve que ce terme ne va pas tellement servir a Oualb car manifestement il n'a probablement jamais été confronté au probleme, sinon il aurait découvert par lui meme la différence * / [].
 
Qu'est-ce tu as contre moi? J'ai répondu a ta place, c'est ca que tu supportes pas?
 
Tout ce que tu sais dire, c'est des reproches. Mon code est pourri? Parce qu'il manque les const? C'est ca qui suffit a rendre un code pourri?  
 
Sérieux Taz, on est pas la pour s'engueuler, un peu de courtoisie quoi! J'ai pas été agressif, alors pourquoi réagir ainsi?

oui et je reste poli. l'absence de const est une faute grave
 
c'est pas ma faut si on vous apprends pas ce que c'est que le tableau

 
http://forum.hardware.fr/hardwaref [...] -43703.htm

Bon, je viens de compiler comme tu l'as dit :
g++ -W -Wall -std=c++98 -pedantic test.cpp
Ca ne change rien. Mingw n'est pas aux normes?

non

Peux tu m'indiquer un compilo qui le soit?

Comeau qui suit toutes les dernières modifications.
 
le problème c'est qu'en C++ les chaine littérales sont const char[n] mais pour le moment la conversion implicite passe par char *, puis const char*, donc ça sert pas à grand chose. la future révision du C++ rendra la conversion conforme à la const-ness des chaines littérales

 
C'est mieux ca?

t'es con ?

 
Je l'attendais celle la. Je sais bien qu'il manque le const dans la premiere ligne.
 
Et je sais aussi qu'il faudra modifier mon ++s en conséquence.
 
Mais je me tire de la discussion, t'es vraiment trop agressif.

moi aussi, t'as vraiment rien compris

La méthode Taz est particulièrement efficace, suffit de pas se braquer pour vraiment en profiter
 
Ca prend du temps de manger sans mettre les coudes sur la table et en se tenant droit. J'ai encore bcp de mal pour ma part.
 
Courage Ace17, dis toi que c'est pour ton bien...
 
Juste pour le fun (et me faire humilier des fois que ce soit pourri encore   ).
 

Cordialement,
   xter.

Au fait, rien à voir, mais il est vrai qu'en C++, contrairement au C, la norme veut que l'on utilise 0 et non NULL ?  
 
Je trouve ça bizarre, est ce vrai ? (un lien serait bienvenue )

oui. ça n'est pas bizarre. le c++ fait juste que 0 est une valeur spéciale affactable à un pointeru sans cast (un peut comme un mot clef, d'ailleurs, certains en parle)
 
le C ne permets pas ça
NULL ((void*)0)
 
certains pensent que NULL cai mieux, on sait qu'on manipule des pointeurs. mais le compilateur le sait il ? non. alros j'aime bien le 0;

là t'as abuser
 

 
faut y aller molo sur les const
 
le const de retour ne rime à rien
le const sur le pointeur, comprends bien qu'ici, c'est un garde fou que tu te mets pour t'empecher de modifier sa valeur.

Puis typiquement, un tableau sera sur la stack alors qu'un pointeur pointera dans le heap.

alors là, le typiquement ... moi je te mets des tableaux dans le tas et je te fais pointer tout ce que tu veux sur la pile... sans parler des tableaux statiques (ben oui la taille est fixe, ça reflète souvent un usage statique)
 
merci pour la version anglaise, le français est tellement plus long à écrire

Monsieur Taz : j'avais commencé à écrire pile puis en arrivant à « tas » je me suis dit que ce n'était pas assez usité. Donc j'ai tout passé en anglais. Je trouve assez déplacé de critiquer l'emploi de termes anglais consacrés par l'usage, sur un forum technique, dans un domaine où la litérature est en majorité anglaise. Par ailleurs je suis plus géné par les « t'es con » et autres politesses dont tu nous gratifies régulièrement que par les anglicismes.
 
Ensuite par typiquement j'entendais variables locales dans une fonction, ce qui me semble effectivement être un emploi « typique ». Et je disais justement ça pour souligner la le contraste statique/dynamique et la différence de nature entre les deux notions.

forum technique : si le terme existe en français, a suffisemment de sens et est tout aussi compréhensible, je ne vois aucune raison de s'en passer.
 
pile/tas n'ont rien à voir avec allocation statique/dynamique.

Avec mon bout de code, j'etais qd même pas si loin de la vérité
 
Xter.

avoue que la version que j'ai donnée est bien sympa quand même ?

En effet, j'avoue : ta version est plus séduisante.
 
En plus, je viens de comprendre qqchose de fondamental sur la gestion des pointeurs que je n'oserai repeter par peur du ridicule !
 
Cordialement,  
   xter.

toujours aussi agressif Taz

 
Faut avouer qu'elle est à chier, oui. Dans un strlen correct, on ne s'amuse pas à incrémenter deux variables lors du parcours de la chaîne mais une seule et du coup, son code en C ressemble à quelque chose comme ça:
 

mais on en a rien à faire, personne cherche à faire un strlen ici on illustre juste
d'ailleurs, aucun intéret ton cast à la con ... et puis je connais pas de strlen qui ne soit pas écrit directement en assembleur ... alors je sais pas ce que tu viens chercher... t'as gagné t'es content ...

 
Encore heureux...
 

 
Comment faire ça avec les pieds? C'est réussi...
 

 
Si mais tu es trop jeune pour le comprendre, petit scarabée.
 

 
Même remarque.
 

 
Moi non plus. On se fait un strlen en assembleur avec 36 variables incrémentales dont on pourrait se passer?
 

 
Oui, je suis content mais c'est un peu facile avec toi.

 
T'as pas l'impression de brasser du vent et de te faire mousser ?

 
Vanité des vanités, tout n'est que vanité et poursuite du vent, disait Qoheleth.
 

 
Ca non et d'autant plus que j'ai une femme pour le faire à ma place