Diff�rence entre char &r='c' et char r='c'

C'est de la "m�moire" interne au processeur, bien plus rapide que la ram. (t'as dis r�sum�... je r�sume xD)
Mais lis plut�t un cours d'architecture syst�me et de syst�me d'exploitation .. (le Tanenbaum reste mon pr�f�r� :p).

deubelte,
Tu te perds dans des d�tails qui n'apporteront rien � ta compr�hension des adresses, des pointeurs et de la gestion m�moire. D'autant que des notions comme tas ou pile n'existent pas en C++ mais sont li�es au fonctionnement des PC et de certaines plateformes. D'autres ont des strat�gies de gestion m�moire diff�rentes. Ce que tu arriveras � comprendre sera donc d�pendant de la plateforme sur laquelle tu interviens et du compilateur que tu utilises. L'important est plus de comprendre comment est sp�cifi�e la dur�e de vie d'une variable, comment intervient la gestion dynamique, qu'est-ce qu'un pointeur, pourquoi on s'en sert (puis comment), quels sont les risques li�s et comment on y rem�die, etc.

Bonjour,
j'ai une question concernant toujours les r�f�rences. SI on consid�re cette classe:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

class set_int{   public: int *adval; int nmax; int nelem; public: set_int(int=20); set_int (set_int const & ); set_int operator =(set_int &); ~set_int(); };   set_int set_int::operator=(set_int &e){ { if(this !=&e) { delete adval; this->adval=new int[nmax=e.nmax]; this->nelem=e.nelem; int i; for(i=0;i<nelem;i++) this->adval[i]=e.adval[i]; } return *this; }   }

---

Quelle sera la diff�rence la m�me classe, mais si la surcharge de l'op�rateur = renvoie une r�f�rence:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

set_int & set_int::operator=(set_int &e){ { if(this !=&e) { delete adval; this->adval=new int[nmax=e.nmax]; this->nelem=e.nelem; int i; for(i=0;i<nelem;i++) this->adval[i]=e.adval[i]; } return *this; }   }

---

Par exemple, avec un essais de cette classe:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void main(){ set_int ens1,ens2,ens3; int i,n; for(i=0;i<20;i++){ ens1.ajoute(5); ens3.ajoute(6); } for(i=0;i<20;i++){ ens2.ajoute(i); } ens1=ens2=ens3; }

---

Je ne vois pas la diff�rence.

Il est d'ailleurs �crit dans le bouquin que je lis: "A priori seule la valeur du pointeur du premier op�rande � besoin d'�tre transmise par r�f�rence, pour que= puisse le modifier: cette condition est obligatoirement remplie puisque notre op�rateur est surd�fini comme fonction membre. Toutefois en pratique, on utilisera �galement la transmission par r�f�rence, � la fois pour le second op�rande et pour la valeur de retour, de facon � etre plus efficace en temps"
Ce qui fait qu'on aurait pu �crire:

Code:

---

1 2	set_int set_int::operator=(set_int e){ {....}

---

Etant donn� que seul this � besoin d'�tre pass� par r�f�rence.
Merci

Disons que c'est surtout important pour d'autres op�rateurs surcharg�s, notamment les op�rateurs de d�calages de bits surcharg�s en "insertion/extraction de flux" : L'op�rateur surcharg� prend en param�tre une r�f�rence vers le flux, et retourne cette m�me r�f�rence.

PS: J'ai appris un truc, aujourd'hui: que type & uneRef = *unPointeur; compte comme un d�r�f�rencement de unPointeur.
Ce qui donne la propri�t�: Dans un programme sans comportement ind�fini, il ne peut y avoir de r�f�rence nulle.

Citation:

---

Envoy� par M�dinoc

PS: J'ai appris un truc, aujourd'hui: que type & uneRef = *unPointeur; compte comme un d�r�f�rencement de unPointeur.
Ce qui donne la propri�t�: Dans un programme sans comportement ind�fini, il ne peut y avoir de r�f�rence nulle.

---

H��� non justement on a test� �a sur Visual Studio (voir plus avant dans le topic) et �a ne d�r�f�rence pas :(

J'ai pas test� sur GGC mais je suppose que lui d�r�f�rence

Pardon, compte logiquement, vu de la norme, comme un d�r�f�rencement du pointeur.

Citation:

---

Envoy� par M�dinoc

Pardon, compte logiquement, vu de la norme, comme un d�r�f�rencement du pointeur.

---

Oui vu de la norme, et du coup, il semble que ce soit un point de la norme que VS ne respecte pas.

Je ne crois pas que la norme oblige l'impl�mentation � physiquement d�r�f�rencer le pointeur. C'est juste qu'elle ne d�finit pas ce qui se passe si on essaie...

En m�mte temps c'est un peu ce qu'on essaye de dire avec loic depuis deux pages :s...

En effet, mais j'ai eu du mal � en voir la conclusion.

Le fait important est surtout que la norme n'interdit pas � l'impl�mentation de d�r�f�rencer physiquement le pointeur.