Comment puis-je garder doxygen, de documenter #définit dans un fichier C?

J'ai #define valeurs dans les en-têtes que je veux certainement Doxygen pour document mais j'ai d'autres dans C fichiers que je les traiter comme des constantes statiques et je ne veux pas de Doxygen pour les documenter. Quelque chose d'aussi simple et stupide que de

#define NUMBER_OF(a) (sizeof((a))/sizeof((a)[0]))
#define MSTR(e) #e

Comment puis-je garder Doxygen de mettre les #defines dans la documentation qu'il crée? J'ai essayé de le marquer avec @internal mais cela ne semble pas aider.

Un peu liés à la question sur Doxygen et #define, comment puis-je obtenir:

#define SOME_CONSTANT 1234 /**< An explanation */

de mettre "SOME_CONSTANT" et "explication", mais pas "1234" dans la sortie?

OriginalL'auteur Chris Nelson | 2009-11-04

  1. 3

    Vous pouvez exclure une partie de code à partir de Doxygen analyse avec \cond ... \endcond balises.

    edit: Certaines questions connexes:

    Je suppose que les adresses des #define .c problème de fichier (je peux entourent ces lignes avec conditionnelle de contrôle). Il semble bruyant et contre nature. Et n'est pas du tout le masquage d'adresse de valeurs pour les #define avais constantes. (Peut-être que je ne devrais pas avoir demandé un composé question, mais je l'espère, il y avait des #define spécifique des choses qui pourraient répondre à deux questions.)
    Je ne sais pas comment faire pour afficher une définition de la constante, sans révéler sa valeur.
    J'ai cond/endcond de travail, mais je voudrais vraiment savoir pourquoi interne ne fonctionne pas. Mon doxygen fu est certainement faible. 🙁
    Malheureusement, je partage votre incompréhension de @internes. De nombreux aspects de Doxygen sont encore obscures pour moi. La courbe d'apprentissage est lent, mais en vaut la peine.

    OriginalL'auteur mouviciel

  2. 9

    Il n'est pas nécessaire d'utiliser le \cond et \endcond commandes. Vous pouvez masquer l'initialiseur, simplement à l'aide de la \hideinitializer commande:

    #define SOME_CONSTANT 1234 /**< An explanation @hideinitializer */

    Concernant la première question, vous pouvez définir HIDE_UNDOC_MEMBERS = YES et seules les macros d'avoir une documentation Doxygen bloc sera affiché dans la sortie.

    OriginalL'auteur bszente

  3. 4

    Vous pouvez définir MAX_INITIALIZER_LINES = 0 dans votre doxyfile pour masquer les valeurs de votre définit.

    OriginalL'auteur emp

  4. 1

    Ce sera sans doute encore sembler bruyant et contre nature, mais pour répondre à votre autre question, essayez:

    /** An explanation */
#define SOME_CONSTANT /** @cond */ 1234 /** @endcond */

    OriginalL'auteur Ben Hocking

  5. 1

    Vous voulez seulement de documenter ce qui est déclaré dans le .h fichiers. Je suis en supposant que vous déclarez toutes les fonctions statiques et variables comme static dans votre .c fichiers. Tous les autres sont déclarés dans .h fichiers correspondants. Ce sont vos "public" des membres.

    Ce que j'aime faire dans ce cas, et je crois que doxygen était plus conçu pour être utilisé de cette façon est:

    • dans votre Doxyfile, ensemble EXTRACT_ALL = NO et ajouter le répertoire où votre .h fichiers sont à
    • ajouter /** \fichier */ pour tous vos .h fichiers (mais pas votre .c fichiers).

    Ce sera l'indice que ce qui est contenu dans votre .h fichiers. Vous pouvez toujours ajouter le répertoire contenant votre .c fichiers INPUT à votre Doxyfile, et ils vont être analysés à la recherche de la documentation supplémentaire pour votre "public"...

    OriginalL'auteur ericbn

  6. 0

    J'ai résolu ce problème en déplaçant ma documentation de l' .c dossier à la .h fichier. Ensuite, exécutez doxygen uniquement sur le .h fichier.

    Puis les éléments que j'ai envie de document (le "public" éléments) sont intrinsèquement ce que doxygen ramasse.

    Parce que j'ai déjà été prudent de mettre "public" des éléments dans le .h fichier et "privé" des éléments dans le .c fichier, cela fonctionne très bien.

    Cette technique est venu à l'esprit quand j'ai remarqué que doxygen tirait dans les inclut. Il m'a frappé que si je ont été également déplacer le sous-ensemble de comprend que le module appelant aurait besoin d'utiliser mon module, alors que la liste devrait être documentée.

    Cette technique a un avantage supplémentaire: je peux mettre de la documentation dans une fenêtre de terminal et de la source dans une autre fenêtre de terminal, tandis que la mise à jour de la documentation.

    OriginalL'auteur Michael Potter

  7. 0

    Parfois vous pouvez avoir une définition qui vous veulent du document, mais que vous voulez de doxygen pour traiter différemment (ou même l'ignorer complètement pour éviter les erreurs d'analyse).
    Pour cela, vous pouvez définir le #define dans doxygen différemment que dans votre code source.

    Exemple:
    Certains compilateurs permettent variable de liaison à des segments spécifiques, à savoir:

    const int myvar @ "segment_of_myvar_in_memory"=123;

    => doxygen serait d'analyser la "segment_of_myvar_in_memory" partie comme nom de variable qui n'est pas souhaité.
    Nous pourrions utiliser une définition:

    #define __link_to_segment(name) @ name
const int myvar __link_to_segment("segment_of_myvar_in_memory")=123;

    Si Prétraitement est active, Doxygen interprète de notre variable est maintenant comme une fonction de la cause de la fonction-comme les définir à l'aide de crochets..
    Mais si nous redéfinissons notre définir dans les Doxyfile, les changements de comportement:

    PREDEFINED = __link_to_segment(a)=

    maintenant la variable est correctement analysé comme variable également tous les types ou de mots clés avant sont correctement indiquées comme mots-clés.

    Un côté sympa effekt:
    Dans le cas où vous utilisez 2 différents IDEs avec votre code (un IDE pour compiler&débogage, pour l'édition), vous découvrirez également que certaines IDEs (c'est à dire de l'Éclipse) ont des problèmes d'analyse des variables avec @"nom de segment". L'utilisation de l'approche ci-dessus, vous pouvez redéfinir le __lien__segment(nom) il y a trop:

    #define __link_to_segment(name)

    c'est à dire de l'Éclipse sera alors de montrer et d'analyser les variables correctement, alors que le "compiler&débogage" IDE peuvent encore relier la variable par son nom de segment.

    OriginalL'auteur dominik liebaug