After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645689 - Issues with "no uniquely matching class member found"
Issues with "no uniquely matching class member found"
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: build
1.7.3
Other Linux
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2011-03-25 22:42 UTC by Leo Carreon
Modified: 2011-04-09 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Leo Carreon 2011-03-25 22:42:33 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.
Comment 1 Dimitri van Heesch 2011-03-25 23:03:51 UTC
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.
Comment 2 Dimitri van Heesch 2011-03-25 23:07:45 UTC
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.
Comment 3 Leo Carreon 2011-03-26 04:49:29 UTC
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.
Comment 4 Leo Carreon 2011-03-26 05:00:04 UTC
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.
Comment 5 Leo Carreon 2011-03-27 00:48:44 UTC
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.
Comment 6 Dimitri van Heesch 2011-03-27 09:10:32 UTC
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.
Comment 7 Leo Carreon 2011-03-27 21:49:10 UTC
FYI, I removed the #define's for the namespaces and all the problems that I was encountering went away.
Comment 8 Akhil Laddha 2011-04-08 04:41:52 UTC
Shall we close the bug ?
Comment 9 Leo Carreon 2011-04-08 06:18:16 UTC
OK, you may close the bug.
Comment 10 Dimitri van Heesch 2011-04-09 14:58:39 UTC
Closing on request.