Étant donné que le journal pose la question, je suppose qu'il cherche une solution...
Pas vraiment en fait, c’était plus un journal « exploratoire ». Présenter le problème et quelques-unes des solutions possibles, et voir ce que les autres programmeurs du coin ont à dire.
Au passage, une précision : comme le journal est construit (en gros 1 on peut gérer gracieusement les erreurs d’allocation, 2 mais c’est compliqué, 3 on peut aussi juste terminer en cas d’erreur vu que de toute façon avec un système à genoux on ne peut pas faire grand’chose), il donne peut-être l’impression que je recommande la terminaison immédiate sur erreur, ou que je considère ça comme « la bonne solution ».
Ce n’était pas mon intention. J’adopte généralement la méthode du « wrapper qui tue » dans mes programmes, parce qu’ils rentrent à fond dans la catégorie des programmes non-interactifs qu’on lance, font ce qu’ils ont à faire (ce qui typiquement prend un dixième de seconde), et terminent en rendant la main à l’utilisateur — le genre de programmes où il n’y guère d’intérêt à mon sens à essayer à tout prix de « gérer gracieusement » le manque de mémoire. Mais je ne veux surtout pas prétendre que c’est la bonne approche applicable à tous les cas de figure.
Au contraire, si je devais recommander quoi que ce soit, ce ne serait pas une méthode ou une autre, mais plutôt le fait de se poser quelques questions au début du développement (de quel type de programme s’agit-il ? quel devrait être, typiquement, le volume de données qu’il va manipuler ? est-ce un logiciel serveur supposé tourner indéfiniment, ou au contraire un programme à durée d’exécution limitée ? etc.) et de choisir la méthode de gestion du manque de mémoire en conséquence.
[^] # Re: Mélange des deux
Posté par gouttegd . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
Pas vraiment en fait, c’était plus un journal « exploratoire ». Présenter le problème et quelques-unes des solutions possibles, et voir ce que les autres programmeurs du coin ont à dire.
Au passage, une précision : comme le journal est construit (en gros 1 on peut gérer gracieusement les erreurs d’allocation, 2 mais c’est compliqué, 3 on peut aussi juste terminer en cas d’erreur vu que de toute façon avec un système à genoux on ne peut pas faire grand’chose), il donne peut-être l’impression que je recommande la terminaison immédiate sur erreur, ou que je considère ça comme « la bonne solution ».
Ce n’était pas mon intention. J’adopte généralement la méthode du « wrapper qui tue » dans mes programmes, parce qu’ils rentrent à fond dans la catégorie des programmes non-interactifs qu’on lance, font ce qu’ils ont à faire (ce qui typiquement prend un dixième de seconde), et terminent en rendant la main à l’utilisateur — le genre de programmes où il n’y guère d’intérêt à mon sens à essayer à tout prix de « gérer gracieusement » le manque de mémoire. Mais je ne veux surtout pas prétendre que c’est la bonne approche applicable à tous les cas de figure.
Au contraire, si je devais recommander quoi que ce soit, ce ne serait pas une méthode ou une autre, mais plutôt le fait de se poser quelques questions au début du développement (de quel type de programme s’agit-il ? quel devrait être, typiquement, le volume de données qu’il va manipuler ? est-ce un logiciel serveur supposé tourner indéfiniment, ou au contraire un programme à durée d’exécution limitée ? etc.) et de choisir la méthode de gestion du manque de mémoire en conséquence.