Discussion :

[Goten]

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).

[3DArchi]

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.

[deubelte]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Médinoc]

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.

[jblecanard]

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

[Médinoc]

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

[jblecanard]

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.

[Médinoc]

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...

[Goten]

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

[Médinoc]

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.