Est-ce que cette abuse macro?

Si la macro est dans un fichier source et utilisée uniquement dans ce fichier, je le trouve un peu moins offensant que si elle est désactivée dans une en-tête quelque part. Mais je n'aime pas beaucoup une macro qui revient, (surtout une documentée em> pour mettre fin à l'application et revenir en réalité), et toujours moins celle qui revient conditionnellement, car elle le rend assez facile à créer La fuite de mémoire suivante: xxx pré>

Si je crois que la documentation, je n'ai aucun motif de suspecter que ce code fuit la mémoire chaque fois que la lecture échoue. Même si la documentation était correcte, je préfère que le flux de contrôle dans C soit éventuellement évident, ce qui signifie pas caché par les macros. Je préférerais également que mon code soit vaguement cohérent entre les cas où j'ai des ressources pour nettoyer et étudier où je ne le fais pas, plutôt que d'utiliser la macro pour un mais pas l'autre. Donc, la macro n'est pas à mon goût même si ce n'est pas définitivement abusif. P>

faire ce que dit la documentation, je préférerais écrire quelque chose comme: p> xxx pré>

avec vérifier code> être une fonction. Ou utilisez un affirmer code>. Bien sûr, une affirmation ne fait que quelque chose si NDEBUG n'est pas défini, il n'est donc pas bon de la manipulation des erreurs si vous planifiez des constructions distinctes de débogage et de libération. P>

faire ce que la macro fait réellement, je voudrais Préfère ignorer la macro entièrement et écrire: p>

if (retval == -1) return DCD_BADREAD;

Je suis sur la clôture de savoir s'il faut appeler une telle macro * abus *, mais je dirai que ce n'est pas une bonne idée.

Je dirais que en général, vous devriez éviter d'utiliser retour dans une macro. Il est difficile de créer une macro qui gère le retour correctement sans effectuer le flux de contrôle de la fonction qui l'appelle maladroit ou difficile à comprendre. Vous ne voulez certainement pas "accidentellement" de retourner d'une fonction sans le réaliser. Celui-ci peut être ennuyeux de déboguer.

plus, cette macro peut causer des problèmes avec le flux de code en fonction de la manière dont il est utilisé. Par exemple, le code xxx

ne ferait pas ce que vous penseriez que ce serait (le sinon devient associé au si à l'intérieur de la macro). La macro doit être clôturée dans {} pour vous assurer qu'il ne modifie pas de conditionnels environnants.

En outre, le deuxième argument n'est pas utilisé. Le problème évident ici est la mise en œuvre ne correspondant pas à la documentation. Le problème caché est lorsque la macro est invoquée comme ceci: xxx

Vous vous attendez à ce que le pointeur passe à l'élément de tableau suivant après l'appel de la macro. Cependant, le deuxième paramètre n'est pas utilisé, l'incrément n'arrive jamais. C'est une autre raison pour laquelle les déclarations avec des effets secondaires causent des problèmes dans les macros.

au lieu d'utiliser une macro pour faire tout cela, pourquoi ne pas écrire une fonction pour encapsuler le lire et L'erreur vérifie? Il peut retourner zéro sur le succès ou un code d'erreur. Si le code de traitement des erreurs est commun entre tous les blocs lisez , vous pouvez faire quelque chose comme ceci: xxx

aussi longtemps que tout votre Appels vers Read_Helper Attribuer leur valeur de retour à RET , vous pouvez réutiliser le même bloc de code de traitement des erreurs dans toute la fonction. Votre fonction print_error_message_for_code prendrait simplement un code d'erreur comme entrée et utilisez un commutateur ou un tableau pour imprimer un message d'erreur qui correspond à celui-ci.

J'avoue que beaucoup de gens ont peur de goto , mais réutilisant le code de traitement des erreurs courantes au lieu d'une série de blocs imbriqués et de variables de condition peuvent être un cas d'utilisation approprié pour celui-ci. Il suffit de le garder propre et lisible (une étiquette par fonction, et conservez le code de manipulation d'erreur simple).