Un design pattern, c'est une proposition de solution à une problématique. Sans préciser à quoi correspond ces classes et la problématique, ça n'a pas de sens de parler de pattern.
Moi je sais: le design pattern de "la fuite de mémoire causée par trois lignes de code pre-C++11 et du new sans delete".
J'ai bon?
Pas forcément...
Cela dépend de ce que feront B et C des pointeurs qui leur sont fournis
Par exemple, avec B et C prenant la forme de
class B{
public:
B(A* ptr):data_{ptr}{}
private:
std::unique_ptr<A> data_;
};
class C{
public:
C(B* ptr):data_{ptr}{}
private:
std::unique_ptr<B> data_;
};
Pour autant que new B(a); ou new C(b); ne lancent pas une exception (ce qui, en l'état, a malgré tout peu de chance d'arriver), il n'y aura pas la moindre fuite mémoire.
Et comme nous sommes dans main, nous pourrions même encore nous en foutre, car, bien que ce ne soit pas "très sympa", le fait que la levée d'une exception nous fera sortir de l'application nous assure que le système d'exploitation fera le ménage pour nous
aurait d'ailleurs, à ce titre, exactement le même effet (mais ce sont le constructeur de copies et l'opérateur d'affectation qui fouteraient la merde :P)
- Edité par koala01 18 juin 2018 à 22:17:26
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Il n'y a pas de "ça dépend" pour moi car rien dans le code ne permet de savoir qui est responsable du contenu à l'adresse "a". Est-ce "a" ? Est-ce "*b" ?
Il n'y a pas de "ça dépend" pour moi car rien dans le code ne permet de savoir qui est responsable du contenu à l'adresse "a". Est-ce "a" ? Est-ce "*b" ?
Je crois plutôt que la reṕonse de koala01 avait une visée humoristique. 3 lignes de codes sans contexte ne disent pas grand chose en soi ;-).
C'était surtout pour dire que, bien que l'on puisse craindre une fuite mémoire à la vue de ces trois lignes de code, comme on n'a aucune informations sur ce que font B et C, on ne peut pas dire qu'il y en aura d'office une .
Les deux codes que je présente démontrent en effet que, à part pour C (qui sera récupéré par le système), il pourrait n'y avoir de fuite mémoire ni sur A ni sur B (bien que la fuite mémoire sur C les ferait arriver "en cascade" :P)
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Code parfaitement valide et sans fuite memoire
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.