Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.
Pourquoi ? Parce que le comportement de malloc entre Linux et d'autres OS est diffèrent, et que si tu ne gères pas le cas, alors ton soft va exploser en vol sur d'autres plateformes.
Exemple tout simple : code qui est sensé être multiplateforme entre Windows et Linux, et le code fait une allocation de 256Kb.
256Kb c'est petit hein, c'est genre rien du tout.
Pourtant sur Windows, si ton soft tourne alors qu'un soft super vorace tourne en background, il pourrait tout à fait se retrouver dans la situation ou il n'y a effectivement pas 256Kb de mémoire dispo, car Windows ne tue pas les processus au hasard pour faire de la place. Ce pourrait être juste quelque secondes parce qu'un soft a décidé de faire une énorme allocation qu'il libère tout de suite après hein... et là malloc retournera NULL sous Windows, là ou Linux serait allé trouver un processus à tuer pour faire de la place.
Est-ce que laisser le soft exploser en vol parce qu'il n'y avait pas 256Kb de RAM dispo pendant qqe secondes est une bonne chose ? A mon avis non, c'est très mauvais.
Donc perso l'approche que j'utilises est la suivante :
J'ai un allocateur custom, qui ne retourne JAMAIS NULL pour les allocations plus petites qu'une certaine limite (genre 1Mb ou 4Mb, selon les besoins). Il se contente de ré-essayer avec une petite pause car le mode de pensée est que si le système n'a pas 1-4Mb de dispo, ce ne sera pas indéfiniment sinon le système entier est à plat.
Résultat, dans tout mon code, je n'ai des checks pour NULL que lorsque je sais que la taille allouée peut potentiellement être plus élevée. Dans les autres cas, mon allocateur prendra peut-être 30 secondes à retourner (mais c'est pas grave car si le système est à genoux niveau RAM, il ne ferait rien de toute facon), mais il ne retournera pas NULL.
L'avantage est que je n'ai pas besoin de me soucier de mettre des exception handlers pour la plupart de mes utilisations de STL, ou des NULL checks pour la plupart de mes allocations. Il n'y a qu'un très faible nombre de cas ou j'ai besoin de le faire, et l'approche permet au code de rester lisible et supporter plusieurs OS proprement.
# Approche hybride
Posté par pasBill pasGates . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 10. Dernière modification le 26 octobre 2016 à 21:48.
Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.
Pourquoi ? Parce que le comportement de malloc entre Linux et d'autres OS est diffèrent, et que si tu ne gères pas le cas, alors ton soft va exploser en vol sur d'autres plateformes.
Exemple tout simple : code qui est sensé être multiplateforme entre Windows et Linux, et le code fait une allocation de 256Kb.
256Kb c'est petit hein, c'est genre rien du tout.
Pourtant sur Windows, si ton soft tourne alors qu'un soft super vorace tourne en background, il pourrait tout à fait se retrouver dans la situation ou il n'y a effectivement pas 256Kb de mémoire dispo, car Windows ne tue pas les processus au hasard pour faire de la place. Ce pourrait être juste quelque secondes parce qu'un soft a décidé de faire une énorme allocation qu'il libère tout de suite après hein... et là malloc retournera NULL sous Windows, là ou Linux serait allé trouver un processus à tuer pour faire de la place.
Est-ce que laisser le soft exploser en vol parce qu'il n'y avait pas 256Kb de RAM dispo pendant qqe secondes est une bonne chose ? A mon avis non, c'est très mauvais.
Donc perso l'approche que j'utilises est la suivante :
J'ai un allocateur custom, qui ne retourne JAMAIS NULL pour les allocations plus petites qu'une certaine limite (genre 1Mb ou 4Mb, selon les besoins). Il se contente de ré-essayer avec une petite pause car le mode de pensée est que si le système n'a pas 1-4Mb de dispo, ce ne sera pas indéfiniment sinon le système entier est à plat.
Résultat, dans tout mon code, je n'ai des checks pour NULL que lorsque je sais que la taille allouée peut potentiellement être plus élevée. Dans les autres cas, mon allocateur prendra peut-être 30 secondes à retourner (mais c'est pas grave car si le système est à genoux niveau RAM, il ne ferait rien de toute facon), mais il ne retournera pas NULL.
L'avantage est que je n'ai pas besoin de me soucier de mettre des exception handlers pour la plupart de mes utilisations de STL, ou des NULL checks pour la plupart de mes allocations. Il n'y a qu'un très faible nombre de cas ou j'ai besoin de le faire, et l'approche permet au code de rester lisible et supporter plusieurs OS proprement.