GNOME Bugzilla – Bug 645689
Issues with "no uniquely matching class member found"
Last modified: 2011-04-09 14:58:39 UTC
Please note that I'm using the latest update of doxygen for Fedora 14. It appears that doxygen is having difficulty matching class members when default argument initializers are involved. Here's an example of the warning messages that I'm getting on my files: /home/Leo/Devel/projects/datetime/library/src/cdateduration.cpp:27: warning: no uniquely matching class member found for LFC1_DATETIME_NS_BEGIN CDateDuration::CDateDuration(LFC1_NUMERIC_NS::TInt32 avDuration, enum EUnits avUnit) Possible candidates: lfc1::datetime::CDateDuration::CDateDuration(LFC1_NUMERIC_NS::TInt32 avDuration, enum EUnits avUnit=E_U_DAY) at line 140 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp lfc1::datetime::CDateDuration::CDateDuration(const CDateDuration &arRHS) at line 141 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp /home/Leo/Devel/projects/datetime/library/src/cdateget.cpp:33: warning: no uniquely matching class member found for CDateGet::CDateGet(size_t avRelease) Possible candidates: lfc1::datetime::CDateGet::CDateGet(size_t avRelease=0) at line 281 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp lfc1::datetime::CDateGet::CDateGet(const CDateGet &) at line 309 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp /home/Leo/Devel/projects/datetime/library/src/cdateno.cpp:30: warning: no uniquely matching class member found for LFC1_DATETIME_NS_BEGIN CDateNo::CDateNo(LFC1_NUMERIC_NS::TInt32 avDateNo) Possible candidates: lfc1::datetime::CDateNo::CDateNo(LFC1_NUMERIC_NS::TInt32 avDateNo=MIN_DATENO) at line 86 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp lfc1::datetime::CDateNo::CDateNo(int avYear, int avMonth, int avDay) at line 87 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp lfc1::datetime::CDateNo::CDateNo(const CDateNo &arRHS) at line 88 of file /home/Leo/Devel/projects/include/datetime/cdate.hpp Note that all warning messages of the same type above all involve default argument initializers thus my conclusion that this is possibly the cause of the messages.
Hi Leo, Please mention the version of doxygen you are using and attach a self-contained example (source+config file in a tar or zip) that allows me to reproduce the problem.
Note that I tried a simple example: --------------------------------------------------- namespace lfc1 { namespace datetime { class CDateGet { public: CDateGet(size_t avRelease=0); CDateGet(const CDateGet &); }; } } //------------------------------------- using namespace lfc1::datetime; CDateGet::CDateGet(size_t avRelease) { } CDateGet::CDateGet(const CDateGet &) { } --------------------------------------------------- But that worked fine.
I'm using #define's for the namespace names which are defined in include files used by my source code. Is doxygen able to resolve namespace names that use #define's? Just wondering if this is what is causing the problem.
The Doxygen version is 1.7.3. I will need to try and generate a cut down version of my project which exhibits the problem. This may take some time because my project is currently already large.
All of the classes in my project are coded in the following manner: datetime.hpp: ------------- #define LFC1_DATETIME_NS_BEGIN namespace lfc1 { namespace datetime #define LFC1_DATETIME_NS_END }} cdate.hpp: ---------- LFC1_DATETIME_NS_BEGIN class CDateGet { public: CDateGet(size_t avRelease=0); ~CDate(); }; LFC1_DATETIME_NS_END cdateget.cpp: ------------- LFC1_DATETIME_NS_BEGIN CDateGet(size_t avRelease) { } ~CDateGet() { } LFC1_DATETIME_NS_END My project already contains 6 libraries which follow the coding style above. There are no issues with the first 5 libraries. I have only encountered the problem I described on the last library. I tried replacing the uses of the #define's with their actual values in the first file which contained the issue and the problem went away. Unfortunately, this is not my desired solution because there is a good reason for using the #define's.
FYI: you can let doxygen ignore the macros by using its preprocessor, see http://www.doxygen.org/preprocessing.html But I don't think this is the real problem.
FYI, I removed the #define's for the namespaces and all the problems that I was encountering went away.
Shall we close the bug ?
OK, you may close the bug.
Closing on request.