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 488125 - operator->* is not dealt with correctly
operator->* is not dealt with correctly
Status: VERIFIED FIXED
Product: doxygen
Classification: Other
Component: general
1.5.3
Other All
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2007-10-19 02:47 UTC by Wu Yongwei
Modified: 2013-09-05 13:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A minimal test case (109.05 KB, application/x-compressed-tar)
2008-02-14 09:21 UTC, Wu Yongwei
Details

Description Wu Yongwei 2007-10-19 02:47:58 UTC
Please describe the problem:
"->*" is an operator in C++.  However, in Doxygen-generated documentation, a space is inserted between "->" and "*", making the appearance wrong.

Steps to reproduce:
1. Define operator->* for a class in a cpp file
2. Add the cpp file to Doxyfile
3. Run doxygen

Actual results:
In the HTML output, there is a space between "->" and "*"; and in the LaTeX output, there is a space between the rightarrow and "*".  As can be seen in http://nvwa.sourceforge.net/doc/0.8/class____debug__new__recorder.html and http://nvwa.sourceforge.net/doc/0.8/refman.pdf (p. 9, 13 of 78).

Expected results:
"->*" is a C++ operator, and it should not be separated.

Does this happen every time?
Yes.

Other information:
Comment 1 Vishrut Chokshi 2008-01-09 23:12:51 UTC
I am having the same error. I have method operator*(……) defined and doxygen gives operator *(……). It is a bug and there should not be any space in between operator and *.
Comment 2 Vishrut Chokshi 2008-01-09 23:16:01 UTC
Ditto for any operator method with *. I.e. *=
Doxygen adds space in between *= and operator
Comment 3 Dimitri van Heesch 2008-01-19 15:59:32 UTC
Confirmed. Should be fixed in the next subversion update.
Comment 4 Dimitri van Heesch 2008-02-10 13:03:22 UTC
This bug was marked assigned, which means to should be fixed in version 1.5.5 of doxygen. Please verify if this is indeed the case, and if not, reopen the bug and provide additional information if possible.
Comment 5 Wu Yongwei 2008-02-14 09:21:42 UTC
Created attachment 105212 [details]
A minimal test case

This is a minimal test case for the bug, along with HTML and LaTeX/PDF results generated.
Comment 6 Wu Yongwei 2008-02-16 11:22:05 UTC
Test report on the test case attached.

In the HTML output of 1.5.3, the link text in
the reference is the correct "Deriv::operator->*", but there is a
space between -> and * in other places.  Similarly, in the LaTeX
output of 1.5.3, it is "Deriv::operator right-arrow *" everywhere.

In the HTML output of 1.5.5, the space between -> and * disappears
everywhere.  However, the link in the reference also disappears.  It
is true not only for operator->*, but also for any operator->,
operator*, etc.

In the LaTeX output of 1.5.5, the link also disappears, and the text
is the normal "Deriv::operator->*", without the right-arrow.  The
other things are similar to 1.5.3.  The big difference is that the DOT
graphs are gone, while they are correct in 1.5.3 and 1.5.1.  They
still work when PDFLaTeX is NOT used, but the font used in the graphs
is not FreeSans as in the older versions.  There are no error
messages then, but I do see error messages when running 1.5.5 for the
first time with PDFLaTeX:

Error: /invalidfont in /findfont
Operand stack:
  --nostringval--   10.0   FreeSans
Execution stack:
  %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   --nostringval--   false   1   %stopped_push   1889
1   3   %oparray_pop   1888   1   3   %oparray_pop   1872   1   3
%oparray_pop   1755   1   3   %oparray_pop   --nostringval--
%errorexec_pop   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   1847   3   4   %oparray_pop
Dictionary stack:
  --dict:1147/1684(ro)(G)--   --dict:0/20(G)--   --dict:71/200(L)--
--dict:36/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
MiKTeX GPL Ghostscript 8.60: Unrecoverable error, exit code 1

So I would say the minor bug seems gone, but more serious problems,
(link problems and DOT problems) appear in the new version 1.5.5.

I use the doxygen.exe in doxygen-1.5.x.windows.bin.zip, MiKTeX 2.5,
and Cygwin bash (for running make to get the LaTeX PDF output).
Comment 7 Dimitri van Heesch 2008-02-16 13:08:51 UTC
The linking problem can be solved using Deriv::operator->*()
(so include the extra braces to signal it is a method)

I'll make the pattern matching rules a bit less strict so that also the version with :: but without () will be found.

As for the pdflatex issue. Did you run it from a clean directory? (I experienced that switching from a hyperlinks on/off without clearing the latex output directory first can cause issues). If you did then I would like to know which version of dot you are using... 

Doxygen still uses FreeSans.ttf but references in dot files no exclude the .ttf part (which caused problems with newer versions of dot on some systems...)
Comment 8 Wu Yongwei 2008-02-17 13:33:03 UTC
Yes, I tried running it from a clean directory. I use Graphviz 2.8.  Newer versions did not work in the past (possibly because of the problem you described).  I tried the different Graphviz versions one by one, and found the last version that worked was 2.8.  My comments in the build script showed MiKTeX 2.5, Doxygen 1.5.1, and Graphiz 2.8 worked together.

Do you recommend using the latest version of DOT now?  Does DOT support version conditionals?
Comment 9 Wu Yongwei 2008-06-04 12:58:55 UTC
Hi Dimitri,

I tried doxygen 1.5.6, dot 2.18, and MiKTeX 2.5 on a clean directory. I can confirm that these problems are gone (in HTML):

* Space between "->" and "*" in "->*"
* No link under "Obj::operator->*"

However, There are still errors with PDFLaTeX. The first error for the test case is (others are similar):

Generating docs for file test.cpp...
Error: /invalidfont in /findfont
Operand stack:
   --nostringval--   --nostringval--   Helvetica   Helvetica   Helvetica
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1889   1   3   %oparray_pop   1888   1   3   %oparray_pop   1872   1   3   %oparray_pop   1755   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   1847   5   4   %oparray_pop
Dictionary stack:
   --dict:1147/1684(ro)(G)--   --dict:0/20(G)--   --dict:71/200(L)--   --dict:38/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
MiKTeX GPL Ghostscript 8.60: Unrecoverable error, exit code 1

If I go into the latex directory and make refman.pdf:

* There is still the rightarrow instead of "->"
* There is still space between rightarrow and "*"
* No graphs are generated

I can work around the first problem by sed'ing the .tex files, but I do not know any workarounds for the last problem.

When not using PDFLaTeX, the graphs are at least there, though the font of the graph is ugly (not FreeSans or any sans-serif fonts).

So it seems the latest version of doxygen/dot works well for HTML output. However, for LaTeX output on Windows, the best combination I can find is still doxygen 1.5.1 and dot 2.8.
Comment 10 albert 2013-06-01 11:09:11 UTC
Tried to test this with version 1.8.4 but got into an endless loop. bug_701295 has been submitted for this and this has been fixed in the meantime in the git version.
Testing this bug against the git version reveals that the problem is solved. Also testing against version 1.8.31 reveals that the problem is solved.

See the problem with the version 1.8.4 and the fix in the git version I think the best is to set the bug to ASSIGNED.
Comment 11 Dimitri van Heesch 2013-08-23 15:04:23 UTC
This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.5. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant.
Comment 12 Wu Yongwei 2013-09-05 13:39:26 UTC
Verified and working.