Salut,
 
voici une partie de mon code:
 
cout <<"Votre nom : ";
cin >> p.nom;
 
nom est un char * d'une classe personne (p). On m'a dit que ce n'etait pas la bonne solution de mettre p.nom directement dans le cin, mais on ne m'a pas explique pourquoi ni la solution...
 
quelqu'un peut il m'aider?
 
merci

tu peux montrer comment t'as déclaré "nom"?

 
la ta structure sappelle p
et nom est un element de ta structure

 
ta pas prévu de faire un guide facile pour le html aussi? et le java?

voila comment j'ai declaré :  
class personne
{
   protected :
           char *nom;
           blablabla....
   public :
          blablabla ....
};

Des tutorials HTML? Plus tard peut etre!

[edtdd]--Message édité par Ace17--[/edtdd]

ben tu ferais mieux de déclarer nom de la maniere suivante
 
char nom[64];

non je dois absolument garder mon char *
 
comment dois je faire?

mais tu sais, quand tu fais :
char szNom[64];
szNom est quand même un char*.

les char* c'est tout pourri, il vaut mieux s'en méfier, suit le conseil char nom[TAILLE]; sinon tu risques d'avoir des problèmes d'allocation de mémoire (initialisation de var, etc etc)

Plutot de hardcoder la taille du nom dans la classe et d'utiliser un tableau statique, on peut créer le tableau dans le constructeur, c'est plus propre :
 

 
Après tu fais un accesseur du style  
 
Personne::setNom(const char* str) {
// assertions sur str...
   strcpy(nom,str);          // effectue une copie du nom
}
 
Le problème de ton "char* nom;" c'est qu'il s'agit juste d'un pointeur, donc si tu copies juste le pointeur dans ta structure (en faisant dans ce cas là "nom = str" ), il y à une hypothèse cachée : le contenu de str doit durer au moins aussi longtemps qu'une instance de Personne. Il faut à tout prix eviter ce genre de problème. En créant et en détruisant la chaine "nom" dans la classe, c'est Personne qui a la responsabilité de son propre nom donc ça reste cohérent.
 
Si tu considères qu'une personne possède nécessairement un nom, tu le mets direct en paramètre du constructeur, etc... etc...
Le C++ autorise autant de constructeurs que l'ont veut : il faut en profiter !
 
H.T.H.

 
Qu'est ce qui dit lui ? "char* c'et tout pourri" ???? Porte nawak...

tout à fait d'accord, si tu penses cela tu penses que les pointeurs sont pourris ... po compris l'intéret tu as !!  

utilisé n'importe comment, oui, c tout pourri

 
 
  C'est pas pourrit les char*, y faut juste savoir s'en servir...  
quand tu déclare un char*, c juste un pointeur. après, y reste à réserver de l'espace mémoire pour faire pointer le char* dessus, avec un petit malloc (ou un new char(NBCHAR) si t en c++).
après, y suffit de penser à libérer l'espace avec un free (si t'as fait un malloc) ou un delete (si t'as fait un new), et ça devient exactement la même chose qu'un char[]. Sauf qu'ici, c ce qu'on appel de l'allocation dynamique de mémoire, on a donc en plus la possibilité d'agrandir ou réduire l'espace mémoire réservé... bien utile desfois !
 
EDIT: ha... un peu en retard moi, apparement je suis pas le 1er à lui tomber dessus !

[edtdd]--Message édité par El_Gringo--[/edtdd]

 
Philosophique, la reflexion,

 
oui, mais pas tellement pour ce qu'il veut faire.
Je signalais simplement qu'il était dangereux de jouer avec des char* sans les initialiser, pas la peine de tous me tomber dessus chuis d'assez mauvaise humeur  

voici ce que j'ai fais pour corriger :  
 
{
if (nom) delete [] nom;
nom = new char[strlen(s)+1]; // s est passe en parametre  
strcpy(nom,s);
}
 
est ce que ca vous parait correct?
 
j'ai aussi une deuxieme question (je passe les details du code):
 
cout <<"Adresse : ";
cin >> adresse;
cout <<"Code Postal : ";
cin >> cp;
cout <<"Localite : ";
cin >> localite;
 
si dans adresse je rentre un truc du style "nom_de_la_rue" ca passe, si par contre j'entre "nom_de_la_rue numero", la demande du code postal est "skippée"... ca vient du fait qu'il y a un espace qui a ete encodé a la ligne avant
 
comment puis je corriger cela?
 
merci

essaie peut etre avec getline() ?

oui ca vient de l'espace met un _ et c bon
au fait garde ton char* c mieu
et tu met p->nom

ben justement c'est ca le prob,
 
je veux mettre un espace !
je sais qu'il y a une fonction pour "comprendre" ca mais je ne la connais pas, si quelqu'un la connait, qu'il me dise svp
 
merci

t'as essayé?

non j'ai pas su car je sais pas dans quel header cette fonction est definie, ni quelle parametre elle prend

jette un oeil là, par exemple : http://www.cplusplus.com/ref/iostr [...] tline.html

ok merci mais ca marche pas,
 
cette fois ci ce n'est plus "code postal" qui est skippé mais "adresse" lui meme !
ca m'avance pas ca

ah ok j'ai compris ce que tu voulais faire
c pour quoi qu'on te demande ca?
moi j'ai fait la meme chose en c++ avec getch

C'est une applic que je dois faire pour l'ecole (graduat en informatique)
 
c'est une hierarchie de ce type que je dois faire :  
                         personne
 
   membre personnel                      client
 
                         client station           client meteo

       
N'importe quoi.
En fait, c'est les declarations char nom[TAILLE]; qui sont pourries lorsqu'on ne maitrise pas la taille des donnees devant etre stockees par nom (cas d'une valeur recuperee depuis la console par exemple), car qque soit la valeur de taille, il y a toujours un moment ou qque chose de trop grand va vouloir s'y mettre. Les lois de Murphy marchent tres tres bien dans ces cas la:
Si le buffer a une taille fixe, elle sera trop petite.
Si on augmente la taille du buffer, elle sera toujours trop petite.
A+,

gilou a écrit a écrit :           N'importe quoi. En fait, c'est les declarations char nom[TAILLE]; qui sont pourries lorsqu'on ne maitrise pas la taille des donnees devant etre stockees par nom (cas d'une valeur recuperee depuis la console par exemple)

n'empeche si tu fais un char* nom; cin>>nom; après bonne chance pour manipuler nom...
 
'fin je repete, pour ce que j'en dis...
pour moi une alloc dynamique ne sert que si on tiens absolument a pouvoir mettre des trucs de taille variable
ici je n'en vois pas trop l'interet
 
enfin je vous trouve bien acide ce soir...

 
ha, bah quand on raconte n'imp, faut s'attendre sur un forum de programmation, faut s'attendre à se prendre des programmeurs sur la gueule !
évidement que char* ça marche pas bien (pas du tout d'ailleur je pense, ou alors 1 fois sur 10)... c mal programmé, c tout !
D'abbord, le C, c'est nul y suffit d'oublier de mettre les ';' à la fin de tes lignes et ça marche plus !

[edtdd]--Message édité par El_Gringo--[/edtdd]

L'interet, c'est quand tu ne maitrises pas la taille de ce tu as a y mettre, parce que ce sont des donnees exterieures a ton programme.
A+,

 
Pour faire ca, le mieux c'est d'utiliser la classe string
(std::string). En effet quand tu fais
cin >> p.nom  
 Le programme va ecrire a l'adresse p.nom ce qu'il a trouve
sur le flux cin. Toi tu dois avoir reserver la place suffisante
en memoire (allocation dynamique). Et si il n'y a pas la place,
ca ecrit n'importe ou !
 
 
Avec string tout ca se fait tout seul ! Et la chaine est
detruite quand tu n'en as plus besoin (destruction de la classe)
(#include <string.h> ou #include<string> using namespace std
a rajouter en haut du code).

 
Presque szNom est alors un const char * (on peut pas changer
l'adresse)

bah... un const char* c'est un char* ... qui est constant, mais c un char* !! non mais !

un const char *
c'est un char * qui est const
donc dont tu ne peux pas changer
la valeur. Donc tu as interet
soit a prevoir une taille suffisante
soit etre sur de la validite de
tes donnees. (quand je dis sur
ca veut dire qu'il n'y a pas
de moyen de faire autrement)
 
Si tu programmes en C++
la maniere la plus propre
c'est effectivement
d'utiliser les string.Point.
Si tu veux faire
sans, tu vas finir par reprogrammer
les strings.
 
Sauf evidemment si tu SAIS que
tes donnees ne vont pas depasser 32 caracteres
et que tu prends la peine de valider
tes donnees avant de les stocker dans tes
variables.  
Sinon donnees non validees => plantages
inexpliques + trou de securite potentiel.
 
A+
LEGREG

y a une question que je me pose sur les string et autres trucs de la STL:
si on en utilise, y a aucune dll qui est linkée en plus ? (ce qui ferai qu'on est obligé de livrer cette dll avec les appli)
par exemple, pour les MFC, on a MFC42.dll
là y en a réellement aucune ?

c'est pas un probleme lie a la STL
(qui est une librairie de templates)
mais plutot un probleme lie a l'implantation
 
A ma connaissance l'implantation de la STL de Visual
ne necessite pas de librairie dynamique externe.
(les mfc non plus sauf si tu compiles en dynamic)
 
A+
LEGREG

ha... soit t'as pas compris ce que je veux dire, sois tu te plante !
 
Si on fait une appli avec les MFC, on utilise la dll MFC42.dll
une fois que t'as compilé ton truc, tout bien, ton exe à besoin de cette dll pour fonctionner, qu'on l'utilise en dynamique ou en static... logique !
Sur nos postes, les environnements de dev (VC et autres) ont déja installé tout ce qu'y faut. Mais desfois, en arrivant chez les cliens, y a des surprises...
j'voulais savoir ce qu'il en est avec la STL... (string c bien un truc de la STL, non !?)

Tu es encore plus a la rue que moi apparemment
 

 
Donc pour la STL comme je disais  
ca depend de l'implantation
=> se referer a la doc de l'outil
des fois ca sert.
Les STL n'ont a priori pas
besoin d'une librairie dynamique
externe mais parfois il en faut
tout de meme une a cause
de l'implantation des STL par l'editeur
de la librairie.  
 
A+
LEGREG

legreg a écrit a écrit : Tu es encore plus a la rue que moi apparemment   Citation : You can link your application or DLL with the MFC library either statically or dynamically.   Feature Only in Professional and Enterprise Editions   Static linking to MFC is supported only in Visual C++ Professional and Enterprise Editions. For more information, seeVisual C++ Editions.If you dynamically link your application to the MFC library, you will, at a minimum, need to redistribute MFCx0[U].DLL and MSVCRT.DLL, where x is the version number. MFCx0[U].DLL includes all of the basic framework classes. All MFC DLLs use the shared version of the C run-time library; thus, MSVCRT.DLL is required. If your application uses the MFC database classes, such as CRecordset and CRecordView, you will need to redistribute ODBC and any ODBC drivers that your application uses.   Donc pour la STL comme je disais   ca depend de l'implantation => se referer a la doc de l'outil des fois ca sert. Les STL n'ont a priori pas besoin d'une librairie dynamique externe mais parfois il en faut tout de meme une a cause de l'implantation des STL par l'editeur de la librairie.     A+ LEGREG

 
Le bout de texte que tu me met en gras à rien à voir !!?
Ouais, si on met en static, peut être qu'il met là dll dans l'exe... ce qui grossit l'exe d'1 bon Mo, mais évite de se trainer la dll partout...