Je vois pas pourquoi tu imagines que les utilisateurs de "langages modernes" peuvent se passer de ce genre de considération. Que fera la jvm (par exemple) si elle exécute un algo qui a besoin d'allouer 1 To si la machine peut pas lui fournir ? C'est pas une question rhétorique d'ailleurs, j'en sais rien, mais ce que je sais ce qu'elle fait pas de magie, donc elle y arrivera pas.
Personnellement, dans mes softs (c++), je ne capture pas std::bac_alloc. Le prof qui m'a enseigné C++ disait à tort ou à raison que c'était inutile, parce si cette exception était déclenchée, on pouvait plus faire grand chose qui est un sens. Juste créer la std::string qui va contenir le message à destination de l'utilisateur risque fortement d'échouer par exemple (selon l'implémentation et l'espace restant par exemple) Quelques (trop ;p) années plus tard, je sais que cette affirmation doit être nuancée, mais dans mon cas précis (développement de softs dits "de gestion") elle reste vraie je trouve : les algos que j'écris ne doivent pas la déclencher, tout simplement parce qu'ils ne doivent utiliser que des quantités ridicules de mémoire. Imaginez je ne sais pas moi un crm. Si un std::bad_alloc est déclenché sur une machine moderne avec plusieurs Go de RAM, c'est qu'il y a un gros problème de conception. Faut pas chercher comment capturer et repartir, faut surtout chercher les fuites.
J'imagine que les avis vont être différents sur ce journal. Les types qui développent par exemple des outils de calcul dans la recherche vont peut-être avoir besoin d'allouer des Go, et captureront std::bad_alloc. Les types qui écrivent des applis de gestions (qui en général délèguent les opérations coûteuses à un SGBDR) ne s'en soucieront sûrement pas.
Ceci dit, je trouve ce journal très intéressant, car même si dans mes softs je ne m'en soucie pas (par pragmatisme), il y a toujours ce petit truc qui gratte. Je préférerai bien évidemment qu'ils marchent coûte que coûte.
Dernière chose, je vais quand même décrire une technique que j'utilise depuis quelques années pour résoudre une partie du problème : j'utilise le RAII au maximum. Une classe qui va allouer le fera dans son constructeur. Si ça échoue, un std::bad_alloc va donc être déclencher. Vu que j'utilise le RAII, je m'attends déjà à ce que le constructeur échoue et le code appelant capture déjà les exceptions, donc si jamais std::bad_alloc était déclenchée elle serait capturée par le niveau du dessus qui gère déjà l'échec de la construction. Je pense donc que même un std::bad_alloc serait géré proprement, même si c'est pas garanti (pas impossible que le code du catch alloue des trucs et du coup relance un std::bad_alloc).
A vrai dire et en conclusion, mes softs sont utilisés un peu partout en France depuis 10 ans par des centaines ou des milliers de gens, si des std::bad_alloc avaient été déclenchés, je serai déjà au courant et on m'aurait demandé de trouver une solution. Ce n'est pas le cas.
# Langages modernes
Posté par guppy . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 10.
Je vois pas pourquoi tu imagines que les utilisateurs de "langages modernes" peuvent se passer de ce genre de considération. Que fera la jvm (par exemple) si elle exécute un algo qui a besoin d'allouer 1 To si la machine peut pas lui fournir ? C'est pas une question rhétorique d'ailleurs, j'en sais rien, mais ce que je sais ce qu'elle fait pas de magie, donc elle y arrivera pas.
Personnellement, dans mes softs (c++), je ne capture pas std::bac_alloc. Le prof qui m'a enseigné C++ disait à tort ou à raison que c'était inutile, parce si cette exception était déclenchée, on pouvait plus faire grand chose qui est un sens. Juste créer la std::string qui va contenir le message à destination de l'utilisateur risque fortement d'échouer par exemple (selon l'implémentation et l'espace restant par exemple) Quelques (trop ;p) années plus tard, je sais que cette affirmation doit être nuancée, mais dans mon cas précis (développement de softs dits "de gestion") elle reste vraie je trouve : les algos que j'écris ne doivent pas la déclencher, tout simplement parce qu'ils ne doivent utiliser que des quantités ridicules de mémoire. Imaginez je ne sais pas moi un crm. Si un std::bad_alloc est déclenché sur une machine moderne avec plusieurs Go de RAM, c'est qu'il y a un gros problème de conception. Faut pas chercher comment capturer et repartir, faut surtout chercher les fuites.
J'imagine que les avis vont être différents sur ce journal. Les types qui développent par exemple des outils de calcul dans la recherche vont peut-être avoir besoin d'allouer des Go, et captureront std::bad_alloc. Les types qui écrivent des applis de gestions (qui en général délèguent les opérations coûteuses à un SGBDR) ne s'en soucieront sûrement pas.
Ceci dit, je trouve ce journal très intéressant, car même si dans mes softs je ne m'en soucie pas (par pragmatisme), il y a toujours ce petit truc qui gratte. Je préférerai bien évidemment qu'ils marchent coûte que coûte.
Dernière chose, je vais quand même décrire une technique que j'utilise depuis quelques années pour résoudre une partie du problème : j'utilise le RAII au maximum. Une classe qui va allouer le fera dans son constructeur. Si ça échoue, un std::bad_alloc va donc être déclencher. Vu que j'utilise le RAII, je m'attends déjà à ce que le constructeur échoue et le code appelant capture déjà les exceptions, donc si jamais std::bad_alloc était déclenchée elle serait capturée par le niveau du dessus qui gère déjà l'échec de la construction. Je pense donc que même un std::bad_alloc serait géré proprement, même si c'est pas garanti (pas impossible que le code du catch alloue des trucs et du coup relance un std::bad_alloc).
A vrai dire et en conclusion, mes softs sont utilisés un peu partout en France depuis 10 ans par des centaines ou des milliers de gens, si des std::bad_alloc avaient été déclenchés, je serai déjà au courant et on m'aurait demandé de trouver une solution. Ce n'est pas le cas.