Discussion :

[denispir]

Du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Toto * tots = malloc (count * sizeof(Toto) ;
if (totos == NULL) {
    // et là, on fait quoi?
}

Au départ, j'ai mis des assert (totos != NULL), juste pour noter les endroits où je devrai plus tard faire quelque chose de plus sensé. C'est l'heure de m'occupper de ça, mais j'ai aucune idée de ce qui serait mieux. Au moins, l'assertion dit clairement quel est le problème et surtout où. A première vue, il me semble qu'un utilisateur ne peut rien faire de mieux que nous rapporter les faits et le message d'erreur. Alors, quoi?

Dans un langage même légèrement de plus haut niveau, on ne s'occupe tout simplement pas de ces choses-là. Ca ne se produit pas (?). Ce qui signifie que si, par ex en python, un objet ne peut pas être alloué, l'utilisateur se retrouve face à un message d'erreur C légèrement reformulé pas le runtime python (ce sera une MemoryError de python si mes souvenirs sont corrects) : ça lui fait une belle jambe, c'est tout aussi "impertinent" et ça le laisse tout autant impuissant.
J'aimerais bien trouver une stratégie sensée générale qui puisse s'appliquer à tous les cas où un défaut nous échappe, comme les relations avec le système de fichier ou les entrées-sorties en général.

note: Je ne parle pas ici des défauts qui font en fait (ou devraient faire) partie de la logique de l'application, par exemple un fichier de config n'est pas là : il doit là y avoir une voie de secours.

Denis

[kwariz]

Normalement tu ne peux rien y faire ... s'il n'y a plus de place, ben il n'y en a plus (à moins de pouvoir en faire toi-même et de prendre sur toi d'en libérer ailleurs). Tu peux éventuellement essayer une méthode qui requiert moins de mémoire en fallback, mais ce n'est pas très général (du genre lire pouis trier un tableau en mémoire, le tableau est trop grand pour tenir en mémoire, ton fallback : trier sur disque).
Du coup mise à part émettre un message plus ou moins pertinent puis quitter l'application tu ne peux rien faire.

EDIT: ah oui ... comme je l'avais déjà écrit assert ne doit pas être utilisé pour les erreurs runtime ... si tu veux un message avec le nom du fichier, la ligne ou le nom de la fonction il y a des macros pour ça.

[gerald3d]

Je suis d'accord avec kwariz. Soit tu as moyen de faire autrement, travailler sur disque par exemple, soit tu ne peux pas.
Dans le second cas ton application a la nécessité d'allouer cette mémoire. Si ce n'est pas possible tu affiche un message d'erreur sur le canal stderr et tu quittes l'application. De toute manière ton application ne peut plus fonctionner comme il faut.

[denispir]

Il é méchan ?

Ce n'est pas que je ne veux pas ne pas l'utiliser. Au contraire, chercher comment faire avec des macros qui vont bien me donnera l'occase de découvrir d'autres aspects du langage C.

Mais je voudrais comprendre pourquoi je ne dois pas l'utiliser. Si afficher un message d'erreur pertinent sur stderr est le mieux qu'on peut faire, alors assert ne fait-il cela justement très bien?
Le seul pb qui me vient à l'esprit, c'est que assert est peut-être réservé par convention aux tests. Dans ce cas, c'est gênant de le réutiliser ailleurs. Sinon, peut-être qu'il n'est pas compilé en mode release (il me semble avoir lu un truc comme ça qq part)?

Donc, à moins qu'il y ait mieux, je compte faire la chose suivante: chercher la def de la macro assert (c'est bien une macro?) dans la stdlib, la comprendre, la reproduire, et appleler le résultat verify...

Merci à vous,
Denis

[kwariz]

Non, mais assert est prévu pour ... les assertions (détecter les erreurs de conceptions/programmations en phase de dev), c'est pourquoi si tu (ou un autre) recompiles le programme en définissant NDEBUG tous tes assert ne feront plus rien (pas bien).
Un malloc qui plante n'est pas (toujours ) une erreur de programmation, mais une erreur runtime qui doit être traitée par ton propre handler au runtime.

Il n'est pas interdit d'utiliser assert comme tu fais, c'est très fortement non recommandé (après tout le monde est libre).

Il est tout aussi facile de se faire une macro/fonction utilisant un fprintf(stderr,...), __FILE__ __LINE__ sont standards __FUNC__ / __FUNCTION__ __PRETTYFUNCTION__ existent mais doivent dépendre d'une implémentation particulière je crois. *cf edit2


EDIT: j'y vais un peu fort avec les asserts car on peut évidemment les laisser en release ... mais cela peut créer de la confusion pour d'autres personnes qui reliraient ou maintiendraient ton code. Un des réflexes est souvent : on enlève les assert, le code sera un peu plus rapide et c'est pas grave car on a confiance au code qui a été testé ...

EDIT2: en fait c99 définit la macro __func__, gcc propose aussi __FUNCTION__ qui est l'identifiant de la fonction et __PRETTY_FUNCTION__ qui est la signature de la fonction.

EDIT3: jette un coup d'oeil sur <err.h> dans la gnulibc : http://www.gnu.org/software/libc/man...-Messages.html

[denispir]

Non, mais assert est prévu pour ... les assertions (détecter les erreurs de conceptions/programmations en phase de dev), c'est pourquoi si tu (ou un autre) recompiles le programme en définissant NDEBUG tous tes assert ne feront plus rien (pas bien).
Un malloc qui plante n'est pas (toujours ) une erreur de programmation, mais une erreur runtime qui doit être traitée par ton propre handler au runtime.

Il n'est pas interdit d'utiliser assert comme tu fais, c'est très fortement non recommandé (après tout le monde est libre).

Il est tout aussi facile de se faire une macro/fonction utilisant un fprintf(stderr,...), __FILE__ __LINE__ sont standards __FUNC__ / __FUNCTION__ __PRETTYFUNCTION__ existent mais doivent dépendre d'une implémentation particulière je crois. *cf edit2


EDIT: j'y vais un peu fort avec les asserts car on peut évidemment les laisser en release ... mais cela peut créer de la confusion pour d'autres personnes qui reliraient ou maintiendraient ton code. Un des réflexes est souvent : on enlève les assert, le code sera un peu plus rapide et c'est pas grave car on a confiance au code qui a été testé ...

EDIT2: en fait c99 définit la macro __func__, gcc propose aussi __FUNCTION__ qui est l'identifiant de la fonction et __PRETTY_FUNCTION__ qui est la signature de la fonction.

EDIT3: jette un coup d'oeil sur <err.h> dans la gnulibc : http://www.gnu.org/software/libc/man...-Messages.html

Oui, merci kwariz. Globalement, ce que tu dis là reflète ce que j'avais en tête. J'avais d'ailleurs déjà repéré ces macros-là (y compris d'ailleurs l'incertitude par rapport à __FUNCTION__ que tu évoques) pour me faire une macro de "vérification".
Denis