Discussion :

[oodini]

Je ne sais pas pour vous, mais ce genre de test algo à l'écrit, ça m'a toujours stressé.
J'ai toujours l'impression de rater l'astuce de génie que je cherche en vain, perdant un temps fou, alors qu'en fait, c'est souvent tout con.

Pour ton dernier problème, j'imagine que si j'instancie un Array de taille nulle, à la destruction de l'objet, ça plantera.
Et il y aura de toute façon des problèmes, quelle que soit la taille...

Il y a deux autres cas d'erreurs plus triviaux...

[Iradrille]

Sinon, en ce moment, j'aime beaucoup faire discuter sur le code du premier exo là: https://www.x-formation.com/wp-conte...Developer1.pdf -- mais à réserver à des gens qui affirment un minimum de niveau de connaissance sur le C++ je dirai. C'est plus un sujet de conception en C++, où du recul sur les notions d'invariant et de contrat est nécessaire pour correctement appréhender tous les problèmes avec ce code.

Par curiosité, les 4 bugs sont bien :

Code c++ :

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
{
   Array<int> a(0);
   // m_pData non initialisé, erreur sur le delete
}
 
while(true) {
   auto p = new Array(unsigned(0xffffffff)); // un jour le new (dans le ctor) echouerra
   p->Set(unsigned(0xfffffffe), 0); // et on écriera quelque part ou il ne faut pas
}
 
// delete au lieu de delete[], ça peut se tester ?
 
// problèmes de copie / affectation
{
   Array<int> a0(5);
   Array<int> a1(4);
   Array<int> a2(a0); // a2 pointe sur la même zone mémoire que a0. Bug ou par design ?
 
   a1 = a0; // mémoire de a1 non libérée (bug)
   // a1 pointe sur la même zone mémoire que a0. Bug ou par design ?
 
   // multiples deletes sur la même zone mémoire (bug)
}

?
(Yen a d'autres ?)

Problèmes de design:
- réinventer la roue, std::vector existe, et fonctionne.
- getter non const.
- copie des éléments dans le getter, quelque soit leur taille ? Ça peut être assez catastrophique avec des gros éléments.
- vérification que des unsigned soient positifs : ça ne fait pas de mal en soit, mais c'est inutile.
- ctor a 1 argument non explicit : possible problème de cast.
- dtor virtuel ? Vouloir hériter d'un tableau semble bizarre.
- m_nSize pourrait être déclaré const.

Sinon, j'avais eu ce problème :
On a un tableau d'entiers, on cherche la paire des plus petits nombres uniques dans ce tableau. Même question pour la recherche d'un triplet.
Exemple: Dans [6, 2, 3, 4, 3, 9],
la paire des plus petits nombres uniques est [2, 4]
le triplet des plus petits nombres uniques est [2, 4, 6]

[Luc Hermitte]

Pour le delete[], en formation, je le fais observer avec le sanatizer -> `CXX=clang++ CXXFLAGS="-fno-omit-frame-pointer -fsanitize=address,undefined -g" make array` (si le fichier s'appelle array.cpp).

Sinon c'est l'idée, je dirai que pratiquement l’essentiel des problèmes (profonds et non techniques) de ce code se résume à la question : "c'est quoi l'invariant de la classe ?". C'est des questions que l'auteur ne s'est pas posées (ou peut-être si justement si cela a été écrit exprès pour des tests d'évaluation/entretien). Du coup des cabrioles à coup de programmation défensive sont réalisées, et cela reste pourtant très bancal.

[ternel]

Il y a plus grave, je pense.
l'allocation dans le constructeur peut échouer, et la classe s'imagine quand même avoir les éléments à dispositions.

Plus subtile, delete accepte NULL, il n'y a pas lieu de le vérifier (dans le destructeur).
Plus grave, mais déjà vu: puisque get suppose que le tableau est alloué, le destructeur ne peut pas s'attendre à ce qu'il ne le soit pas.

[Luc Hermitte]

Il y a plus grave, je pense.
l'allocation dans le constructeur peut échouer, et la classe s'imagine quand même avoir les éléments à dispositions.

Invariant non maitrisé

La classe devrait avoir pour invariants:
- je suis responsable unique du buffer
- le buffer est un pointeur valide vers une zone de nb_elements elements.
- Et on peut se rajouter éventuellement le cas: ni nb_element ni buffer (redondant) ne peuvent être nuls -- à voir avec le déplacement, je ne sais pas encore trop sur quel pied danser.

Et comme tout invariants, ils sont garantis de la sortie des constructeurs à l'entrée du destructeur.

EDIT: après oui, tu as parfaitement raison. C'est juste que je range ça dans "1- spécifier l'invariant ; 2- s'assurer qu'aucun chemin ne le viole".