En ce qui concerne new VS malloc pour allouer une struct C, je n'ai pas vraiment d'avis ; tant que tu les utilises correctement, ça na va pas changer l'univers. new peut utiliser un autre allocateur que malloc mais tant que tu ne mélanges pas malloc/free avec new/delete sur le même objet, ça ira.
La spécification C++ dit que si new échoue à allouer de la mémoire, il émet une exception de type std::bad_alloc, du coup, il est inutile de tester le pointeur de retour envers nullptr.
Personnellement, je décourage l'utilisation d'une fonction public du genre init(). Ça laisse plus d'opportunités à l'utilisateur de la classe de se tirer une balle dans le pied. Je suis partisan d'insérer le code d'init dans le constructeur et de balancer une exception en cas d'erreur. Au moins l'utilisateur ne se retrouvera jamais avec un objet inutilisable.
si tu as testé le pointeur à la construction, le tester à la destruction est excessif.
tu peux probablement déléguer la gestion de ton pointeur à un pointeur intelligent tel que unique_ptr, en définissant le Deleter idoine.
# quelques éléments de réponse
Posté par nazcafan . En réponse au message classe C++, membre structure C et allocation dynamique. Évalué à 4. Dernière modification le 21 avril 2017 à 17:15.
newVSmallocpour allouer unestructC, je n'ai pas vraiment d'avis ; tant que tu les utilises correctement, ça na va pas changer l'univers.newpeut utiliser un autre allocateur quemallocmais tant que tu ne mélanges pasmalloc/freeavecnew/deletesur le même objet, ça ira.newéchoue à allouer de la mémoire, il émet une exception de typestd::bad_alloc, du coup, il est inutile de tester le pointeur de retour enversnullptr.publicdu genreinit(). Ça laisse plus d'opportunités à l'utilisateur de la classe de se tirer une balle dans le pied. Je suis partisan d'insérer le code d'initdans le constructeur et de balancer une exception en cas d'erreur. Au moins l'utilisateur ne se retrouvera jamais avec un objet inutilisable.Deleteridoine.