c++ - use file or class for documenting classes in doxygen? -

this surely noob question, can't find answer in doxygen documentation. i'm not sure whether using:

@file

or

@class

when documenting header files.

the reason if put file, comments appear in files tab only, not in classes tab (per each).

for cpp it's ok, use file , it's good, if use both file , class in header (file @ beginning , class right before start of class declaration) duplicated entries class in generated documentation...

what i'm doing wrong? suggestions? ideas?

regards, alex

edit: run new problem now. in order avoid circular dependecies declare class twice in header file (probably not best way avoid circular dependencies works me), instance:

#ifndef eu_sofia_kpi_common_abstractthread_decl #define eu_sofia_kpi_common_abstractthread_decl  namespace eu_sofia_kpi_common {     class kpi_cpp_api abstractthread; }  #define eu_sofia_kpi_common_abstractthread_decl_end #endif eu_sofia_kpi_common_abstractthread_decl  #ifdef eu_sofia_kpi_common_abstractthread_decl_end #ifndef eu_sofia_kpi_common_abstractthread_def #define eu_sofia_kpi_common_abstractthread_def  namespace eu_sofia_kpi_common {      class kpi_cpp_api abstractthread     {      public:         abstractthread();         virtual ~abstractthread();         ///start method, derived classes must implement method initialize boost::shared_ptr<boost::thread> pointer member object         virtual int start() = 0;         //stop method         virtual void stop() = 0;      protected:         ///pointer boost thread inherited , children classes must use in implementation of start , stop methods         boost::shared_ptr<boost::thread> m_thread;     };  }  #endif eu_sofia_kpi_common_abstractthread_def #endif eu_sofia_kpi_common_abstractthread_decl_end 

as can see, have forward declaration prior "real" declaration. if use @class, doxygen complains inconsystency issues related class, although generates documentation class. guess surrounded #ifdef or #ifndef doxygen not seem much...

i use neither, unless want specify alternate include path or that. looks this:

/// tunables loader. /** class contains set of functions loading tunables  * file. need 1 quatunablesloader object in  * program. once work done, can safely destroy it.  *   * ... blah, blah, blah ...  * */ class quatunablesloader { 

this equivalent using @class, answer question yes, should use @class when documenting classes. if header file doesn't contain else, shouldn't document @ all, documentation "this file contains declaration of class someclass" anyway. if file contains more, friend functions, should document file (obviously, using @file), possibly providing reference class.