# Commentaires ## Commit (22/03/21 00:27 à 01:43 UTC): 8b10e44 -> 530f793 -> d756ba3 - [ ] Je suis censé me pencher sur **les iterateurs** aujourd'hui, pendant que tu faisais le assign. Mais tu a bien galopé hier soir :). En implementant les méthodes `deque.front()`, `deque.back()` et `deque.at()`. :+1: Bien joué. - [ ] Même commentaire que le commit précedant concernant les `deque.assign()`. ## Commit (22/03/21 00:21 UTC): 45930bc - [ ] Même commentaire que le commit précedant concernant les `deque.assign()`. ## Commit (22/03/21 00:17 UTC): 736a904 ### Idée - [ ] Utiliser `this.clear()` pour vider un objet deque - [ ] Quand on implementera la fonction swap. On pourrait s'en service par exemple dans le assign operator: d'abord en créeant `deque A = deque(..)` ensuite `this.swap(A) ou this.swap(B, A)` et return *this (qui entrainera `~deque()` de A) ### deque.assign(count, value) - [ ] En testant ton commit `736a904`, j'ai vu que pour `deque.assign(10,a)`, il y a problème avec le `~deque()`. De plus d'après la doc de la [lib std](https://www.cplusplus.com/reference/deque/deque/assign/), elle dit ceci: >**Assign container content** > > Assigns new contents to the deque container, replacing its current contents, and modifying its size accordingly. Donc notre assign ressemblera au constructor **_`deque(size_type count, const T&value)`_**. Alors pourquoi ne pas servir de notre **constructor**: ``` void assign( size_type count, const T& value ) { // clear current object clear(); deque<T> newDeque = deque(count, value); tabLength = newDeque.tabLength; tab = newDeque.tab; newDeque.tab = nullptr; // prevent ~deque to free mem nbElements = newDeque.nbElements; firstPtr = newDeque.firstPtr; lastPtr = newDeque.lastPtr; firstVal = newDeque.firstVal; lastVal = newDeque.lastVal; } ``` Par conséquent, pour eviter que `~deque()` vide quoique ce soit alors que `tab == nullptr`, voici à quoi ressemble le code de `~deque()`: ``` ~deque() { if (tab != nullptr) { for (int i = 0; i < tabLength; i++) { if (tab[i] != nullptr) delete[] tab[i]; } delete[] tab; } } ``` ###### (\*) *J'ai simplement deplacé le test de `tab != nullptr`* Et la fonction **clear()**: ``` void clear() { // this method will free the content of the object for (auto i = firstPtr; i < lastPtr; i++) if (tab[i] != nullptr) delete[] tab[i]; if (tab != nullptr) delete[] tab; tab = nullptr; // make sure that pointer will not be used tabLength = nbElements = 0; firstVal = lastVal = firstPtr = lastPtr = -1; } ``` **Conclusion:** Après tout cela, il est vrai qu'on pouvait se dire pourquoi libérer la mémoire alors qu'on pouvait l'utiliser en modifiant simplement les valeurs dedans tout en prennant en considération les cas (`count > nbElement`, etc.) comme tu l'as fait dans le code de ce commit. Mais cela nous ramène toujours a realloué le tableau en plus grand en cas ou `count > nbElement`, puis le recopier, etc. Et c'est justement cela qui m'a sur la piste de pourquoi ne pas faire realloué le tableau dans tous les cas! Par ailleurs, dans le cas où `count < nbElement`, comme ton idée de départ était de ne pas se retrouver un tableau de pointer avec des cases vide. De ce fait, nous retrouverons aussi à faire une réallocation du tableau avec une taille réduite et vidage du précedent, etc. Au final, n'oublie pas que notre tableau n'est pas dynamic(malheureusement pas de vector). Donc les réallocation c'est à nous de le faire tout le temps où c'est necessaire. ## Commit (20/03/21 00:49 UTC): d2dc367 ### Libérer la mémoire d'un tableau - [x] `delete[] other.tab[i]` libère la mémoire de ton tab chunk. Donc attention à `this.tab[i]`. Si `this.tab[i]` pointe sur le même chunk que tu libère alors booom. - [x] Donc à la ligne 204 (`deque.h`), faut pas. Il faut plutôt mettre en dehors de ta boucle for ceci: `delete[] tab` qui est donc censé libéré ton tableau de pointer vu qu'on la depouiller (à chaque fois que le move rentre en jeu).