Gestion des allocations mémoires

Bonjour,

Ma question concerne la gestion des allocations mémoires. Il s'agit plus d'une question concernant les méthodes que d'une question purement technique: disons que dans une fonction, je réalise de multiples allocations via new (std::nothrow). A chaque new, je teste si l'allocation a réussi. Du coup, je me retrouve avec pleins de if imbriqués les uns dans les autres, comme ci dessous:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

int *a = NULL; int *b = NULL; int *c = NULL; a = new (std::nothrow) int; if(a) { b = new (std::nothrow) int; if(b) { c = new (std::nothrow) int; if(c) { /* ... */ } } }

---

Par curiosité, je me demandais si il existait une méthode de programmation pour la gestion des new, qui diffère de la précédente.

Cordialement,

Julien.

Oui, la bonne méthode est de ne rien tester.

Si tu en es au point ou tu dois tester les new (qui dans la plupart des implémentations vont lancer une exception de toutes façons), alors c'est que soit ton programme est trop gros pour ton hardware, soit ton hardware est trop gros pour ton programme.

Ne test pas les new. Si un new rate, ça va te crasher rapidement à la gueule :aie:

Et ça sera pas à la gueule du client, donc tu peux corriger le problème en amont.

C'est juste absurde (et non-recommandé par ces messieurs du standard) de vérifier les new.

Salut,

Donc tu sous-entends que le new ne crash jamais si il a suffisamment d'espace mémoire pour allouer l'objet ? Contrairement au malloc qui lui crasherait également pour d'autres raisons (puisque le test est préconisé pour le malloc) ?

Julien.

Je précise tout de même que je suis dans un contexte "système embarqué".

Julien.

Pourquoi tu passes par les versions nothrow ? Les versions normales qui lancent une exception si l'allocation échoue ne te conviennent pas ? Parce que là tu te retrouves en effet à devoir tester tout tes new (donc à devoir faire comme en C).

Alors il s'agit d'une règle de codage de l'entreprise, les exceptions sont interdites. Mais peu importe, si le new vous gène, remplaçons l'exemple précédent par du malloc. Les if imbriqués dans l'exemple précédent ne vous "choque" donc pas ?

Cordialement,

Julien.

Code:

---

1 2 3 4 5 6 7 8 9 10

int *a = nullptr; // plus mieux int *b = nullptr; int *c = nullptr; a = new (std::nothrow) int; if(!a) return; b = new (std::nothrow) int; if(!b) return; c = new (std::nothrow) int; if(!c) return; /* ... */

---

Citation:

---

Envoyé par Khan34

Salut,

Donc tu sous-entends que le new ne crash jamais si il a suffisamment d'espace mémoire pour allouer l'objet ? Contrairement au malloc qui lui crasherait également pour d'autres raisons (puisque le test est préconisé pour le malloc) ?

Julien.

---

Non, le new echouera (tout comme malloc) si le systeme (OS ou pas) ne peut pas allouer l espace demande au moment demande, quelle que soit la raison.

Si tu alloues un objet tres tres tres gros alors peut etre qu il y a un interet a verifier les new, mais ce n est pas la norme, c est une exception (sans jeu de mot).

La plupart du temps si ton new echoue, tu ne peux rien faire d autre que quitter l application ou ne rien faire du tout, ce qui reviens globalement a la meme chose. Dans tous les cas, par defaut, ne test pas les new, c est inutile.


Si tu as un cas bien specifique ou tester le new a du sens, lache toi, sinon ce n est pas necesaire.

En fait tout depends du context de l appel.

Ok, merci pour toutes ces réponses.

Julien.

@Klaim: Je suis d'accord qu'on ne peut rien faire, mais si on test pas le retour des versions nothrow on se retrouve à déréférencer des pointeurs nuls.

Citation:

---

Envoyé par Flob90

@Klaim: Je suis d'accord qu'on ne peut rien faire, mais si on test pas le retour des versions nothrow on se retrouve à déréférencer des pointeurs nuls.

---

J ai dit "la plupart du temps". Les cas ou ca deviens utile de faire quelque chose sont rare et reserves a des contextes extremes ou critique ( au sens ou des vies sont en jeu ). Dans les autres cas, ca n a aucun sens et on arrive a rien de reellement utile. Meme faire un log peut faire cracher l application a ce point la.