# ================================================
# Issues file.
# ================================================
PAGE_TITLE: <font size=2><a href="../../index.html">ccdoc home page</a></font><br>Ccdoc Issues
PAGE_AUTHOR: Joe Linoff
PAGE_EMAIL: jdl@xilinx.com
PAGE_REVISION: $Revision: 1.34 $
PAGE_DATE: $Date: 2004/09/30 16:09:26 $
PAGE_DESC_BEGIN:
<hr noshade size=2>
This page keeps track of issues related to ccdoc as they come up.  If
you click the Summary link at the top of the page it will take you to
a summary page. If you click on the status types (such as OPEN) it
will take you to a page that lists only issues with that status.
<p>
The status field contains either CLOSED, FIXED or OPEN.
<p>
<ul>
<li><b>CLOSED</b> - This issue did not require a change to ccdoc.
<li><b>FIXED</b> - This issue was fixed in a release of ccdoc.
<li><b>OPEN</b> - This issue is pending.
</ul>
<p>
These pages were automatically created by a perl script called 
make_issues.pl that is freely available by clicking
 <a href="make_issues.pl">here</a> the input to the script is a text file.
PAGE_DESC_END:

# ================================================
ENTRY_ID: 0001
ENTRY_TITLE: The -rootfile switch parses relative names improperly.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/22
ENTRY_REPORTED_BEGIN:
Little bug: Switch '-rootfile': If there is no parh given, the first
letter of filename will missing from the HTML hrefs. Eg:
<br>
&nbsp;&nbsp;&nbsp;&nbsp;'-rootfile index.html' =&gt; '&lt;a href='ndex.html'&gt;@root&lt;/a&gt;' ('i' missing)
<br>
but
<br>
&nbsp;&nbsp;&nbsp;&nbsp;'-rootfile ./index.html' =&gt; '&lt;a href='index.html'&gt;@root&lt;/a&gt;'
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Found a problem in make_file_url. The separator iterator was being
incremented when the path was completely relative.
<h4>Broken Code: phase3_html.c:1845</h4>
<pre>
  // ================================================================
  // Make file URL, strip off the leading directories.
  // ================================================================
  void ccdoc::phase3::html::make_file_url(string& url,string& fn) const
  {
    // Strip off the leading directories to
    // make the relative reference work.
    string::iterator itr = fn.begin();
    string::iterator relpath_itr = fn.begin();
    for(;itr!=fn.end();++itr) {
      if( '/' == *itr ) {
        relpath_itr = itr;
      }
    }
    url = "";
    for(<b>++relpath_itr</b>;relpath_itr!=fn.end();++relpath_itr) {
      url += *relpath_itr;
    }
  }
</pre>
<h4>Fixed Code</h4>
<pre>
  // ================================================================
  // Make file URL, strip off the leading dSeptember 18, 2001 (Tuesday)

The new release of ccdoc is available: "ccdoc v0.8 r18 2001/09/18".

This release fixes issues 0052 and is the first release that contains the linux port.





irectories.
  // ================================================================
  void ccdoc::phase3::html::make_file_url(string& url,string& fn) const
  {
    // Strip off the leading directories to
    // make the relative reference work.
    string::iterator itr = fn.begin();
    string::iterator relpath_itr = fn.begin();
    for(;itr!=fn.end();++itr) {
      if( '/' == *itr ) {
        relpath_itr = itr;
        <b>++relpath_itr; // ISSUE 001 FIX</b>
      }
    }
    url = "";
    for(;relpath_itr!=fn.end();++relpath_itr) {
      url += *relpath_itr;
    }
  }
</pre>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0002
ENTRY_TITLE: The ccdoc_top tage is incorrectly placed in the HEAD section.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/22
ENTRY_REPORTED_BEGIN:
Very little bug: &lt;a name=ccdoc_top&gt;&lt;/a&gt; is placed into the HEAD, which is
not correct (according to HTML 4.0 at least, but I don't think its right for
HTML 3.x). It should be pleced just *before* that &lt;table border=0
width="100%"&gt; in the BODY. However I don't know a browser which is confused
by this.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Moved &lt;a name=ccdoc_top&gt;&lt;/a&gt; to the BODY section.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0003
ENTRY_TITLE: Need a new switch, similar to -head, that inserts a file after the head tag to insert custom META elements.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/22
ENTRY_REPORTED_BEGIN:
What is missing, a switch similar to '-head' which inserts the
specified file just after the &lt;head&gt; tag. This is required to insert custom
META elements, primary for set the charset. (Note that most browsers accepts
META http-equivs in the BODY (!) so I can use -head, but its not correct
HTML.)
<p>
<hr>
<i>Perhaps a -meta &lt;file&gt; switch?</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Added a -meta &lt;file&gt; switch that allows the user to specify a 
file that contains custom meta variables.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0004
ENTRY_TITLE: HTTP server problem with uncommon extensions like .exe_gz and .taz.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/23
ENTRY_REPORTED_BEGIN:
The HTTP server on www.joelinoff.com gives back text/html content-type for
those files with uncommon extensions, like ccdoc.exe_gz, doc.tgz. It
confuses many browsers. (I think the solution is to set DefaultType in the
httpd.conf to application/octet-stream, unless u serve html or plain text
documents with odd or no extension.)
<p>
(btw, if some users will report CRC errors in the gzipped files, this is
because there is some conflict between the HTTP server and some (or only
one?) proxy-es. Dont ask why, I got partial-content (HTTP 206) without the
last few kbytes of files (=> gunzip detects CRC error), then decided to
bypass the cache-proxy.)
<p>
<hr>
<i>I completely agree. I have been trying to work with my domain hosting service
to correct this (Earthlink) but they are very slow to respond.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
I resolved this by renaming the archives that were causing problems. Apparently
the ".gz" extension does the right thing.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0005
ENTRY_TITLE: Log output is not flushed properly on solaris platforms.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/22
ENTRY_REPORTED_BEGIN:
Part of the log file is missing on the solaris platforms because
the s_log global variable is not flushed at the end of the program.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
This was resolved by flushing the s_log object before the program
exits.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0006
ENTRY_TITLE: Tests weren't working properly.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/22
ENTRY_REPORTED_BEGIN:
Tests are being reported as successful when they are not.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
There was a bug in the test.pl file that caused all tests to pass.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0007
ENTRY_TITLE: WARNING: File '*.h' cannot be read so it will be ignored.
ENTRY_REPORTED_BY: <a href="mailto:yuriy@fortress-sys.com">Yuriy Stul</a>
ENTRY_REPORTED_ON: 2001/08/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/23
ENTRY_REPORTED_BEGIN:
Wildcards do not work in my cmd.exe shell. Here is my example:
<pre>
    C:> ccdoc.exe -db LB.db -pkg LBTools *h
    WARNING: File '*.h' cannot be read so it will be ignored.
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
I modified the MSVC version of the program to attempt to process
wildcards if the attempt to open the specified file fails.
The -files switch still works.
<p>
When I originally closed this issue, I used the following reasoning.
<blockquote>
<p>
Wildcards do not work in the cmd.exe shell on Windows platforms because
it does not expand them.
Instead it expects the application to do the expansion.
<p>
Ccdoc cannot do that because a user can run many different shells on Windows
platforms, such as: ksh, rsh and tcsh (I use tcsh). Most of those shells (in
fact all of them execept cmd.exe) expand wildcards before passing the the
program.
<p>
Unfortunately, ccdoc can't tell the difference a legitimate file name
with a * or ? in it from the tcsh and a wildcard request from the cmd
sheel so you have to tell it using the -files switch.
<p>
You can work around this problem by using the new -files switch as follows:
<pre>
    C:> DIR \B *.h > hfiles.txt
    C:> ccdoc -db foo.db -pkg foo -files hfiles.txt
</pre>
</blockquote>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0008
ENTRY_TITLE: Turn off the ccdoc generation of special members.
ENTRY_REPORTED_BY: <a href="mailto:tm5@gmx.at">Martin Trappel</a>
ENTRY_REPORTED_ON: 2001/08/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/23
ENTRY_REPORTED_BEGIN:
Ccdoc seems to generate automatic comments for Standard Copy Constructor,
Destructor and Assignment Operator.
<p>
Can I disable this, since I have a few classes where I do not have these
and I don't quite see the point in having doc for non-existant members?
<p>
<hr>
<i>This was originally added because of request from Lou Sanchez-Chopitea
because, according to the standard, these special members always exist whether
you declare them or not.</i>
<p><i>
I agree with your point that you should not be forced to see them unless you
want to and will look into providing a switch that gives you the control
to turn the reporting of them on or off.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Added the -[no]cdsm switches to phase 1 to allow users to control whether
or not default special members are created.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0009
ENTRY_TITLE: Compile problem in gcc 3.0 on SuSE linux platform.
ENTRY_REPORTED_BY: <a href="mailto:MDavis@vista-care.com">Michael Davis</a>
ENTRY_REPORTED_ON: 2001/08/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/23
ENTRY_REPORTED_BEGIN:
We use gcc 3.0 on a
SuSE linux platform here, and your code compiled with only one glitch.  Here
is a patch should you want it:
<pre>
*** phase3_html.cc.orig Thu Aug 23 09:52:22 2001
--- phase3_html.cc      Thu Aug 23 09:36:43 2001
*************** void ccdoc::phase3::html::write_class_de
*** 476,482 ****
        --xitr;
        make_tag_id(*xitr,prev_tag);
        }
!       if( itr ) {
        vector&lt;statement::base*&gt;::iterator xitr = itr;
        ++xitr;
        if( xitr != contents.end() ) {
--- 476,482 ----
        --xitr;
        make_tag_id(*xitr,prev_tag);
        }
!       if( itr != contents.end() ) {
        vector&lt;statement::base*&gt;::iterator xitr = itr;
        ++xitr;
        if( xitr != contents.end() ) {
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Thank you. I have updated and released the fix.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0010
ENTRY_TITLE: Random character appears between package name and function/macro/etc. name in the HTML title.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/08/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/23
ENTRY_REPORTED_BEGIN:
Random character appears between package name and function/macro/etc. name
in the HTML title.
<p>
Eg. this is the title for function RcMalloc in rcheap.h:
<pre>
  &lt;title&gt;ccdoc RcMalloc rcheap.h:C:function&lt;/title&gt;
</pre>
'C' should not be there.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
This problem occurred because the lineno was being appended to
the output string used for the title as an integer rather than
a string in phase3_html.cc at line 2169.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0011
ENTRY_TITLE: Instantiations of class template methods are reported as global functions.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/24
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/24
ENTRY_REPORTED_BEGIN:
In the following example, the instantiation of the template
constructor is incorrectly reported as a global function.
<pre>
    template &lt;class T&gt;
    class A {
    public:
      A();
    };

    // Instantiation is incorrectly reported as
    // a global function.
    template &lt;class T&gt;
    A&lt;T&gt;::A()
    {
    }
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
This occurs because ccdoc attempts to do a name resolution to determine
where the instantiation belongs so it tries to look up A&lt;T&gt; and can't
find it.
<p>
The best way to work around this problem is to tell ccdoc to ignore
the template method instantiations as shown below:
<pre>
    template &lt;class T&gt;
    class A {
    public:
      A();
    };

    <b><i>#if !defined(__ccdoc__)</i></b>
    // Instantiation is incorrectly reported as
    // a global function.
    template &lt;class T&gt;
    A&lt;T&gt;::A()
    {
    }
    <b><i>#endif</i></b>
</pre>
Meanwhile, I am looking at adding a feature to ccdoc to tell it to
ignore template method instantiations (without ignoring template
functions), see issue <a href="#TAG_0012">0012</a>.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0012
ENTRY_TITLE: Ccdoc should ignore template method instantiations.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/17
ENTRY_REPORTED_BEGIN:
See issue <a href="#TAG_0011">0011</a> for details of the problem.
Ccdoc should have a switch that allows users to tell it to turn
off (or on) the recognition of template method instantiations.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r33 and verified by test 69.
<p>
See issue <a href="#TAG_0149">0149</a> for more details.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0013
ENTRY_TITLE: Add ccdoc to source forge.
ENTRY_REPORTED_BY: <a href="mailto:semacdi@hotmail.com">Scott MacDiarmid</a>
ENTRY_REPORTED_ON: 2001/08/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/01/02
ENTRY_REPORTED_BEGIN:
I am sure you have been asked this before, but have you ever considered 
moving this project to SourceForge
(<a href="http://www.sf.net">http://www.sf.net</a>)? It provides bug 
tracking, forums, and version control.  I find it useful from both sides of 
the coin.  Meaning as a developer and an end-user.  As a developer it allows 
people to easy submit bugs to me, ask me question and it also provides CVS 
for good version control.  As an end user I can follow what a project is 
doing very easily.  The only catch is you would have to put it under an open 
source license.  Anyway, just a thought.
<p>
<hr>
<i>I think that this is a great idea and have initiated the process.
I will close this issue when the transfer is complete.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
I finally got around to it.
See <a href="http://ccdoc.sourceforge.net">http://ccdoc.sourceforge.net</a>.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0014
ENTRY_TITLE: The typedef id for function pointer doesn't get extracted properly by ccdoc.
ENTRY_REPORTED_BY: <a href="mailto:chifung@csua.berkeley.edu">Chi-Fung Fan</a>
ENTRY_REPORTED_ON: 2001/08/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/24
ENTRY_REPORTED_BEGIN:
The typedef id for function pointer doesn't get extracted properly by ccdoc.
Example:
<pre>
    /** Zero-argument const method type for Node */
    typedef Node* (Node:*NodeConstMeth) () const;
</pre>
Ccdoc will generate an entry with 'const' instead of NodeConstMeth.
<p>
<hr>
<i>This is a serious problem, I will look into it as soon as possible.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
The problem was in phase1_parser.c. The parse_typedefs id heuristic did
not how to deal with a trailing const keyword.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0015
ENTRY_TITLE: Methods with throw clauses surrounded by parentheses don't get extracted properly by ccdoc.
ENTRY_REPORTED_BY: <a href="mailto:chifung@csua.berkeley.edu">Chi-Fung Fan</a>
ENTRY_REPORTED_ON: 2001/08/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/27
ENTRY_REPORTED_BEGIN:
Methods with throw claused don't extracted properly by ccdoc. Example:
<pre>
  void PlotDown(const doc::CC* pCC) const
    throw (RunTimeError);
</pre>
<p>
<hr>
<i>I will fix this as soon as possible. Meanwhile, here is a workaround
that you can use.
</i>
<pre>
  void PlotDown(const doc::CC* pCC) const
#if !defined(__ccdoc__)
    throw (RunTimeError)
#endif
    ;
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r5.
<p>
This problem occurred because the get_fct_id() heuristic in phase1_parser
assumed that the trailing set of outermost parentheses defined the function
argument list. I changed it look for the trailing set of outermost parentheses
before a "throw" keyword.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0016
ENTRY_TITLE: Source file names of the form ../folder/file.ext don't work properly in the cmd.exe shell under windows.
ENTRY_REPORTED_BY: <a href="mailto:yuriy@fortress-sys.com">Yuriy Stul</a>
ENTRY_REPORTED_ON: 2001/08/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
Source file names of the form ../folder/file.exe don't work properly.
The error message that it report is:
<pre>
  The instruction at "0x00402330" referenced memory at "0x6e64658f".
  The memory could not be read.
</pre>
<hr>
<i>
I need your help. I cannot reproduce this bug. I have created half a 
dozen test cases and they all work.</i>
<p><i>
Here are two examples of the 
command lines I was testing:</i>
<pre>
  ..\bin_opt_msvc_MSWin32-4.0\ccdoc -db ..\test\test.db -html ..\test\html\ ..\sources\s1.h ..\sources\s2.h

  AND

  ..\bin_opt_msvc_MSWin32-4.0\ccdoc -db ../test/test.db -html ../test/html/ ../sources/s1.h ../sources/s2.h
</pre>
<i>
I tried multiple levels of directories.
I tried different source file extensions and everything else I could think of.
</i>
<p>
<i>
All of this testing was done under Win2K using the MS-DOS command 
interpreter (cmd.exe).
</i>
<p>
<i>
Can you help figure out what am I doing wrong so that I can track down
and fix this problem?
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r8.
<p>
First, my thanks to Yuriy for helping me track this down.
<p>
This was a different manifestation of issue 
<a href="#TAG_0020">0020</a>. The fix was the same.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0017
ENTRY_TITLE: Can't differentiate between different revisions of ccdoc 0.8.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/26
ENTRY_REPORTED_BEGIN:
It is difficult to distinguish between different versions of ccdoc 0.8.
<p>
<hr>
<i>I need to a -version switch to report the version/revision of the
program.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r5.
<p>
Added the -version switch. Deprecated the -cid switch.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0018
ENTRY_TITLE: Directory separators in -root names cause run time errors.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/27
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/27
ENTRY_REPORTED_BEGIN:
Directory separators in -root names cause run time errors. If you use
a directory separator in a -root name, it confuses ccdoc into thinking
there is a directory when there isn't which causes a run-time error.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r6.
<p>
Added '/' and '\' filtering in ccdoc::phase3::html::format_name().
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0019
ENTRY_TITLE: The @see directive no longer accepts user defined links.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/27
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/27
ENTRY_REPORTED_BEGIN:
The @see directive no longer accepts user defined links.
In the previous version of ccdoc I could put in a direct link as follows:
<pre>
@see &lt;a href=mywebpage.html&gt;Useful Stuff&lt;/a&gt;
</pre>
<p>
<hr>
<i>This is an oversight. It will be fixed immediately.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r7.
<p>
Modified the scanner to accept @see arguments that begin with a '&lt;'.
Modified the html generator to output these without interpretation.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0020
ENTRY_TITLE: ccdoc crashes
ENTRY_REPORTED_BY: <a href="mailto:chifung@csua.berkeley.edu">Chi-Fung Fan</a>
ENTRY_REPORTED_ON: 2001/08/27
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
Both MSVC and cygwin versions of ccdoc crashed on generating docs for my
program source.  Attached is the debug messages before ccdoc dumped core.
<p>
I noticed that the offendng file that caused the core dump is the last
file 'src/ScribDoc.h'.  If I move it to be the first input file,
everythinkg runs ok.  This is also the workaround for me.
<p>
What information do you need to debug this problem?
<pre>
ccdoc -v -db doc/webdocs/ccdoc.db -pkg Util include/mathpack/convolution.h include/mathpack/geometry.h include/ctl/iterator.h src/plot.h
db: read begins
db: does not exist
db: read ends
phase1: begins
phase1: parsing 'include/mathpack/convolution.h' ...
phase1: parsing 'include/mathpack/geometry.h' ...
phase1: parsing 'include/ctl/iterator.h' ...
phase1: parsing 'src/plot.h' ...
phase1: ends
db: write begins
db: writing 146 statements
db: write ends
ccdoc -v -db doc/webdocs/ccdoc.db -pkg Scribble src/navigator.h src/pager.h src/charannotvw.h src/drawtool.h src/presenter.h
db: read begins
db: read ends
phase1: begins
phase1: parsing 'src/navigator.h' ...
phase1: parsing 'src/pager.h' ...
phase1: parsing 'src/charannotvw.h' ...
phase1: parsing 'src/drawtool.h' ...
phase1: parsing 'src/presenter.h' ...
phase1: ends
db: write begins
db: writing 406 statements
db: write ends
ccdoc -v -db doc/webdocs/ccdoc.db -pkg Scribble src/definitions.h src/annottempl.h src/annotation.h src/chardefinitions.h src/dynamics.h
src/doctypes.h src/visitor.h src/docreader.h src/docwriter.h src/tablet.h src/glyph.h src/cc.h src/token.h src/page.h src/ScribDoc.h
db: read begins
db: read ends
phase1: begins
phase1: parsing 'src/definitions.h' ...
phase1: parsing 'src/annottempl.h' ...
phase1: parsing 'src/annotation.h' ...
phase1: parsing 'src/chardefinitions.h' ...
phase1: parsing 'src/dynamics.h' ...
phase1: parsing 'src/doctypes.h' ...
phase1: parsing 'src/visitor.h' ...
phase1: parsing 'src/docreader.h' ...
phase1: parsing 'src/docwriter.h' ...
phase1: parsing 'src/tablet.h' ...
phase1: parsing 'src/glyph.h' ...
phase1: parsing 'src/cc.h' ...
phase1: parsing 'src/token.h' ...
phase1: parsing 'src/page.h' ...
phase1: parsing 'src/ScribDoc.h' ...
phase1: ends
db: write begins
db: writing 1994 statements
db: write ends
      0 [main] ccdoc 94223783 open_stackdumpfile: Dumping stack trace to CCDOC.EXE.stackdump
/cygdrive/c/CHIFUNG/BIN/mkscribdocs.sh: line 63: 94223783 Segmentation fault      (core dumped) ccdoc -db doc/webdocs/ccdoc.db
root.txt
      0 [main] ccdoc 603763 open_stackdumpfile: Dumping stack trace to CCDOC.EXE.stackdump
/cygdrive/c/CHIFUNG/BIN/mkscribdocs.sh: line 64: 603763 Segmentation fault      (core dumped) ccdoc -db doc/webdocs/ccdoc.db -index
      0 [main] ccdoc 94223007 open_stackdumpfile: Dumping stack trace to CCDOC.EXE.stackdump
/cygdrive/c/CHIFUNG/BIN/mkscribdocs.sh: line 70: 94223007 Segmentation fault      (core dumped) ccdoc -db doc/webdocs/ccdoc.db
-html doc/webdocs/ -header root_hdr.txt -srcurl ../../ -root Scribble
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fix in r8.
<p>
Dangling prefix comment statements at the end of db caused an iteration
to extend past the end of a collection in database.cc around line 400.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0021
ENTRY_TITLE: Report the version/revision information in the default trailer.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/28
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
Report the version/revision information in the default trailer. This makes
error reporting easier.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r8.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0022
ENTRY_TITLE: Centralize the version/revision information.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/28
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
Currently there are several references to "0.8" in phase3_html.c and in
switches.cc. These should be centralized to make maintenance easier.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r8.
<p>
All references to version are now funneled through ccdoc::switches::version().
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0023
ENTRY_TITLE: DOC++ vs ccdoc
ENTRY_REPORTED_BY: <a href="mailto:pbc@poczta.onet.pl">Bragas</a>
ENTRY_REPORTED_ON: 2001/08/28
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
I'm wondering if you couldn't merge your project with DOC++. They look very
similar and joining your efforts could help creating even better tool (best
in its category ?).
<p>
I'm not DOC++ developer and this is just my private impression.
<p>
<hr>
<i>
That is an interesting suggestion. I never really gave it much thought
because there are a large number of documentation generation tools out
there (see my other tools page) and I have no idea which ones are
suitable for merging.
</i>
<p>
<i>
As far as I am concerned, the DOC++ developers (or anyone else for
that matter) are free to take the ccdoc code and incorporate it into
their system(s). I would be happy to support them in that
effort. Furthermore, if they showed sufficient commitment to my goal
of improving documentation in the C++ community for free, I would be
happy to hand it over completely.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Surveyed current ccdoc users and asked whether they wanted this
project merged with Doxygen or DOC++. All (100%) of the respondents
said no because they felt that the tools served different needs.
Ccdoc was viewed as an interface documentation tool and doxygen was
viewed as a source code documentation tool. In many cases, folks used
both.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0024
ENTRY_TITLE: Missing comma separator in @see output for the alternative URL form.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/08/28
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
The @see directive does not correct separate entries with commas if
there an alternative form URL specified.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r9.
<p>
Forgot to output leading comma's for the alternative URL form of the
@see directive.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0025
ENTRY_TITLE: Undocumented 0.7a feature for explicitly specifying @pkgdoc URLs is no longer supported.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/28
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/28
ENTRY_REPORTED_BEGIN:
In version 0.7a, ccdoc supported an undocumented syntax for the @pkgdoc
directive that allowed the user to specify a custom URL. The syntax looked
like this:
<pre>
    /** @pkgdoc A.B ../A_B.html*/
</pre>
Ccdoc would create the link using the standard package name and substitute in
the specified link. We are using that feature extensively. Will it be supported
in v0.8?
<p>
<hr>
<i>Yes. This is an oversight. All features that ccdoc can reasonably support
will be supported.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r9.
<p>
Added support for the two argument form of @pkgdoc and documented it in the
on-line help and in the users guide.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0026
ENTRY_TITLE: Provide an expanded package contents view.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
This would replace the tree view in the previous version. Basically it
would expand the contents path hierarchically (the same way it is done
in the class summary) with the type, scope and short description.
<p>
<hr>
<i>I think that this is a great idea. The switch name will be something like
-[no]rpthpc (hierarchical package contents).</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
I implemented the -[no]rpthpc. It reports the hierarchical class
structure of each package. I liked the format so much that I made
it the default.
<p>
I also added the -[no]rptcsd to allow you to control whether details
are reported on the class summary page (report class summary details).
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0027
ENTRY_TITLE: Provide a way to turn off package source.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
The source entry on the package page always points to a ccdoc db file. This
is not useful to casual readers.
<p>
<hr>
<i>I agree. I will remove this from the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
Completely removed source statements for packages. The db reference does not
make sense for users.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0028
ENTRY_TITLE: Provide a way to turn off the default author on the package page.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
Reporting unascribed as the default package author when the author is
not specified is not really useful in our environment.  Can I turn
this default handling off?
<p>
<hr>
<i>Not right now, I will add a switch called -[no]rptdpa (default
package author) to give you that control.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
Added the -[no]rptdpa switches. The default is -norptdpa.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0029
ENTRY_TITLE: Provide a way to turn off the default version on the package page.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
Reporting unknown as the default package version when the version is
not specified is not really useful in our environment.  Can I turn
this default handling off?
<p>
<hr>
<i>Not right now, I will add a switch called -[no]rptdpv (default package version)
to give you that control.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
Added the -[no]rptdpa switches. The default is -norptdpv.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0030
ENTRY_TITLE: Provide a way to turn off default description comments on the page.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
Reporting undocumented as the default package comment when the comment
is not specified is not really useful in our environment.
Can I turn this default handling off?
<p>
<hr>
<i>Not right now, I will add a switch called -[no]rptdpd (default
package comment) to give you that control.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
Added the -[no]rptdpd switches, made -norptdpd the default.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0031
ENTRY_TITLE: Provide a way to change the "package" string in the title on package pages.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
In our environment packages have different semantics, some of them are
subsystems, others are packages and still others are layers. I would
like to be able to change the title on the package page to reflect
this.
<p>
<hr>
<i>This is a good idea. I will add a @pkgdoctid directive that allows
you to specify the title tag that ccdoc writes out. This was not
possible in earlier versions because they use GIF images but in the
new version it is straightforward.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
Added the @pkgdoctid directive. See the on-line help or the users guide
for additional details.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0032
ENTRY_TITLE: Users guide and on-help report than -norptpub is the default.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/08/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/29
ENTRY_REPORTED_BEGIN:
Minor documentation nit, help and the users guide report that -norptpub
is the default when the real default is -rptpub.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0033
ENTRY_TITLE: This construct is incorrectly recognized as a struct: void foo(struct bar* spam).
ENTRY_REPORTED_BY: <a href="mailto:JWawszczak@era.pl">Wawszczak, Jarosaw</a>
ENTRY_REPORTED_ON: 2001/08/30
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/08/30
ENTRY_REPORTED_BEGIN:
This construct is incorrectly recognized as a struct: void foo(struct bar* spam).
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r10.
<p>
This occurred because the parsing heuristic didn't recognize the the
struct declaration was inside an argument list.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0034
ENTRY_TITLE: For -rpthpc only show packages.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/02
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/04
ENTRY_REPORTED_BEGIN:
I have one more request.... I'd like the 'hierarchical contents' to
show 'packages only', and not classes, namespaces, etc.  Basically, I
want to limit the depth to packages.  The 'classes' link can still be
the full glory.  Without this, the current contents with classes is
too detailed for the top-level index.  With my mod, it will be a
direct replacement of the old 'tree'.
<p>
<hr>
<i>I think that this is a good idea. I will release it in r11.
Unfortunately, I won't be able to work on it until next week.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r11.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0035
ENTRY_TITLE: ccdoc 0.7a to 08 quick reference
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/02
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: 2001/09/04
ENTRY_RESOLVED_ON: Joe Linoff
ENTRY_REPORTED_BEGIN:
I think that it would be useful to have a summary of the changes between
0.7a and 0.8 for users that are familiar with 0.7a.
<p>
<hr>
<i>I think that this is a good idea. I will add something as soon as I can.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r11.
<p>
Added a <a href=../quick_ref.htm>quick reference guide</a> at the top level.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0036
ENTRY_TITLE: Comments get lost.
ENTRY_REPORTED_BY: <a href="mailto:yuriy@fortress-sys.com">Yuriy Stul</a>
ENTRY_REPORTED_ON: 2001/09/03
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/04
ENTRY_REPORTED_BEGIN:
Comments get lost under the following conditions:
<pre>
  /**
   * This is a dangling comment at the head of a file.
   */
  /**
   * This is a class comment that gets lost.
   */
  class A {};
</pre>
You can work around this problem by changing the initial comment to
a non-ccdoc style comment as follows:
<pre>
  /*
   * This is a dangling comment at the head of a file.
   */
  /**
   * This is a class comment that gets lost.
   */
  class A {};
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r12.
<p>
This problem occurred because the database reader assumed that comments
could not exist in sequential records. The fix was in database.cc around
line 399.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0037
ENTRY_TITLE: Change the asterisk column header to "Inherited From".
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/05
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/05
ENTRY_REPORTED_BEGIN:
Change the asterisk column header to "Inherited From".
The asterisk is not very meaningful.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r13.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0038
ENTRY_TITLE: Change the Path column header to "Entity".
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/05
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/05
ENTRY_REPORTED_BEGIN:
Change the asterisk column header to "Inherited From".
The asterisk is not very meaningful.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r13.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0039
ENTRY_TITLE: Performance problem in phase3.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/05
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/07
ENTRY_REPORTED_BEGIN:
The new version of ccdoc seems to generate HTML files much slower than v0.7a.
In our tests it was running about 10X slower.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r14.
<p>
Found an O(N^2) complexity algorithm in databases::get_stmt_no_pkgs().
Converted the algorithm to O( n log(n) ). The test case performance
improved from 49 minutes to 30 seconds but the real case is still slow.
<p>
Found another O(N^2) complexity algorithm in databases::get_stmt_no_pkgs()
related to tree traversal for id lookups.
Converted the algorithm to O( n log(n) ). The real test case performance
improved from 18 hours to 12 minutes.
<p>
Made the generated HTML slightly more compact. The resulting output in the browers is identical.
<p>
<ul>
<li>Modified indenting to use
&lt;blockquote&gt; and &lt;/blockquote&gt; instead of
&lt;table&gt;&lt;tr&gt;&lt;td&gt;&lt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&gt;&lt;/td&gt;&lt;td&gt;
 and &lt;/td&gt;&lt;/tr&gt;&lt;/table&gt; because it saves characters and achieves the
same result.
<li>Removed extraneous carriage returns.
<li>Removed the comment banner in the trailer.
</ul>
<p>
Summary of performance improvements:
<p>
<ul>
<li>Added m_path_map and support to database.h.
<li>Use m_path_map in phase3::html to improve performance.
<li>Removed the redundant calculation of the previous link in 
    phase3::html::write_class_details.
<li>Improved phase2 performance as well.
</ul>
<p>
Summary of other miscellanous changes:
<p>
<ul>
<li>Verbose mode because more verbose. It now reports each instance of each
entity type for which HTML is created. In the past it only reported it for
classes.
<li>Removed the old, slow tree lookup code.
</ul>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0040
ENTRY_TITLE: Protected inherited methods reported.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/09/05
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/06
ENTRY_REPORTED_BEGIN:
In some cases, it looks like protected inherited methods are reported.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r13.
<p>
The make_class_contents() method in phase3_html.cc was not verifying
that the inherited methods were accessible.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0041
ENTRY_TITLE: Improve 0039 performance enhancement.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/09/07
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/08
ENTRY_REPORTED_BEGIN:
The following changes would improve the issue
<a href="#TAG_0039">0039</a>
performance fix even more:
<p>
<ul>
<li>Use the same map for phase2 and phase3. In the current implementation,
phase2 clears the map and phase3 re-creates it. This is unnecessary because
they are the same.
<li>Ignore comments. Although comments have ids, they are not used. This 
would reduce the memory footprint somewhat.
<li>Don't write out the database if it hasn't changed. This occurs when
phase3 is run independently.
</ul>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r15.
ENTRY_RESOLVED_END:


# ================================================
ENTRY_ID: 0042
ENTRY_TITLE: ccdoc bug notification - not correctly determining variable name
ENTRY_REPORTED_BY: <a href="mailto:mrprk@hotmail.com">Paul Kohler</a>
ENTRY_REPORTED_ON: 2001/09/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/10
ENTRY_REPORTED_BEGIN:
<b>Version</b>: ccdoc v0.8 r14 2001/09/07 bin_opt_msvc_MSWin32-4.0
<br>
<b>Shell</b>: cmd.exe
<br>
<b>Platform</b>: Windows 2000
<p>
It seems to be reporting a link and link text in the contents of a package
as the value (it is a static global variable). There are two and the
comments are generated correctly, but the link goes to the first one.
<p>
Here is the snippet of code with comments:
<p>
<blockquote>
<pre>
typedef int   Bool;
#define true  1
#define false 0

/**
 * Global boolean value to signal if an account is loaded.
 *
 * @author  Paul Kohler
 */
static Bool g_bAccountInit = false;

/**
 * Global boolean value to signal if the connection has been established.
 *
 * @author  Paul Kohler
 * @see IConnect
 */
static Bool g_bConnected = false;
</pre>
</blockquote>
And this is the resulting html snippit:
<blockquote>
<pre>
false(href="ccdoc.lib.libivr.false.var.html")   variable   public   Global
boolean value to signal if the ICSS connection has been established.
false(href="ccdoc.lib.libivr.false.var.html")   variable   public   Global
boolean value to signal if an account is loaded.
</pre>
</blockquote>
<p>
<hr>
<i>Excellent report! I was able to duplicate the problem in a few minutes
and am currently working to fix it. My hope is that the fix will be
released in r15 as early as today.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r15.
<p>
The variable parsing heuristic was not correctly recognizing '=' as an id
separator in some cases. Look for "Issue 0042" in a comment in
phase1_parser.cc.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0043
ENTRY_TITLE: Old hash mark syntax for @see does not work.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/09/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/10
ENTRY_REPORTED_BEGIN:
The old @see #foo syntax no longer works.
<hr>
<p>
<i>This was an oversight. I inadvertently deprecated it. It will be
fixed in the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r15.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0044
ENTRY_TITLE: The summary report could use a little more indenting.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/09/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/10
ENTRY_REPORTED_BEGIN:
It would be nice to be able to control the indenting level for reporting
hierarchical objects on the summary page..
<hr>
<p>
<i>Perhaps I could add a switch that would allow you to control the level
of indenting.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r15.
<p>
Added the -rptcsi (Class Summary Indent) switch.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0045
ENTRY_TITLE: The variable width font in the Code: section is not as readable as the fixed width font used in 0.7a.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/09/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/11
ENTRY_REPORTED_BEGIN:
The variable width font in the Code: section is not as readable as the
fixed width font used in 0.7a.
<hr>
<i>
The mono-space font was removed because of a general consensus that
the variable width font was easier to read as demonstrated by Bjarne
Stroustroup changing the font for all C++ examples in his recent
books.
</i>
<p>
<i>
I have no opinion one way or the other.
</i>
<p>
<i>
I will add a switch that allows the user to control this.
of indenting.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r17.
<p>
Added the -rptfwcf (Fixed Width Code Font) switch.
<p>
I originally reported this as fixed in r15 but the generate HTML still
seemed to be proportional so I changed the generated output.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0046
ENTRY_TITLE: The @see index doesn't seem to work.
ENTRY_REPORTED_BY: <a href="mailto:cmeuzelaar@thermonoran.com">Chris Meuzelaar</a>
ENTRY_REPORTED_ON: 2001/09/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/10
ENTRY_REPORTED_BEGIN:
ccdoc fails to generate links for @see directives when generating
documentation for a large number of files / classes when multiple
instances of the function exist in a class (see below).  The sample
below will generate HTML with the link back to the first function
CSampleTray::AddSampleAt 0, but not the other two.  Attached are the
batch files used to generate the documentation as well as the database
file. I am generating documentation using ~500 files.
<hr>
<p>
<i>
Here is a bit of sample code that doesn't work.
</i>
<blockquote>
<pre>
class A {
public:
  /**
   * Do stuff.
   * @see A::B 1
   * @see A::B 2
   */
  void B();
  void B(int);
  void B(double);
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r16.
<p>
I thought that this bug was important enough to warrant a re-release.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0047
ENTRY_TITLE: The indenting on the contents page should be the same as the summary report.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/09/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/11
ENTRY_REPORTED_BEGIN:
The indenting on the contents page should be the same as the summary
report.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r17.
<p>
Modified the -rptcsi (Class Summary Indent) switch to also change the 
contents indenting.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0048
ENTRY_TITLE: Derived classes in namespaces are not recognized correctly.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/09/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/11
ENTRY_REPORTED_BEGIN:
In the following example, the HTML for class_two does not correctly
link to class_one.
<blockquote>
<pre>
namespace ccdoc_test {
  class class_one {
  };
  class class_two : public class_one {
  };
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r17.
<p>
Partially scoped names were not being expanded in the extends clause
processing in phase3_html.cc.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0049
ENTRY_TITLE: Non-template class method instantiation not recognized correctly.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/09/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/17
ENTRY_REPORTED_BEGIN:
In the following example, some_method() is reported as a separate function.
<blockquote>
<pre>
namespace ccdoc_test {
  class class_one {
  public:
    int some_method();
  };
  inline int class_one::some_method()
  {
    return 0;
  }
}
</pre>
</blockquote>
<hr>
<i>
This is not quite as serious as the previous bug because it
can be worked around as follows:
</i>
<blockquote>
<pre>
namespace ccdoc_test {
  class class_one {
  public:
    int some_method();
  };
  <b>#if !defined( __ccdoc__ )</b>
  inline int class_one::some_method()
  {
    return 0;
  }
  <b>#endif</b>
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r33 and verified by test 69.
<p>
This was fixed as part of the issue <a href="#TAG_0149">0149</a> 
work.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0050
ENTRY_TITLE: Ccdoc fails to parse methods with fct args properly.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/09/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/11
ENTRY_REPORTED_BEGIN:
The following example is reported incorrectly as a variable of name fp:
<blockquote>
<pre>
class A {
public:
  int fct2( void ( * fp ) ( ) ) ;
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r17.
<p>
This bug resulted from the phase_parser not being able to correctly
identify methods under certain conditions.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0051
ENTRY_TITLE: External class method implementations with default arguments are not correctly recognized.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/09/17
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/17
ENTRY_REPORTED_BEGIN:
External class method implementations with default arguments are not
correctly recognized. Here is an example:
<blockquote>
<pre>
class A {
public:
  void fct(int x=0);
};
void A::fct(int x)
{
}
</pre>
</blockquote>
Ccdoc treats the implementation as a separate function.
<hr>
<i>
This occurs because ccdoc does not understand default arguments and thinks
that the =0 makes two different argument sequences. You can workaround this
in two different ways, both are shown below:
</i>
<blockquote>
<table border=0 cellspacing=3 cellpadding=3 width="80%">
<tr>
<th align=left>Workaround #1</th>
<th align=left>Workaround #2</th>
</tr>
<tr>
<td valign=top>
<pre>
class A {
public:
  void fct(int x=0);
};
<b>#if !defined(__ccdoc__)</b>
void A::fct(int x)
{
}
<b>#endif</b>
</pre>
</td>
<td valign=top>
<pre>
class A {
public:
  void fct(int x <b>/**@#-*/</b> =0 <b>/**@#+*/</b> );
};

void A::fct(int x)
{
}
</pre>
</td>
</tr>
</table>
</blockquote>
<i>
Because there are workarounds, this a low priority bug.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r33 and verified by test 69.
<p>
This was fixed as part of the issue <a href="#TAG_0149">0149</a> 
work.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0052
ENTRY_TITLE: Backslash character definition ('\\') confuses the ccdoc scanner.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/09/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/18
ENTRY_REPORTED_BEGIN:
The following definition confuses the ccdoc parser.
<blockquote>
<pre>
const char X = '\\';
</pre>
</blockquote>
<hr>
<i>This is a serious bug that will be fixed as soon as possible.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r18.
<p>
There was a scanner problem for detecting the ends of character constants
in some cases.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0053
ENTRY_TITLE: No line numbers for internal comment parsing warnings.
ENTRY_REPORTED_BY: <a href="mailto:ray.rizzuto@ulticom.com">Ray Rizzuto</a>
ENTRY_REPORTED_ON: 2001/09/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/21
ENTRY_REPORTED_BEGIN:
Error during parse of header file with a package comment:
<blockquote> 
<pre>
WARNING: Internal comment parsing error.
 Unexpected EOF for ''.
 This comment will be ignored.
WARNING: Internal comment parsing error.
 Unexpected EOF for ''.
 This comment will be ignored.
</pre>
</blockquote> 
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r19.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0054
ENTRY_TITLE: Serious problem with typedef of struct
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/21
ENTRY_REPORTED_BEGIN:
The following struct typedef conduses ccdoc.
<pre>
typedef struct _TEST {
    int a;
    int b;
} TEST1;
</pre>
It generates the following documentation:
<pre>
package ccdocTest

Contents

    Entity    Type       Scope    Short Description
    a         typedef    public   undocumented
    b         variable   public   undocumented
</pre>
<hr>
<i>
This is definitely a bug.
When I revisited the test suite I noticed that there were no
cases for struct and class typedefs.
</i>
<p>
<i>
You might be able to workaround this problem as follows:
</i>
<pre>
  struct _TEST {
    int a;
    int b;
  };
  typedef _TEST TEST1;
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r19.
<p>
The ccdoc::phase1::parser::parse_typedef() method did not correctly
recognize embedded structures.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0055
ENTRY_TITLE: ccdoc generates default special members for C style structs 
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/20
ENTRY_REPORTED_BEGIN:
Ccdoc should never create default special members (constructor, destructor,
operator=) for structs in C programs, since there is no such thing in C.
<hr>
<i>
This is true. Unfortunately, ccdoc does not officially support C.
</i>
<p>
<i>
Perhaps this problem can be solved in another way by allowing 
you to specify -nocdsm in phase1 for certain files. 
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Client has a workaround. I will re-open this issue if I get additional
requests.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0056
ENTRY_TITLE: Incorrect line numbers reported in warning messages. 
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
Try this:
<pre>
---[ccdoctest.h]---
/** @pkg ccdocTest */

int x;
</pre>
Ccdoc will say, that x is in ccdoctest.h:4, but it is in ccdoctest.h:3.
It seems to me, that the extra 1 line number is related somehow to the ccdoc
comment.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34, verified by test 13.
<p>
This was extremely tricky because the line numbers were correct most
of the time so it was hard to find a test case. The only time they
were incorrect were when the first line of the file had a ccdoc
directive that required a push/pop of the tokens that included the
new line.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0057
ENTRY_TITLE: "Undocumented" as default short desc. in tables is confusing.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/21
ENTRY_REPORTED_BEGIN:
"Undocumented", the default short description can be confusing in HTML
tables when most entries have a short description, since "Undocumented"
entries can be easily overlooked. I think the solution is to give switch to
override this text, then I can replace it with "-".
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Ccdoc already supports this. 
The resolution is described in detail in issue <a href="#TAG_0058">0058</a>.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0058
ENTRY_TITLE: Provide a way to turn off the default author and version for packages.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/21
ENTRY_REPORTED_BEGIN:
Reporting unascribed as the default package author and reporting version as
unknown is not so useful in some projects, since we do it on package level.
Perhaps -[no]rptdnpa and -[no]rptdnpd, where np is for non-package entity?
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Ccdoc provides a mechanism for turning off the default author and version
for any package by allowing the client to specify them explicitly. The
technique for doing this is to create a text file with entries for each
property. That file could look something like this:
<blockquote>
<pre>
// Create empty entries for packages to avoid using the defaults.
/**
 * &amp;nbsp;
 * @author &amp;nbsp;
 * @version &amp;nbsp;
 * @pkgdoc PKG1
 */
/**
 * &amp;nbsp;
 * @author &amp;nbsp;
 * @version &amp;nbsp;
 * @pkgdoc PKG1::SUBPKG1
 */
/**
 * &amp;nbsp;
 * @author &amp;nbsp;
 * @version &amp;nbsp;
 * @pkgdoc PKG1::SUBPKG2
 */
</pre>
</blockquote>
This file would be added to the phase 1 flow as follows:
<blockquote>
<pre>
ccdoc -db $CCDOC_DATABASE pkgdoc.txt
</pre>
</blockquote>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0059
ENTRY_TITLE: Validate ccdoc generated HTML.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/20
ENTRY_REPORTED_BEGIN:
You can use the verifier at <a href="http://validator.w3.org">http://validator.w3.org</a> to find errors in ccdoc generated output.
<hr>
<i>Thank you for a great suggestion! I never knew that an HTML
verifier existed.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Modified the ccdoc output to conform to the HTML 4.01 Transitional
specification.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0060
ENTRY_TITLE: Group entries by type.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/20
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
In many situations it's very bad, that all entities are droped into one big
list, you know, under the "Contents" tite, like this:
<blockquote>
<pre>
CONTENTS

Entry    Type Scope Shor Description
b    function ...
c    macro ...
d    function ...
e    package ...
f    macro ...
</pre>
</blockquote>
This would be much better in many cases:
<blockquote>
<pre>
CONTENTS


Packages

Entry    Type Scope Short Description
e    package ...


Functions

Entry    Type Scope Short Description
b    function ...
d    function ...


Macros

Entry    Type Scope Short Description
c    macro ...
f    macro ...
</pre>
</blockquote>
<p>
A switch like -[no]grpbytype? I don't hink so, cos it's not enough generic
(E.g. maybe an alphabetical index is required too). I think the real
solution is to allow user to specify any number of tables, with custom
grouping and title. Something like this:
<blockquote>
<pre>
$ ccdoc ...  -table(type) "Contents" -table() "Index" ...
(Note that I have skipped unimportant parts with ellipsis)
</pre>
</blockquote>
It would generate two tables: one with title "Contents" and with grouping by
entity type, and below another table with title "Index" without grouping
(just an alphabetiacal index, like the table in the current version). I put
the grouping condition into parenthesis to allow multi-level grouping for
future developmens, like -contents(type,functionality).
<hr>
<i>This is an interesting suggestion. The previous version of ccdoc did use
to group by entity. I will revisit that decision.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0061
ENTRY_TITLE: Typedef struct statement does not include struct comments.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/23
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
The fix for issue <a href="#TAG_0054">0054</a> only recognizes ccdoc
style comments for the typedef, not for the structure.
<hr>
<i>
This occurs because ccdoc only associates comments with statements.
</i>
<p>
<i>
In this case there is only one statement but it is clear that it could
be broken into the struct definition and the typedef.
It might be possible to modify ccdoc with a heuristic that recognizes this
construct and breaks it into two.
</i>
<p>
<i>
This is a low priority enhancement because this syntax is C artifact that
is not necessary in C++ because the struct [name] declares [name] as a type.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0062
ENTRY_TITLE: Long entry name deforms HTML table.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/23
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Just an idea: Long entry name stretches the first column too much. In
the worst case it makes the "Contents" table unusable, since it
stretches the first column so much that there will be no sufficient
space for the short description.
<p>
A possible solution is to give a
switch to specify the maximum entry name length, then break long names
into two (or three, etc...) with an "\\&lt;br&gt;\\" in the HTML (to
be more precise, with '\\&lt;/a&gt;&lt;br&gt;' + indent*'&amp;nbsp;' +
'&lt;a href="' + relpath + '"&gt;\\' (two backslash in the HTML
output, not C escaping of one backslash...))
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0063
ENTRY_TITLE: Allow user defined defaults for author, short description and version.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/09/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/24
ENTRY_REPORTED_BEGIN:
Reporting unascribed as the default package author and reporting version as
unknown is not so useful in some projects, since we do it on package level.
Perhaps -[no]rptdnpa and -[no]rptdnpd, where np is for non-package entity?
<hr>
<i>
This is what issues <a href="#TAG_0058">0058</a> and <a
href="#TAG_0058">0059</a> were originally supposed to address.  I
misinterpreted the request and addressed the wrong problem.
</i>
<p>
<i>
I believe that the correct way to address the problem is to allow the
user to specify their own default strings for author, version and short
description types using new switches: -rptdefa, -rptdefsd and
rptdefv.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r20.
<p>
Added:
<ul>
<li>-rptdefa &lt;default_author&gt;
<li>-rptdefasd &lt;default_autogen_short_desc&gt;
<li>-rptdefsd &lt;default_short_desc&gt;
<li>-rptdefv &lt;default_version&gt;
</ul>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0064
ENTRY_TITLE: Friend classes in namespaces are not recognized correctly.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/09/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/26
ENTRY_REPORTED_BEGIN:
<p>
Code Sample:
<blockquote>
<pre>
namespace nms  {

    class some_class
    {
       public:
         void some_class();
    };

    class some_other_class
    {
       /** Red, but not linked */
       friend class some_class;
       public:
         void some_other_class();
    };
}
</pre>
</blockquote>
<hr>
<i>
Ccdoc does not resolve scoped identifiers (because it does not process
included header files that may contain "using" statements). This means that
the user must be explicitly specify the full scope of an identifier.
</i>
<p>
<i>
In this particular case, I can modify ccdoc to try looking in the parents
namespace it the id is not found.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r21.
<p>
Modified ccdoc:phase3::html::write_friends_info to look in the namespace
of the parent to resolve unresolved names. Unfortunately this will not
work for all cases. The best solution is to always fully qualify scoped
names.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0065
ENTRY_TITLE: Links from documentation in namespaces are not recognized correctly.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/09/25
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/25
ENTRY_REPORTED_BEGIN:
Code Sample:
<blockquote>
<pre>
namespace nms  {

  class some_class
  {
     public:
       void some_class();
  };

  /** 
   * Some description
   * 
   * Red, but not linked:
   * @$ some_class
   * and "see also" have same problem.
   * @see some_class
   */
  
  class some_other_class
  {
     public:
       void some_other_class();
  };
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Ccdoc does not resolve scoped identifiers (because it does not process
included header files that may contain "using" statements). This means that
the user must be explicitly specify the full scope of an identifier
as shown below.
<blockquote>
<pre>
namespace nms  {

  class some_class
  {
     public:
       void some_class();
  };

  /** 
   * Some description
   * 
   * Red, but not linked:
   * @$ <b>nms::</b>some_class
   * and "see also" have same problem.
   * @see <b>nms::</b>some_class
   */
  
  class some_other_class
  {
     public:
       void some_other_class();
  };
}
</pre>
</blockquote>
<p>
I added fix that will resolve partially scoped references in most cases. See issue
<a href="#TAG_0118">0118</a> for details.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0066
ENTRY_TITLE: The &lt;sstream&gt; header is not needed in phase3_html.cc.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/09/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/09/27
ENTRY_REPORTED_BEGIN:
The &lt;sstream&gt; header is not needed in phase3_html.cc.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r21.r
<p>
You are absolutely correct. The &lt;sstream&gt; header is not needed.
<p>
Earlier I was using stringstreams but had a porting problem and had to
remove them. When I did that I neglected to remove the header file.
<p>
Thanks for pointing it out.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0067
ENTRY_TITLE: Ccdoc does not correctly reset the access specifiers for methods in base classes that are derived as protected or private.
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/10/01
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Code Sample:
<blockquote>
<pre>
  class some_base_class
  {
     public:
       /** Must be reported as "protected" in some_class_01 and
         * as "private" in some_class_02, but reported as "public" */
       void some_public_method();
     protected:
       /** Must be reported as "protected" in some_class_01 and
         * as "private" in some_class_02, but reported as "protected" */
       void some_protected_method();
  };

  class some_class_01 : protected some_base_class {};
  class some_class_02 : private some_base_class   {};
</pre>
</blockquote>
<hr>
<i>
Ccdoc always reports methods as they appear in the original class
specification and expects the user to understand how the access-specification
changes if protected or private inheritance is used.
</i>
<p>
<i>
This may be difficult for many users. I will look into changing this
behavior or making it optional via a switch.
Meanwhile, if you don't want the users to see the methods, you can work
around this as follows:
</i>
<blockquote>
<pre>
  class some_base_class
  {
     public:
       /** Must be reported as "protected" in some_class_01 and
         * as "private" in some_class_02, but reported as "public" */
       void some_public_method();
     protected:
       /** Must be reported as "protected" in some_class_01 and
         * as "private" in some_class_02, but reported as "protected" */
       void some_protected_method();
  };

  class some_class_01
<b>#if !defined(__ccdoc__)</b>
   : protected some_base_class
<b>#endif</b>
    {};
  class some_class_02
<b>#if !defined(__ccdoc__)</b>
   : private some_base_class
<b>#endif</b>
    {};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0068
ENTRY_TITLE: Core dump on solaris in the index phase.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/10/01
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/01
ENTRY_REPORTED_BEGIN:
Under certain conditions a core dump is generated during the index
phase for ccdoc r20.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r21.
<p>
This problem occurred because phase2 was deleting statements without
removing them from the load map in the database object. This caused a
bad pointer to be referenced under certain conditions. This bad
pointer caused the core dump on solaris.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0069
ENTRY_TITLE: Cannot handle construct: "Float operator/(const Float & rval)"
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Gustavsson Mrten</a>
ENTRY_REPORTED_ON: 2001/10/04
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/08
ENTRY_REPORTED_BEGIN:
Ccdoc cannot handle the construct:
<blockquote>
<pre>
Float operator/(const Float & rval)
</pre>
</blockquote>
You can work around this problem by inserting a space after the forward slash as follows:
<blockquote>
<pre>
Float operator/ (const Float & rval)
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r22.
<p>
There was a bug in ccdoc::phase1::scanner::scan_token() for processing
forward slash tokens. When the scanner looked ahead and failed, it
did not reset the next character properly. The problem was easily
fixed by resetting the next character properly. This occurred around
line 506 in phase1_scanner.cc 1.8. Test 29 was added to verify the fix.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0070
ENTRY_TITLE: Users guide documentation error.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Gustavsson Mrten</a>
ENTRY_REPORTED_ON: 2001/10/04
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/08
ENTRY_REPORTED_BEGIN:
By the way, the following section in the user documentation contains an error: 
<blockquote>
<h3>Directive: /**@#-*/, /**@#+*/ </h3>
<blockquote>
Turns ccdoc token processing off and on. They are useful for turn off processing for 
tokens on a line. For whole lines, use the __ccdoc__ compiler pragma as shown in the 
example below:
<blockquote>
<pre>
// Turn off sections of code using __ccdoc__ 
#if defined(__ccdoc__) 
  // Ignore stuff until the end 
#endif 
</pre>
</blockquote>
</blockquote>
</blockquote>
It should be: 
<blockquote>
<pre>
#if !defined(__ccdoc__) 
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r22.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0071
ENTRY_TITLE: Operator keyword duplicated for method operators.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/10/08
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/08
ENTRY_REPORTED_BEGIN:
Operator keyword duplicated for method operators.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
.
<p>
There was a bug in ccdoc::phase3::html::write_section_header for recognizing
method operators for creating titles. It was not checking for 
statement::base::STMT_METHOD_OPERATOR when creating the title.
<p>
This is verified by test19.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0072
ENTRY_TITLE: New switch to turn off sorting of class entities.
ENTRY_REPORTED_BY: <a href="mailto:Michael.Wang@cibc.ca">Michael Wang</a>
ENTRY_REPORTED_ON: 2001/10/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/12
ENTRY_REPORTED_BEGIN:
I would like to see a switch that allows the user to turn off output
ordering/sorting so that the listing of methods/functions can be
dictated by the programmer.
<hr>
<i>
After some additional communication the specific functionality was
refined to: add a new switch that turns off the sorting of class entities.
Specifically it refers to the methods, variables, enumerations and typedefs
inside of a class.
</i>
<p>
<i>
In keeping with the current naming convention this switch should be
called something like -rptdsfce (disable sorting for class entities).
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r22.
<p>
Added two new switches: -rptsci and -norptsci to allow the user to
control the sorting of class information. The default is -rptsci.
If -norptcsi is specified the class contents and details are not sorted.
<p>
The idea is that programmers may wish to logically organize class
information in a way that is more understandable than a simple
sort.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0073
ENTRY_TITLE: Can't tell ccdoc to ignore a privately declared default constructor.
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/10/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/12
ENTRY_REPORTED_BEGIN:
When I create a class with a private default constructor ccdoc still
reports it. Here is an example:
<blockquote>
<pre>
class A {
private:
  A(); // ccdoc always reports this
public:
  A(int);
};
</pre>
</blockquote>
<p>
I would like to see a directive that allows the user to turn off output
generation for a specific entity. This would allow me to tell ccdoc to
ignore the reporting of private default constructors on a per class
basis.
<hr>
<i>
I don't think that a new directive is needed to solve this problem. In fact,
I think it is a simple bug.
</i>
<p>
<i>
Ccdoc must be fixed to not report private entities (even those
generated by default) unless the -rptpri switch is specified.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r22.
<p>
Ccdoc will not report the methods and operators generated by
default if they are privately declared.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0074
ENTRY_TITLE: Ccdoc cannot handle international character sets.
ENTRY_REPORTED_BY: <a href="mailto:glassman_ru@geocities.com">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/10/12
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/12
ENTRY_REPORTED_BEGIN:
CCDoc inserts a generated html meta variable:
<blockquote>
<pre>
&lt;meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"&gt;
</pre>
</blockquote>
Please, provide any command line arguments for switching to user
specified charset.
<hr>
<i>
Thank you for pointing this out. The charset was added for compliance
with the HTML 4.01 Transitional specification (see issue
 <a href="#TAG_0059">0059</a>). 
</i>
<p>
<i>
I will add a switch that allows you to define your own character set
in the next release (probably on Monday).
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r22.
<p>
Added a new switch called -rptctcs that allows users to specify the
character set that they wish to use.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0075
ENTRY_TITLE: Ccdoc cannot handle function typedef of the form: typedef void fct(int arg1);
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/10/13
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/14
ENTRY_REPORTED_BEGIN:
Ccdoc cannot handle function typedef of the form: typedef void fct(int arg1);.
It reports arg1 as the typedef rather than fct.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r23. Verified by test33.
<p>
The phase1_parser did not understand this syntax correctly.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0076
ENTRY_TITLE: Conflict between -meta switch and ccdoc defined meta variables.
ENTRY_REPORTED_BY: <a href="mailto:ddekany@freemail.hu">Dkny Dniel</a>
ENTRY_REPORTED_ON: 2001/10/14
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/16
ENTRY_REPORTED_BEGIN:
There is a conflict between the -meta switch and the fact that ccdoc
automatically creates some meta-variables for HTML 4.01 compliance
because it does not allow users to override or change the ccdoc
generated meta variables.
<p>
If user gives a -meta switch, ccdoc must *not* generate standard meta
elements, like http-equiv-s or keyword-s. Generating ccdoc_... metas is OK.
<hr>
<i>
I completely agree. This is a well thought out criticism of the current
behavior. I will modify r23 to not generate standard meta elements if
the -meta switch is specified.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r23. Verified by test34.
<p>
Also added a warning if both -meta and -rptctcs are specified.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0077
ENTRY_TITLE: Ccdoc incorrectly identifies a class attribute name.
ENTRY_REPORTED_BY: <a href="mailto:cbauer@cidera-mainstream.com">Clint Bauer</a>
ENTRY_REPORTED_ON: 2001/10/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/19
ENTRY_REPORTED_BEGIN:
Ccdoc identifies the attribute name as BAR instead of m_foo:
<blockquote>
<pre>
class A {
public:
  char m_foo[BAR];
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r23. Verified by test35.
<p>
The variable id recognizer in ccdoc::phase1::parser::parse_var_or_fct
(phase1_parser.c) was confused by the square brackets.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0078
ENTRY_TITLE: Ccdoc incorrectly identifies a variable as a function.
ENTRY_REPORTED_BY: <a href="mailto:cbauer@cidera-mainstream.com">Clint Bauer</a>
ENTRY_REPORTED_ON: 2001/10/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/19
ENTRY_REPORTED_BEGIN:
Ccdoc incorrectly identifies a variable as a function in the following case:
<blockquote>
<pre>
const long is_not_a_function = (1+1);
</pre>
</blockquote>
If the parentheses are removed, ccdoc correctly identifies it as a variable.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r23. Verified by test36.
<p>
The function type recognizer in ccdoc::phase1::parser::parse_var_or_fct
(phase1_parser.c) was confused by the presence of parentheses after an
equals sign.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0079
ENTRY_TITLE: platform.pl cannot handle embedded parentheses.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Ben Zoe
ENTRY_RESOLVED_ON: 2001/10/24
ENTRY_REPORTED_BEGIN:
I use cygwin and it attaches a trailer build number in parentheses
which is an illegal path name.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24.
<p>
Ben added a line to filter out parentheses to platform.pl.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0080
ENTRY_TITLE: Trim trailing spaces in path name for get_stmt_no_pkgs().
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Ben Zoe
ENTRY_RESOLVED_ON: 2001/10/24
ENTRY_REPORTED_BEGIN:
If the path name has trailing spaces, the get_stmt_no_pkgs() may fail
unexpectedly.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #38.
<p>
Ben added code that will trim trailing white space. I modified it slightly
to include the \r white space character for PCs.
<p>
It looks like this problem can be tickled by @links with trailing spaces.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0081
ENTRY_TITLE: Multi-space blank lines between SHORT and LONG descriptions cause them to merge.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/24
ENTRY_REPORTED_BEGIN:
Multi-space blank lines between SHORT and LONG descriptions cause them
to merge.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
The current ccdoc behavior is correct.
Blanks are used to indicates lines in HTML &lt;pre&gt; clauses.
The fix that was described (testing for lines that
contain w/s) would fail to properly parse the following case:
<blockquote>
<pre>
/**
 * This is a short description with some code in it:
 * <pre>
 * // Whitespace test
 * 
 * </pre>
 *
 * This is the start of the long description.
 */
</pre>
</blockquote>
<p>
I am not sure that this resolution is correct because the ccdoc
short description does not conform to the javadoc specification.
See issue <a href="#TAG_0089">0089</a> for details.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0082
ENTRY_TITLE: Add the @since directive per the javadoc 1.2 specification.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Ben Zoe & Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
Add the @since directive per the javadoc specification.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #39.
<p>
This change invalidates old ccdoc db files.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0083
ENTRY_TITLE: Modify ccdoc to create a separate links page (as was done in v0.7a).
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/26
ENTRY_REPORTED_BEGIN:
When ccdoc see's multiple links to the same entities it creates a list. In
ccdoc v0.7a it created a separate page with the links. I like that approach
better.
<hr>
<i>
That is an intriguing idea. I will look into it in the near future.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #43.
<p>
Modified ccdoc to handle multiple links on a separate page. It is much
easier to read than the previous version. The main work was done in
the ccdoc::phase3::html::new write_links() method.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0084
ENTRY_TITLE: Alias @exception to @throws per javadoc 1.2.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Ben Zoe & Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
Alias @exception to @throws per javadoc 1.2.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #39.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0085
ENTRY_TITLE: Ccdoc not recognize default constructors with member initialization.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
Ccdoc not recognize default constructors with member initialization as shown
in the following example:
<blockquote>
<pre>
class A {
public:
  A() : x(0), y(0) {}
private:
  int x,y;
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #42.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0086
ENTRY_TITLE: Comment form to handle single line suffix comments.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Ben Zoe
ENTRY_RESOLVED_ON: 2001/11/25
ENTRY_REPORTED_BEGIN:
One another topic, I was looking for a way to do a one line ccdoc
comment for this type of suffix documentation:
<blockquote>
<pre>
class A
{
public:
  /** An int variable */
  int intVar;
 
  /** A long variable */
  long longVar;
};
</pre>
</blockquote>
as
<blockquote>
<pre>
class A
{
public:
  int   intVar;  //@- An int variable
  long  longVar; //@- A long Var
};
</pre>
</blockquote>
This is not a priority item. It probably has limited application. But I
personally have many files where a single short comment line to the
right of the documented item makes the file easier to read. I tried
finding a place to do this but stopped when it took too much time. I'll
keep at it when I some spare time.
<hr>
<i>
This is an interesting idea. Your idea of a //@- syntax makes sense.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 53.
<p>
Ben did all of the work to implement the changes to phase1_scanner.cc.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0087
ENTRY_TITLE: Exceptions were not reported as links.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/10/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
Ccdoc was not reporting links to exceptions in @exception and @throws
directives.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #39.
<p>
The code for resolving the exception class was not implemented in
ccdoc::phase3::html::write_ccdoc_exception_directive_info() (phase3_html.c).
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0088
ENTRY_TITLE: An extra invalid link reported for @link references to classes.
ENTRY_REPORTED_BY: <a href="mailto:bzoe@javtech.com">Ben Zoe</a>
ENTRY_REPORTED_ON: 2001/10/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
An extra invalid link reported for @link references to classes. The following
code fragment demonstrates the problem:
<blockquote>
<pre>
class A {
};
class B {
public:
  /**
   * Comment.
   * @link A
   */
  void fct();
};
</pre>
</blockquote>
The link will be reported as "link: A {A}" where the second link is invalid.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #39.
<p>
The STMT_CLASS_END statement (a dummy) was being reported as an invalid link.
This was corrected by adding ccdoc::phase3::html::find_and_write_links()
to detect and ignore end of class statements as well other send statements for
structs, unions and namespaces.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0089
ENTRY_TITLE: Ccdoc short description syntax is not compliant with javadoc.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/10/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
From the javadoc manual
 <a href="http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#generalform">http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#generalform</a>:
<blockquote>
<b>First Sentence</b><br>
The first sentence of each doc comment should be a summary sentence,
containing a concise but complete description of the API item. This
means the first sentence of each member, class, interface or package
description. The Javadoc tool copies this first sentence to the
appropriate member, class/interface or package summary. This makes it
important to write crisp and informative initial sentences that can
stand on their own.
<p>
This sentence ends at the first period that is followed by a blank,
tab, or line terminator, or at the first tag (as defined below). For
example, this first sentence ends at "Prof.":
<pre>
/**
  * This is a simulation of Prof. Knuth's MIX computer.
  */
</pre>
</blockquote>
Ccdoc doesnt handle first sentences according to javadoc
standard. I believe the summary is created from the first paragraph.
<p>
I think that there is a point in following the javadoc specification
as close as possible, the documentation is for free.
<hr>
<i>
This is an excellent point and I agree with your conclusion. My only
concern is that changing the existing behavior may adversely affect
users that depend on the current incorrect behavior.
</i>
<p>
<i>
I feel that the best solution is to modify ccdoc to conform to the javadoc
standard but provide a switch that allows the current behavior.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #40.
<p>
Changed the default behavior of ccdoc to conform to javadoc and added
two phase 1 switches: -[no]jdsds. The -jdsds (JavaDoc Short Description
Syntax) switch enables the javadoc behavior and is the default. The
-nojdsds switch enables the old behavior for backward compatibility.
<p>
<i>
Beware! This change will affect your output. Use the -nojdsds switch to
enable the old behavior.
</i>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0090
ENTRY_TITLE: Support the {@link ...} javadoc syntax.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/10/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/26
ENTRY_REPORTED_BEGIN:
Ccdoc does not support inline link references. It should be enhanced to
support the {@link ...} directive.
<p>
<i>
As an interesting aside, the @link directive in ccdoc was developed
independently of javadoc.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified in test #44.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0091
ENTRY_TITLE: Constant values are not hyperlinked in the documentation for function arguments.
ENTRY_REPORTED_BY: <a href="mailto:david_mcbride@notes.teradyne.com">David McBride</a>
ENTRY_REPORTED_ON: 2001/10/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/25
ENTRY_REPORTED_BEGIN:
I have a suggestion.  I've noticed that if an enum is a parameter in a
funtion, then a link gets created back to the enum definition.  That's
perfect.  However, it doesn't seem that the same is true for constants
defined either in the global or the class namespace (unless I'm
missing something).  It would be handy if ccdoc treated constants the
same as enums in this regard.
<p>
Example:
<blockquote>
<pre>
enum myEnum {..........};
const double myConstant = 30.0;
 
class myClass
{
public:
  void myFunct(myEnum fred, double ethel = myConstant);
}
</pre>
</blockquote>
ccdoc creates a link in myFunct at "myEnum" back to the definition of
"myEnum".  However, no link is created in myFunct at "myConstant".
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified by test #41.
<p>
The ccdoc::phase3::html::write_code_subsection_token() method
was not looking for variables or functions.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0092
ENTRY_TITLE: The @link syntax does not support the # scoping operator.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/10/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/10/26
ENTRY_REPORTED_BEGIN:
Ccdoc does not support the '#' scoping operator in @link directives.
It works correctly for @see directives.
The example below illustrates the problem.
<blockquote>
<pre>
class A {
public:
  void fct();
  /**
   * {@link #fct foo}
   * @link #fct
   * @see #fct
   */
  void fct1();
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r24. Verified in test #44.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0093
ENTRY_TITLE: Add javadoc style doc comment inheritance.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/01
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Javadoc has quite an advanced feature for doc comment inheritance, see
<a href="http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#inheritingcomments">http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#inheritingcomments</a>.
<p>
I would very much appreciate doc comment inheritance, prefferably
according to javadoc 1.4. Javadoc 1.3
(<a href="http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javadoc.html#inheritingcomments">http://java.sun.com/j2se/1.3/docs/tooldocs/win32/javadoc.html#inheritingcomments</a>)
is not so advanced but would be quite useful also.
<hr>
<i>
This is an excellent idea. I will look into how feasible it is for
ccdoc. The only issue is how well ccdoc can recognize these relationships.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0094
ENTRY_TITLE: Comment reuse for overloaded functions.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/01
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Previously I suggested that you implement doc comment inheritance. If
you decide to do so I have another suggestion.
<p>
I believe that the javadoc rules says that a method must override a
method in the ancestor class to reuse a doc comment. Doc comments
cannot be reused for constructors, destructors etc.
<p>
I find it quite tedious to write doc comments for constructors and
destructors. It would save a lot of typing if one could reuse doc
comments beween them.
<p>
I can see that the implementation can be difficult, but there is
another enhancement that could simplify a lot. Lets call it doc
comment reuse of overloaded functions. There is no such thing in
javadoc, but maybe there should be. I have read the javadoc spec over
and over since I really believed there was such a rule, but there is
no rule.
<h4>Doc comment reuse of overloaded functions</h4>
If an overloaded member function does not have a doc comment, and
placed after a function it overloads, it will inherit the doc comment
of that function. The names of the parameters of the overloaded
functions must be same, only types may vary.
<p>
The result is that one only needs to document the first function in a
group of overloaded functions.
<h4>Doc comment reuse of constuctors etc</h4>
Hope that you will excuse me doing specification by example: 
If a member function (constructor, destructor, etc) uses the class
name itself in the parameter list, a second "invisible" function is
generated, replacing the current class name with a superficial
"this". Using the superficial type "this" is good because it is a
reserved word in C++ preventing any real class to be defined.
<p>
If the original function has a doc comment the generated function will
be placed after the original one, inheriting its doc comment using the
rule for overloaded functions.
<p>
If the original function doesn't have a doc comment, the generated one
will be placed before the original one, allowing the original one to
inherit from the generated one using the rule for overloaded
functions.
<p>
A code example: 
<blockquote>
<pre>
class Base 
{ 
        /** Default construcor */ 
        Base(); 
        /** 
         * Copy constructor. 
         * 
         * @param src   is the object to copy from 
         */ 
        Base(const Base &src); 
        /** Destructor */ 
        ~Base(); 
        /** 
         * Assignment operator. 
         * 
         * @param src   is the object to copy from 
         * @return              a const reference to this object 
         */ 
        const Base& operator=(const Base& src); 
} // class Base 

class Derived : public Base 
{ 
        Derived(); // inherit doc comment 
        Derived(const Derived &src); // inherit doc comment 
        ~Derived(); // inherit doc comment 
        const Derived& operator=(const Derived & src); // inherit doc comment 
        /** 
         * Strange copy constructor that slices the object. 
         * 
         * @param src   is the base class object to copy from 
         */ 
        Derived(const Base &src); 
} // class Derived 
</pre>
</blockquote>
Theses classes will internally be represented as something like this: 
<blockquote>
<pre>
class Base 
{ 
        /** Default construcor */ 
        Base(); 
        this(); // inherit doc comment from previous using overload rule 
        /** 
         * Copy constructor. 
         * 
         * @param src   is the object to copy from 
         */ 
        Base(const Base &src); 
        this(const this &src);// inherit doc comment from previous using overload rule 
        /** Destructor */ 
        ~Base(); 
        ~this();// inherit doc comment from previous using overload rule 
        /** 
         * Assignment operator. 
         * 
         * @param src   is the object to copy from 
         * @return              a const reference to this object 
         */ 
        const Base& operator=(const Base& src); 
        const this& operator=(const this& src);// inherit doc comment from previous using overload rule 
} // class Base 

class Derived : public Base 
{ 
        this(const this &src); // this one will pick up doc comment from base class 
        Derived(); // inherit doc comment from previous using overload rule 
        this(const this &src); // this one will pick up doc comment from base class 
        Derived(const Derived &src); // inherit doc comment from previous using overload rule 
        ~this(); // this one will pick up doc comment from base class 
        ~Derived(); // inherit doc comment from previous using overload rule 
        const this& operator=(const this& src); // this one will pick up doc comment from base class 
        const Derived& operator=(const Derived & src); // inherit doc comment from previous using overload rule 
        /** 
         * Strange copy constructor that slices the object. 
         * 
         * @param src   is the base class object to copy from 
         */ 
        Derived(const Base &src); 
} // class Derived 
</pre>
</blockquote>
<hr>
<i>
I really like this idea. I will look into how feasible it is for
ccdoc. The only issue is how well ccdoc can recognize these relationships.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0095
ENTRY_TITLE: Comma's inserted for each line in @returns and @deprecated comments.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/11/02
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/02
ENTRY_REPORTED_BEGIN:
Ccdoc inserts comma's for each new line in an @returns comment.
The example below illustrates the problem:
<blockquote>
<pre>
/**
 * Returns bug?
 * @returns Are extra
 * comma's inserted
 * at each
 * new line?
 */
void fct();
</pre>
</blockquote>
The output looks like this:
<blockquote>
<i>
Are extra , comma's inserted , at each , new line?
</i>
</blockquote>
<hr>
<i>
The workaround is to wrap the comment so there are no newlines.
This will be fixed in r25.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25. Verified by test #45.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0096
ENTRY_TITLE: Provide an @repeat operator to avoid having to re-type comments.
ENTRY_REPORTED_BY: <a href="mailto:david_mcbride@notes.teradyne.com">David McBride</a>
ENTRY_REPORTED_ON: 2001/11/02
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
As you know, if you have a set of overloaded functions, they often perform
essentially the same function, and could be described by the same ccdoc
comment.  Therefore, it would be handy to have a tag that would tell ccdoc
to apply the comment attached to the previous method to the current method.
For example:
<blockquote>
<pre>
class MyClass {
public:
     /**
     * Performs some useful function. blah blah blah.
     * Some long, involved explanation that I don't
     * want to repeat over and over again.
     * @param someVar Some user defined variable.
     * @returns Returns 0 if successful or not 0 otherwise.
     */
     void myOverloadedFunct(A* someVar);

     /**
     @repeat
     */
     void myOverloadedFunct(B* someVar);

     /**
     @repeat
     */
     void myOverloadedFunct(C* someVar);

     /**
     @repeat
     */
     void myOverloadedFunct(D* someVar);

     /**
     @repeat
     */
     void myOverloadedFunct(E* someVar);
}
</pre>
</blockquote>
<hr>
<i>
This is an interesting suggestion. I believe that it relates to 
issues</i>
 <a href="#TAG_0093"><i>0093</i></a><i> and </i>
 <a href="#TAG_0094"><i>0094</i></a>.
<i>
They are all trying to address the problem of
having to type redundant comments.
I am actively looking into this.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0097
ENTRY_TITLE: Private method is reported incorrectly for overloaded methods with different scopes.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/11/02
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/12
ENTRY_REPORTED_BEGIN:
Private method is reported incorrectly for overloaded methods with
different scopes. The following example illustrates the case.
<blockquote>
<pre>
class A {
public:
  void fct();
private:
  void fct();
};
</pre>
</blockquote>
The private void fct shows up in the list.
<hr>
<i>
The workaround is to tell ccdoc to ignore the private function using the
__ccdoc__ pragma. This will be fixed in r25.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25. Verified by test #46.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0098
ENTRY_TITLE: It would be a help if you made the reference red if the class cannot be found for @link.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/09
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
It would be a help if you made the reference red if the class cannot be found for @link.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34, verified by test 73.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0099
ENTRY_TITLE: Ccdoc does not correctly follow the standard for default constructors.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/09
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/28
ENTRY_REPORTED_BEGIN:
A default constructor is implicitly defined if there are no
constructors defined for a class. If a copy constructor is the only
constructor defined there will be no default (implicitly defined)
constructor and the class will be unusable. Trying to instasiate such
a class will cause a compilation error. I believe that the implicitly
defined default constructor is there to achieve compatibility with C
structs.
<p>
ccdoc generates a default constructor entry if there is no default
constructor defined. This is not according to C++ standard. I suggest
that you change ccdoc to only generate documentation for implicitly
defined default constructors if there are no constructors defined in
the class.
<p>
Also if you call generated member functions "implicitly defined" this
will improve understanding since it will adhere to C++ lingo.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 55.
<p>
Modified special member processing to recognize when any constructor
is declared so that it can turn off the generation of the default
constructor correctly.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0100
ENTRY_TITLE: If using switch -files with a wildcard expression the first file is not processed.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/09
ENTRY_STATUS: CLOSED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/12
ENTRY_REPORTED_BEGIN:
I saw in the issue list that someone has a problem with gnuwin32. If
using switch -files with a wildcard expression the first file is not
processed. No problem if removing the -files switch.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
The first file is not really ignored because the ccdoc expects it to contain a list
of files to process. When it doesn't find any files it goes on to the other entries
on the command line.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0101
ENTRY_TITLE: Template problem.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/09
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/27
ENTRY_REPORTED_BEGIN:
The following code 
<pre>
    template&lt;class VALUE_TYPE&gt; class Prompt : public Component  
    { 
    public: 
        /** 
         * Reads from the instream to an object and returns a reference to it. 
         * First, a text defined in the constructor is written to the ostream defined 
         * in the constructor. Then the instream defined in the constructor is 
         * read to the internal object, using operator&gt;&gt;(). A reference to the 
         * internal object is returned. 
         */ 
        Input&lt; ReturnPrimitiveInterface&lt;const VALUE_TYPE&, const Event&&gt; &gt; in; 
</pre>
generates this output: 
<pre>
attribute const ? ^ &lt; &gt;        
Undocumented 

   Source: 

      metaf/src/components/io/Prompt.h:52 

   Code: 

      public Input &lt; ReturnPrimitiveInterface &lt; const VALUE_TYPE const Event & &gt; &gt; in 
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified in test 54.
<p>
The variable recognition heuristic in phase1::parser::parse_var_or_fct did
not correctly recognize template arguments.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0102
ENTRY_TITLE: Returned nested classes and types in namespaces are not recognized correctly.
ENTRY_REPORTED_BY: <a href="mailto:glassman_ru@geocities.com">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/11/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/26
ENTRY_REPORTED_BEGIN:
Returned nested classes and types in namespaces are not recognized correctly.
<p>
Code Sample:
<blockquote>
<pre>
namespace nms {
class some_class
{
   public:
     typedef int nested_type;
     class nested_class {};
};
<br>
class another_class
{
   public:
     /** Linked correctly */
     some_class get_some_class();
     /** Not linked correctly */
     some_class::nested_type  get_nested_type();
     /** Not linked correctly */
     some_class::nested_class get_nested_type();
};
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 52.
<p>
See issue <a href="#TAG_0118">0118</a> for more details.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0103
ENTRY_TITLE: Invalid processing of operator~().
ENTRY_REPORTED_BY: <a href="mailto:glassman_ru@geocities.com">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/11/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/12
ENTRY_REPORTED_BEGIN:
Sample code:
<blockquote>
<pre>
class some_class
{
  public:
    some_class operator~();
};
</pre>
</blockquote>
<p>
CCDoc output:
<blockquote>
<pre>
~    operator public undocumented
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25. Verified by test #47.
<p>
The ccdoc::phase1::parser::get_fct_id() method was being called for
operators.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0104
ENTRY_TITLE: Invalid processing of operator&amp;().
ENTRY_REPORTED_BY: <a href="mailto:glassman_ru@geocities.com">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/11/10
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/12
ENTRY_REPORTED_BEGIN:
Sample code:
<blockquote>
<pre>
class some_class
{
  public:
    some_class operator&amp;( const some_class&amp; );
};
</pre>
</blockquote>
CCDoc output:
<blockquote>
<pre>
some_classoperator & operator public undocumented
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25. Verified by test #47.
<p>
The ccdoc::phase1::parser::get_fct_id() method was being called for
operators.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0105
ENTRY_TITLE: The javadoc @see tag defines the label part as optional.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/08
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
The javadoc @see tag defines the label part as optional: 
<a href="http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#@see">http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#@see</a>
<p>
If you decide to do the label optional, javadoc specifies how to generate the link: 
<a href="http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#shortened">http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#shortened</a>
<p>
I dont feel that this improvement is very important, but if you like
the idea put it on the issue list and maybe implement it if there is
time and no more important things to do.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0106
ENTRY_TITLE: The javadoc spec for @see allows unqualified names as well as qualified names.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/08
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
The javadoc spec for @see allows unqualified names as well as
qualified names:
<a href="http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#seesearchorder">http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#seesearchorder</a>
<p>
I believe that ccdoc requires a fully qualified c++ class name if the
reference is to another class. The javadoc spec relies on rules
including the java compiler and I dont believe that following their
search patterns will add that much.
<p>
However, it would be nice if the @see tag accepts valid c++ class
names. Leaving out the namespace part if the referencing class belongs
to the same namespace as the referenced class would be an improvement.
<p>
I dont think this improvement is very important since namespaces are
quite short compared to java packages.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0107
ENTRY_TITLE: javadoc # syntax is not supported in the {@link...} directive.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/08
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
It seems like it isnt possible to link to a member function in another class. Example from my code: 
 * {@link metaf::ComAbstractGetAdoRecord#get_one_record ComAbstractGetAdoRecord::get_one_record()} 
<p>
Javadoc allows this construct: 
<a href="http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#@see">http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#@see</a>
<p>
The syntax would be quite useful.
<hr>
<i>
Thanks for all of your suggestions. I am still processing them but I
wanted to respond to this issue quickly because it might help you.
</i>
<p> 
<i>
It turns out that ccdoc does allow you to reference member functions
but it doesn't use the javadoc syntax, you must use a '::' separator
as shown in the following example.
</i>
<pre>
     class A {
     public:
       void fct();
     };
     class B {
     public:
       /**
        * See the {@link A::fct fct} for additional details.
        * @see A::fct
        */
       void bar();
     };
</pre>
<i>
I completely agree that ccdoc should support the javadoc syntax and
will schedule this fix for the next release.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0108
ENTRY_TITLE: -rptdefasd, -rptdefsd and -rptdefv problems and suggestions
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/08
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I am playing around with the switches -rptdefasd, -rptdefsd and
-rptdefv, the intention to mark the text red "<font
color=red>Undocumented</font>" in order to find missing documentation
and implicitly defined member funcions.
<p>
For the implicitly defined member funcions I want the text "Implicitly
defined", and for things that I forgot to document "Undocumented", the
switches used:
<p>
-rptdefasd "<font color=red>Implicitly defined</font>" -rptdefsd "<font color=red>Undocumented</font>" 
This causes the class documentation look just like I want. However, I have found the following errors: 
<ul>
<li>-rptdefsd, documentation error, the default text is
"undocumented", not "automatically generated". Documentation is
exactly as for switch -rptdefasd, did you forget to edit after copy?
<li>-rptdefv, this switch sets the default text for missing version
information, documentation says something completely
different. Default text is "unknown", not "undocumented"
</ul>
The switches I am quite happy with: 
-rptdefa "<font color=red>Unascribed</font>" -rptdefasd "<font color=red>Implicitly defined</font>" -rptdefsd "<font
color=red>Undocumented</font>" -rptdefv "<font color=red>Unknown</font>"
<p>
And some suggestions: 
<ul>
<li>The generated documentation has only one little problem,
undocumented packages are reported "Implicitly defined" on the index
pages. I suggest that you use the switch -rptdefsd instead of
-rptdefasd for missing package documentation.
<li>In order to find all possible problems with the documentation,
mark the text red
</ul>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0109
ENTRY_TITLE: Print warnings to stderr.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Mrten Gustavsson</a>
ENTRY_REPORTED_ON: 2001/11/08
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/02/18
ENTRY_REPORTED_BEGIN:
Marking stuff with problems with red is great. You can mark even more,
like missing default constructors, copy constructors and other things
automatically generated. Another thing to warn for is destructors not
being virtual. Im my experience a missing copy constructor, for a
class with pointers in it, combined with a missing * or & in a
function call will corrupt memory. I have spent days looking for such
errors in my code. When starting doing C I found lint to be an
exellent tool to identify problematic code.
<p>
If the programmers intention is for C++ to automatically generate a
constructor, there should be something in the documentation telling
this, prefferably as a doc comment. If so there should be no red
warning text.
<p>
Since I have so many classes, I find it tedious to click through all
genereated html to find problematic links. I suggest that you also
print warning messages to stderr. Finding the problems will be much
faster.
<p>
If you decide to implement warnings for dangerous C++ constructs I
guess that your user community will come up with even more ideas if
asked.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34, verified by test 73.
<p>
Added warning messages for all conditions that trigger red in the
HTML code.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0110
ENTRY_TITLE: Invalid processing of operator[].
ENTRY_REPORTED_BY: <a href="mailto:lou.sanchez-chopitea@xilinx.com">Lou Sanchez-Chopitea</a>
ENTRY_REPORTED_ON: 2001/11/16
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/12
ENTRY_REPORTED_BEGIN:
Invalid processing of operator~[]. This is exactly the same problem as
issues <a href="#TAG_0103">0103</a> and <a href="#TAG_0104">0104</a>.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0111
ENTRY_TITLE: Multiple link file overflow problem.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/11/16
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/17
ENTRY_REPORTED_BEGIN:
I ran across a problem where multiple links caused too many files to be
generated.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25.
<p>
The problem was fixed by re-using common link files.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0112
ENTRY_TITLE: Phase 3 exception for operator|.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/11/19
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/19
ENTRY_REPORTED_BEGIN:
Operator | clauses cause an exception to be generated in phase3.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r25. Verified by test48.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0113
ENTRY_TITLE: Merge separate ccdoc databases.
ENTRY_REPORTED_BY: <a href="mailto:John.Rostykus@xilinx.com">John Rostykus</a>
ENTRY_REPORTED_ON: 2001/11/20
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
On a related note, I would like to talk to you about possibly
supporting a feature in ccdoc to merge databases.  We could really
parallelize the process if we were not limited to having every ccdoc
process write to the same database.  For example, run the header
processing on each of the 50 or so subsystems individually in
parallel, run a (new) step to merge the resulting databases into 1,
and then do the index/html steps.  Does ccdoc have any capability like
this?  If not, what do you think of this idea?  In general, long
processes that are single threaded are what kill our build times, and
ccdoc (the way we use it) at ~1 hour is in that camp.
<hr>
<i>I think that this is very interesting idea that shouldn't be too
difficult. I will look into it for the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0114
ENTRY_TITLE: Error processing of a operator unsigned long().
ENTRY_REPORTED_BY: <a href="mailto:glass@cholod.ru">Dmitry A.Steklenev</a>
ENTRY_REPORTED_ON: 2001/11/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/26
ENTRY_REPORTED_BEGIN:
Error processing of a operator unsigned long().
<p>
Sample code:
<blockquote>
<pre>
class some_class
{
  public:
    some_class operator unsigned long();
}
</pre>
</blockquote>
CCDoc output:
<blockquote>
<pre>
operator unsignedlong operator public undocumented
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test49.
<p>
There was a name munging heuristic in the phase1::parser that collapsed
operators like [] and (). It wasn't checking for cast operator entries
like "unsigned long".
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0115
ENTRY_TITLE: Mangled links for .\doc\ references on the command line.
ENTRY_REPORTED_BY: <a href="mailto:Richard.Cooper@youmeus.com">Richard Cooper</a>
ENTRY_REPORTED_ON: 2001/11/22
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/27
ENTRY_REPORTED_BEGIN:
Running ccdoc with the following command line produces documentation with
mangled links. The documents are in .\doc but the hyperlinks link to
.\doc\doc
<blockquote>
<pre>
ccdoc -db docs.db -html .\doc\ ..\Headers\*.h
</pre>
</blockquote>
The system works fine if I do the following but as this will be part of an
automatic process I don't want to.
<blockquote>
<pre>
cd .\doc
ccdoc -db docs.db -html .\ ..\..\Headers\*.h
</pre>
</blockquote>
It also works if I move the doc directory to the same level as the Headers
directory
<blockquote>
<pre>
ccdoc -db docs.db -html ..\doc\ ..\Headers\*.h
</pre>
</blockquote>
but not if I move it further up
<blockquote>
<pre>
ccdoc -db docs.db -html ..\..\doc\ ..\Headers\*.h
</pre>
</blockquote>
<hr>
<i>
The problem that you encountered with the -html .\ specification arose
because ccdoc uses the -html specification to generate URLs and the
backslash is not supported as an HTTP path specifier.
</i>
<p>
<i>
You can fix the problems that you were having by replacing the
backslashes with forward slashes. Ccdoc will figure out the correct
DOS path and the URL will work.
</i>
<p>
<i>
I apologize for not making this clear in the users guide. I will
update the information and close out this issue if this works for
you. If I don't hear from you by tommorrow (Nov 27) I will assume that
things are working for you.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Updated the documentation to reflect the requirement that -html path
specifications must use forward slashes on all platforms (even DOS).
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0116
ENTRY_TITLE: The string constant "\\" isn't parsed correctly.
ENTRY_REPORTED_BY: <a href="mailto:chris@sapphyr.com">Chris Martin</a>
ENTRY_REPORTED_ON: 2001/11/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Chris Martin
ENTRY_RESOLVED_ON: 2001/11/25
ENTRY_REPORTED_BEGIN:
The string constant "\\" isn't parsed correctly; resulting in a spurious
"unterminated string literal" warning.
<p>
Fix:
<blockquote>
<pre>
void ccdoc::phase1::scanner::get_string_literal(char* token,int max)
{
   int ch = '"';
   int pch = ch;
   while( max>0 && (ch = get_char()) ) {
     max--;
     *token++ = ch;
     if( ch == '"' && pch != '\\' ) {
       *token = 0;
       return;
     }
#ifdef CHRIS
     if (ch == '\\' && pch == '\\')      // escaped escape
         ch = 0;
#endif
     pch = ch;
   }
   .
   .
</pre>
</blockquote>
<hr>
<i>Thank you for taking the time to track down and fix this
problem. I will incorporate it in the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 50.
<p>
Incorporated the fix by Chris and added a verification test.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0117
ENTRY_TITLE: Class method reported as global function.
ENTRY_REPORTED_BY: <a href="mailto:chris@sapphyr.com">Chris Martin</a>
ENTRY_REPORTED_ON: 2001/11/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Chris Martin
ENTRY_RESOLVED_ON: 2001/11/25
ENTRY_REPORTED_BEGIN:
The following code results in the second "Set" method appearing incorrectly
as a standalone (global) function:
<blockquote>
<pre>
class Foo {
public:
     void Set(int a);
     void Set(char *cp, int a);
};
void Foo::Set(int a)
{
     /** Set one. Red */
}
void Foo::Set(char *cp, int a)
{
     /** Set two. Yellow */
}
</pre>
</blockquote>
I think the problem is in ccdoc::database::erase_from_path_map, where
the entire list of statements associated with a path map entry are
removed from the path map, when only the particular statement should
be.
<p>
My suggested fix is as follows:
<blockquote>
<pre>
void ccdoc::database::erase_from_path_map(ccdoc::statement::base* stmt)
{
   if( stmt ) {
     if( stmt->get_type() != statement::base::STMT_COMMENT_PKGDOC &&
         stmt->get_type() != statement::base::STMT_COMMENT_PKGDOC_URL &&
         stmt->get_type() != statement::base::STMT_COMMENT_PREFIX &&
         stmt->get_type() != statement::base::STMT_COMMENT_SUFFIX ) {
       // Issue 0041
       // Ignore comments, they don't have meaningful names.
       const char* pid = stmt->get_id();
       if( *pid ) {
         string id;
         stmt->get_hier_id_no_pkgs(id);
         if( id.size() ) {
           path_map_itr_type itr = m_path_map.find(id);
           if( itr != m_path_map.end() ) {
#ifdef CHRIS
               statement::base::stmts_t &vec = (*itr).second;
               statement::base::stmts_itr_t vitr = vec.begin();
               for(;vitr != vec.end(); vitr++) {
                   if ((*vitr) == stmt) {
                       vec.erase(vitr);
                       break;
                   }
               }
               if (vec.size() == 0)
                   m_path_map.erase(itr);
#endif
         }
       }
     }
     statement::base::stmts_t& children = stmt->get_children();
     statement::base::stmts_itr_t itr = children.begin();
     for(;itr!=children.end();++itr) {
       erase_from_path_map(*itr);
     }
   }
   .
   .
</pre>
</blockquote>
<hr>
<i>Thank you for taking the time to track down and fix this
problem. I will incorporate it in the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 51.
<p>
Incorporated the fix by Chris and added a verification test.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0118
ENTRY_TITLE: Resolve partially scoped references.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2001/11/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2001/11/26
ENTRY_REPORTED_BEGIN:
This is similar to issue <a href="#TAG_0065">0065</a>.
<p>
Ccdoc does not manage partially scoped names as shown in the following example:
<blockquote>
<pre>
namespace test52
{
  class A
  {
  public:
    typedef int nested_type;
    class nested_class {};
    void fct();
  };
  
  class B
  {
  public:
    /** Linked correctly */
    A get_some_class();
    /** Not linked correctly */
    A::nested_type  get_nested_type();
    /** Not linked correctly */
    A::nested_class get_nested_class();
    /** Not linked correctly */
    A::fct get_nested_fct();
  };
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r26. Verified by test 52.
<p>
Added a heuristic that attempts to resolve partially scoped names. It
works better than before but it is not perfect because ccdoc doesn't
understand the using namespace clause.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0119
ENTRY_TITLE: Inconsistent command line syntax for -html paths under DOS.
ENTRY_REPORTED_BY: <a href="mailto:Richard.Cooper@youmeus.com">Richard Cooper</a>
ENTRY_REPORTED_ON: 2001/11/27
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
In regards to issue <a href="#TAG_0115">0115</a>, replacing the
backslashes with forward slashes in the -html switch does fix the
problem. i.e. this works
<blockquote>
<pre>
ccdoc -db docs.db -html ./doc ..\Headers\*.h
</pre>
</blockquote>
But in DOS you can't use backslashes in the headers path. i.e. this
doesn't work
<blockquote>
<pre>
ccdoc -db docs.db -html ./doc ../Headers/*.h
</pre>
</blockquote>
This is not entirely satisfactory because now the two path
descriptions in the command line need to be in different formats (the
html path in UNIX form, the header path in DOS form). IMO the best fix
would be to accept any paths in either format on any platform, but I
have no idea how tricky that would be to implement.
<hr>
<i>
I agree.
</i>
<p>
<i>
Unfortunately this is somewhat difficult because ccdoc can't reliably
determine whether it is running under cmd.exe or under a unix shell that
is running on top of cmd.exe at run time.
</i>
<p>
<i>
If it is running under cmd.exe, it can safely replace backslashes with
forward slashes but, if it is running under a unix shell that is
running on top of cmd.exe it cannot.
</i>
<p>
<i>
I will look into whether ccdoc can be enhanced to allow you to specify
UNIX style paths (with wildcards) under DOS.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0120
ENTRY_TITLE: Add support for the proposed todo tag in javadoc.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Gustavsson Mrten</a>
ENTRY_REPORTED_ON: 2001/11/28
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/11
ENTRY_REPORTED_BEGIN:
I think that a todo tag would be very useful. It is a javadoc proposed tag: 
<a href="http://java.sun.com/j2se/javadoc/proposed-tags.html">http://java.sun.com/j2se/javadoc/proposed-tags.html</a>.
<hr>
<i>
I agree. I will schedule it for the relatively near future.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27. Tested in test59.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0121
ENTRY_TITLE: Reuse namespace comments between packages.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Gustavsson Mrten</a>
ENTRY_REPORTED_ON: 2001/11/29
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I use package names that reflect the directory structure. Each package
is run through ccdoc in a separate ccdoc invocation.
<p>
I use the same namespace between packages. 
<p>
The namespace comment is valid only for the package in which it is
defined. This is alright. The problem is that the documentation is a
bit unclear about the scope for namespace doc comment reuse. I thought
the namespace comment could be reused between packages.
<hr>
<i>
This makes good sense. In fact, this is how it should work. I suspect
that there is a bug in there somewhere.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0122
ENTRY_TITLE: Enhance template reporting.
ENTRY_REPORTED_BY: <a href="mailto:marten.gustavsson@amfpension.se">Gustavsson Mrten</a>
ENTRY_REPORTED_ON: 2001/11/29
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
Template classes are reported ordinary classes in html output. It
would be great if the html showed that a class is a template class.
<p>
It would also be nice if the template definition was shown just like a
function declaration.
<hr>
<i>
I like this idea.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0123
ENTRY_TITLE: {@link ...} not reported correctly in the @deprecated directive
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2002/02/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/11
ENTRY_REPORTED_BEGIN:
The following comments does not report the link correctly:
<blockquote>
<pre>
struct A {
  /**
   * Do stuff.
   */
  void do_stuff();
};
struct B {
  /**
   * Do stuff.
   * @deprecated See {@link A::do_stuff}.
   */
  void fct();
};
</pre>
</blockquote>
This was actually reported by a number of folks.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27. Verified by test58.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0124
ENTRY_TITLE: Scanner condition evaluates to a constant value.
ENTRY_REPORTED_BY: <a href="mailto:michel@lotbiniere.net">Michel Joly de Lotbiniere</a>
ENTRY_REPORTED_ON: 2002/02/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/03/21
ENTRY_REPORTED_BEGIN:
Just compiled "right out of the box" ccdoc v0.8 r26 2001/11/28 with 
IBM's VisualAge C++ 4.0 on Win32. There was only one message:
<p>
CPPC1104I:The condition evaluates to a constant value. 
("phase1_scanner.cc", line 179.9: )
<p>
The code around that is:
<blockquote>
<pre>
// ================================================
// Eliminate the "\\\n" white space. This cannot
// be done in skip_ws() because of the backslash
// trigraph sequence "??/".
// ================================================
if( '\\' == ch ) {
  char ch1 = get_char();
  if( '\n' ) {           <===== The warning is here
    return get_token();
  }
  put_char(ch1);
}
</pre>
</blockquote>
Did you intend to write: if( '\n' == ch1 ) { etc.?
<hr>
<i>I did indeed mean that. This is fixed in r27.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27.
<p>
This was rolled in with the fixed for issue 129.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0125
ENTRY_TITLE: Hash mark displayed for default {@link...} reference.
ENTRY_REPORTED_BY: <a href="mailto:ethan@nagel.net">Ethan Nagel</a>
ENTRY_REPORTED_ON: 2002/02/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/11
ENTRY_REPORTED_BEGIN:
I noticed another minor issue that would be nice if it was cleared up.
Inline @links seem to work pretty well (actually they work better than
the documentation, but when using the "#" syntax to reference a member
of the current class the default text leaves the "#" sign attached!  I'm
frankly not sure this is even really a bug and there are easy
workarounds, but it is annoying. Perhaps I'm just using ccdoc wrong
somehow.  Here's an example:
<blockquote>
<pre>
class Sample
{
public:
   /**
    * Calls {@link #b}.
    */
   int A();
   /**
    * Calls {@link #A A}.
    */
} ;
</pre>
</blockquote>
The documentation for A would have the "#" sign displayed, while the
documentation for B would give me the results I think you should get
automatically.
<hr>
<i>You are not using ccdoc the wrong way. This is an annoying bug and
will be fixed in the next release.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27. Verified by test60.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0126
ENTRY_TITLE: CcDoc does not recognize ccdoc c++ short comment in a "typedef struct" definition.
ENTRY_REPORTED_BY: <a href="mailto:luis.menina@libertysurf.fr">Luis Menina</a>
ENTRY_REPORTED_ON: 2002/02/26
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
CcDoc does not recognize ccdoc c++ short comment in a "typedef struct"
definition (comment does not appear).
<blockquote>
<pre>
typedef struct 
{ 
    int foo1; //@- useful stuff 1
    int foo2;   //@- useful stuff 2
} MY_STRUCT;
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0127
ENTRY_TITLE: CcDoc does not recognize recognize template derivations.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2002/03/01
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/11
ENTRY_REPORTED_BEGIN:
CcDoc does not recognize recognize template derivations.
The following example does not work properly:
<blockquote>
<pre>
template &lt;class T&gt;
struct A {
   void fct1();
};

struct B {
   void fct2();
};

struct C : public A&lt;B&gt;
{
   void fct3();
};
</pre>
</blockquote>
You can work around this bug as follows:
<blockquote>
<pre>
template <class T>
struct A {
   void fct1();
};

struct B {
   void fct2();
};

struct C : public A <font color=red>/**@#-*/&lt;B&gt;/**@#+*/</font>
{
   void fct3();
};
</pre>
</blockquote>
But, as you can see, it is ugly. I will fix this in r27.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27. Added test57 to verify it.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0128
ENTRY_TITLE: Order class entities the same way that were ordered in v07.
ENTRY_REPORTED_BY: <a href="mailto:luis.menina@libertysurf.fr">Luis Menina</a>
ENTRY_REPORTED_ON: 2002/03/01
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
May the class content be sorted not just alphabetically, but
separating method and attributes ? I think it would be more clear and
efficient (as it was in ccdoc v0.7).
<hr>
<i>
Some folks like it this way, others like it the way that you have
described. I think that a switch should be added that allows this.
</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0129
ENTRY_TITLE: All subdirectories are picked up on NT when the * wildcard is specified.
ENTRY_REPORTED_BY: <a href="CBauer@mainstreamdata.com">Clint Bauer</a>
ENTRY_REPORTED_ON: 2002/03/14
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/03/21
ENTRY_REPORTED_BEGIN:
 When I use this line to ccdoc my files: ccdoc -v  *.h  -db medias.db,
ccdoc happens on every .h file in the current directory, and also on every
.h file in every sub-directory to n-deep sub-directories. This I have found
by experimentation.
<hr>
<i>This is a known problem on windows and I will try to fix it in the
next release. Meanwhile you can work around it by specifying the files
explicitly.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27.
<p>
In DOS mode ccdoc used the "DIR /B /S /O:N" command to deduce wild card file names. I
changed this to "DIR /B /O:N" to eliminate the spurious subdirectory searches.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0130
ENTRY_TITLE: Code section wraps in a strange way for small browser windows.
ENTRY_REPORTED_BY: <a href="mailto:wieland@xilinx.com">Doug Wieland</a>
ENTRY_REPORTED_ON: 2002/03/15
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/12
ENTRY_REPORTED_BEGIN:
The ccdoc output for code segment can cause unreadable output if the
browser window is too small.
<hr>
<i>This is a good point. I will add the HTML &lt;TD&gt; attribute tag NOWRAP
in the next release for Code sections.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0131
ENTRY_TITLE: Support comma separated declarations.
ENTRY_REPORTED_BY: <a href="mailto:pitte@anz.com">Esmond Pitt</a>
ENTRY_REPORTED_ON: 2002/09/24
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I can't report this verbatim because my e-mail system crashed but here
is my best recollection.
<p>
Modify ccdoc to allow different comments for each item in a comma
separated declaration. For example:
<pre>
   const string
      /** This is one string */
      string1 = "aaa",
      /** This is another string */
      string2 = "bbb";
</pre>
Note that you can workaround this in the near term as follows:
<pre>
   // Workaround
   /** This is one string */
   const string string1 = "aaa";
   //** This is another string */
   const string string2 = "bbb";
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0132
ENTRY_TITLE: support single-line prefix comments via //@+
ENTRY_REPORTED_BY: <a href="mailto:pitte@anz.com">Esmond Pitt</a>
ENTRY_REPORTED_ON: 2002/09/24
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
<p>
Presently we have
<pre>
        string  m_memberString; //@- the member documentation for this item
</pre>
How about adding this:
<pre>
        //@+ the member documentation for this item
        string  m_memberString;
</pre>
<hr>
<i>This makes sense as a shorthand but since you can workaround it by
using the following syntax. This modification will be scheduled with
a lower priority.</i>
<pre>
        /** the member documentation for this item */
        string  m_memberString;
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0133
ENTRY_TITLE: Anonymous namespaces are not handled correctly.
ENTRY_REPORTED_BY: <a href="mailto:pitte@anz.com">Esmond Pitt</a>
ENTRY_REPORTED_ON: 2002/09/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/12
ENTRY_REPORTED_BEGIN:
We use anonymous namespaces extensively. Each source file has one or more of
these:
<pre>
  namespace
  {
    // local static stuff, classes, constants, ...
  }
</pre>
These are supposed to be merged within a single source file but distinct
across source files.
<p>
Problems which occur:
<p>
<ol>
<li>the namespace name is reported as 'namespace'</li>
<li>a single 'Source:' file is reported</li>
<li>all but the latest namespace contents are lost</li>
</ol>
<p>
You need to do what the compiler does: auto-generate a namespace name based
on the file name, so you can keep all the contents separate, and recognize
and suppress an auto name when reporting (i.e. report each name as
&lt;anonymous&gt;), something like:
<pre>
  &lt;anonymous&gt;     namespace       // documentation or 'undocumented'
    // contents of this anonymous namespace
  &lt;anonymous&gt;     namespace       // documentation or 'undocumented'
    // contents of this anonymous namespace
  &lt;anonymous&gt;     namespace       // documentation or 'undocumented'
    // contents of this anonymous namespace
  &lt;anonymous&gt;     namespace       // documentation or 'undocumented'
    // contents of this anonymous namespace
</pre>
<hr>
<i>I agree. This fix has been scheduled for r27.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27. Verified by tests 61 and 62.
<p>
This was an involved fix. The current implementation keeps all
of the comments associated with a namespace and chains them
in the documentation for that namespace. All of the members of
the namespace are grouped (by package).
<p>
Two new switches were added: -[no]rptcfuns to provide users
with some level of control over the namespace output.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0134
ENTRY_TITLE: Need a forward link to the contents section for classes and packages.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2002/11/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/12
ENTRY_REPORTED_BEGIN:
When the class description is large, it is hard to find the contents
section. The change will allow users to click to get to the table of
contents.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r27.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0135
ENTRY_TITLE: Fix the copyright notice in the code.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2002/11/13
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/13
ENTRY_REPORTED_BEGIN:
Recently I discovered a mail thread in the linux.debian.legal newsgroup
discussing the ccdoc copyright notice. The author: "Branden Robinson", made
some excellent points which I will directly quote here.
<blockquote>
This license's intentions are clearly DFSG-free, but I think it leaves a
couple of things unclear.
<ul>
<li>Permission to distribute UNmodified copies of the software is not
granted.  This is the only potential DFSG problem I can see.
<li>I'm not sure what is meant by "provided...that the distributor grants
the recipient permission for further distribution as permitted by this
notice".  It almost sounds like a copyleft.  If every distributor has
to license the altered copies under these same terms, it is.  If every
distributor simply has to preserve the original copyright notice and
license terms, but has permission to withhold permission for
sub-licensees to make or distribute copies (modified or not), then it is
not a copyleft.  Either intention is DFSG-free.
<p>
In the event that the author does not intend to be using a copyleft, I
suggest that he use the MIT/X11 license instead, which is short, sweet,
and very close in form to the license he is using:
<pre>
   Permission is hereby granted, free of charge, to any person
   obtaining a copy of this software and associated documentation
   files (the "Software"), to deal in the Software without
   restriction, including without limitation the rights to use,
   copy, modify, merge, publish, distribute, sublicense, and/or
   sell copies of the Software, and to permit persons to whom the
   Software is furnished to do so, subject to the following
   conditions:

   The above copyright notice and this permission notice shall be
   included in all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
   OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
   NONINFRINGEMENT.  IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE
   FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
   OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
   CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
   SOFTWARE.
</pre>
If the author does intend to be employing a copyleft, I wonder just for
the sake of intellectual curiosity why he didn't use the GNU GPL.
</blockquote>
<i>I think that the answer is that the author doesn't really understand
all of this legal stuff and really appreciates any help that he can get:-)</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r28.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0136
ENTRY_TITLE: Ccdoc gets confused by a nested struct.
ENTRY_REPORTED_BY: <a href="mailto:drm@xilinx.com">Dennis Marsa</a>
ENTRY_REPORTED_ON: 2002/11/13
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2002/11/14
ENTRY_REPORTED_BEGIN:
The following code fragment causes ccdoc problems:
<blockquote>
<pre>
class A {
protected:
   A();
public:
   virtual ~A() = 0;
private:
   A(const A& rhs);
   A& operator=(const A& rhs);
public:
   struct B {
      int type;
   };
};
</pre>
</blockquote>
The problems are:
<ol>
<li>The A default constructor was reported as automatically generated. It was defined as a protected member.</li>
<li>The A copy constructor was reported as automatically generated. It was defined as a private member. </li>
<li>The A copy operator was reported as automatically generated. It was defined as a private member. </li>
<li>The A::B default constructor was not defined. </li>
<li>The A::B destructor was not defined. 
</li>
</ol>
<hr>
<i>This bug has been scheduled to be fixed in r28.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r28 and verified by tests 63 and 64.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0137
ENTRY_TITLE: The {@link} directive does not work @param clauses.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2002/12/06
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
The {@link} directive is not correctly recognized in @param clauses.
The code example below demonstrates the problem:
<blockquote>
<pre>
namespace testXX {
   class A {
   public:
      A();
      ~A();
      /**
       * Run the test using the specified arguments.
       * @param argc The number of arguments.
       * @param argv The collection of arguments.
       * @returns The run status.
       */
      virtual int Run(int argc,char** argv);
   };
   class test : public A {
   public:
      test();
      ~test();
      /**
       * Run the test using the {@link test99::A::Run} command.
       * @param argc The number of arguments {@link test99::A::Run}.
       * @param argv The collection of arguments {@link test99::A::Run}.
       * @returns The run status {@link test99::A::Run}.
       */
      virtual int Run(int argc,char** argv);
   };
};
</pre>
</blockquote>
<hr>
<b>2002/12/06 jdl</b><br>
<i>After a bit more investigation, I found that there was a workaround
as shown below which makes the fix less urgent.</i>
<blockquote>
<pre>
namespace testXX {
   class A {
   public:
      A();
      ~A();
      /**
       * Run the test using the specified arguments.
       * @param argc The number of arguments.
       * @param argv The collection of arguments.
       * @returns The run status.
       */
      virtual int Run(int argc,char** argv);
   };
   class test : public A {
   public:
      test();
      ~test();
      /**
       * Run the test using the {@link test99::A::Run} command.
       * @param argc The number of arguments <font color=red>
       *             {@link test99::A::Run}.</font>
       * @param argv The collection of arguments<font color=red>
       *             {@link test99::A::Run}.</font>
       * @returns The run status {@link test99::A::Run}.
       */
      virtual int Run(int argc,char** argv);
   };
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0138
ENTRY_TITLE: The @see and {@link} directives do not correctly reference entities in different packages.
ENTRY_REPORTED_BY: <a href="mailto:markus.stulle@ifs-it.de">Markus Stulle</a>
ENTRY_REPORTED_ON: 2003/01/09
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/13
ENTRY_REPORTED_BEGIN:
We are facing the following problem while documenting
source code produced using programming language ansi-c: if a function
'foo()' is documented in a named packaged, e.g. 'A.B.C', we fail in
referencing that function using the '@link' directive:
<blockquote>
<pre>
// file 'foo.c':
/**
 * @pkg A.B.C
 */

/**
 * this function does nothing,
 * so it is error-free by design.
 */
void foo( void );
</pre>
</blockquote>
<blockquote>
<pre>
// file 'bar.c':
/**
 * @pkg D.E
 */

/**
 * again an important procedure.
 * functionality is identical to {@link A.B.C#foo foo}.
 */
void bar( void );
</pre>
</blockquote>
We tried the following entity strings for referencing 'foo', but none of
them produced a link in the resulting hypertext document:
<blockquote>
<pre>
0) A.B.C.foo
1) A.B.C#foo
2) #A.B.C.foo
3) A::B::C#foo
4) A::B::C.foo
5) A::B::C::foo
6) #A::B::C::foo
</pre>
</blockquote>
The motivation for our investigations is the fact, that, unfortunaltely,
'foo()' is defined multiply in our project (i.e. in different packages)
and we want to have a direct link to it from 'bar()' generated by the
'ccdoc' processor. if we employ the directive '{@link #foo foo}' ccdoc
works fine but delivers a link to a page where the user can select from
one of the multiply defined foo()s.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r29 and verified by test 65.
<p>
The problem was that these references were not considering the path
info when looking up a name in the ccdoc::database::get_stmt_no_pkgs()
method. This method was updated to try harder when a name was not found
by looking up the name using the path information.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0139
ENTRY_TITLE: Core dump when an invalid package name of the form "A::B:" appears.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2003/01/13
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/13
ENTRY_REPORTED_BEGIN:
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r29 and verified by test 66.
<p>
There was a missing break that caused the iterator in void
ccdoc::database::parse_path() to run off of the end.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0140
ENTRY_TITLE: Core dump when a friend declaration of the form: foo&operator<< appears.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2003/01/14
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/14
ENTRY_REPORTED_BEGIN:
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r29 and verified manually. This caused the release date to
bump up to 2003/01/15.
<p>
There was a missing break that caused the iterator in void
ccdoc::database::parse_path() to run off of the end for angle brackets.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0141
ENTRY_TITLE: Architecture is not reflected in the bin directory name.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2003/01/21
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/21
ENTRY_REPORTED_BEGIN:
The problem is that I can't differentiate between linux on an i386 platform,
linux on MacOS X and linux on a sparc station.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed by using $Config{'archname'} instead of $Config{'osname'} in the
platform script. This change doesn't affect users to it will be released
as part of r30 when the StrongARM port is done.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0142
ENTRY_TITLE: No man page for linux ports.
ENTRY_REPORTED_BY: <a href="mailto:jdl@xilinx.com">Joe Linoff</a>
ENTRY_REPORTED_ON: 2003/01/21
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/21
ENTRY_REPORTED_BEGIN:
The Debian linux port had to create its own man page for ccdoc.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
I added a man page that is automatically derived from the help text.
This change doesn't affect users to it will be released
as part of r30 when the StrongARM port is done.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0143
ENTRY_TITLE: Support javadocs frames format.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@smartsol.ch">Thomas Bednarz</a>
ENTRY_REPORTED_ON: 2003/01/24
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
"Javadoc documentation is great and very handy to use".
<hr>
<i>I agree. I will look into this in the near future. A couple of
additional thoughts: 1) the new format should be switch controllable
to avoid disrupting existing clients, 2) the new format may be
higher priority than the XML release (this needs to be investigated).</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0144
ENTRY_TITLE: Mark static members and methods in the class overview.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@smartsol.ch">Thomas Bednarz</a>
ENTRY_REPORTED_ON: 2003/01/24
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/17
ENTRY_REPORTED_BEGIN:
It would be helpful, if static members and methods would be specially
marked in the class overview.
<hr>
<i>This makes sense but I am not sure how to do it cleanly. Do you
have any suggestions? Also, do you think that volatile and inline
methods should also be marked?</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r33 and verified by test 70.
<p>
Since static indicates class scope for attributes and methods on classes
it is in a category of its own. Class scoped attributes are now marked
in the contents table.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0145
ENTRY_TITLE: It is impossible to reference an operator in the @see and {@link..} directives.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/01/30
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/01/30
ENTRY_REPORTED_BEGIN:
I cannot reference an operator== in the @see and {@link..} directives.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r31 and verified by test 67.
<p>
The problem was that the operator keyword was not understood
by the lookup ccdoc::database::get_stmt_no_pkgs() method. In
ccdoc, all operator names consist of two parts: the operator keyword
and the operator tokens. They are separated by a space. The link
syntax for @see and {@link} do not allow spaces so special dispensation
was made to allow users to specify links without spaces. The system
then figures them out during the stmt lookup. This example below
shows how to specify links for operators:
<blockquote>
<pre>
namespace test67
{
  class Test
  {
  public:
     /**
      * Is equal, this is the same as {@link #is_equal is_equal}.
      * @see #is_equal
      */
     bool operator==(const Test&amp;) const;
     /**
      * Test method, this is the same as {@link #operator== ==}.
      * @see #operator==
      */
     bool is_equal(const Test&amp;) const;
  };
}
</pre>
</blockquote>
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0146
ENTRY_TITLE: Namespace processing doesn't work properly in certain cases.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/07
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/10
ENTRY_REPORTED_BEGIN:
The current version of ccdoc fails to correctly associated entities
between two entities in the same namespace in the following example:
<blockquote>
<pre>
// file1.h
namespace A {
   int B;
}
</pre>
</blockquote>
<blockquote>
<pre>
// file2.h
namespace A {
   /**
    * @see #B
    */
   int C;
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r32 and verified by test 68.
<p>
The problem was a bug processing undocumented namespaces. In older versions
it can be worked around by specifying the -rptcfuns switch or by adding a
comment to one of the namespaces.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0147
ENTRY_TITLE: Lots of compiler warnings when building ccdoc using the Borland C++ compiler.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/07
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/10
ENTRY_REPORTED_BEGIN:
Saw lots of warnings when compiling ccdoc using the Borland C++ compiler.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r32.
<p>
This was occurring because I explicity turned off warning messages in the
compilers that I use (g++,sun CC,Mac OSC c++) for some silly reason. 
I turned on warnings and cleaned up all of the warning messages for this
release.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0148
ENTRY_TITLE: Allow users to customize ccdoc output using a CSS file.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/10
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Have you thought, instead of giving color parameters etc. to ccdoc
that it can make custom looking html you could give a custom tailored .css-file
to ccdoc and it could generate html which uses a .css-file?
<hr>
<i>I have not thought about it because I don't know much about style sheets
but it sounds like a good idea.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0149
ENTRY_TITLE: Template method implementations confuse ccdoc.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/17
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/17
ENTRY_REPORTED_BEGIN:
Ccdoc still gets confused by the following code:
<blockquote>
<pre>
template &lt;class T&gt;
class Test
{
public:
   Test();
   ~Test();
   T GetValue() const {return m_val;}
   void SetValue(T val);
private:
   T m_val;
};
template &lt;class T&gt;
Test&lt;T&gt;::Test()
{
}
template &lt;class T&gt;
Test&lt;T&gt;::~Test()
{
}
template &lt;class T&gt;
void Test&lt;T&gt;::SetValue(T val)
{
   m_val = val;
}
template &lt;class T&gt;
T real_fct(T val)
{
   Test&lt;T&gt; f;
   f.SetValue(val);
   return f.GetValue();
}
template&lt;&gt; int real_fct&lt;int&gt;(int);
template&lt;&gt; class Test&lt;double&gt;;
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r33 and verified by test 69.
<p>
I added a phase 1 switch called -[no]tcms to tell ccdoc to
ignore template class methods that are implemented outside
of the declaration. The default for this switch is -notcms.
<p>
This implies that all template method documentation must
be done in the declaration.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0150
ENTRY_TITLE: Make it easier to update the revision number in the source files.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/17
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
During the last few releases I noticed that updating the various source
files with the new revision numbers is error prone. To make it less
error prone, I would like to automate it.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34.
<p>
Added the release.pl script to update various source files with the new
revision number.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0151
ENTRY_TITLE: Translate the generated html to other languages.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/14
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Have you thought adding a change to translate contents
of generated html? It would be nice, if ccdoc would
read certain words like "class", "contents" etc. from a
file which would be kind of resource file.
If you change contents a file to f. ex. finnish, then
you would have finnish documentation! 
<p>
The file (simple ex.) could have key-string pairs:
<blockquote>
<pre>
file: ccdoc.en.language
  CLASS=class
  DESTRUCTOR=destructor

file: ccdoc.fi.language
 CLASS=luokka
 DESTRUCTOR=tuhoaja
</pre>
</blockquote>
Then you could generate english documentation:
ccdoc -langfile ccdoc.en.language ...
and finnish:
ccdoc -langfile ccdoc.fi.language ...
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0152
ENTRY_TITLE: Ignore duplicate macros names.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/17
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/26
ENTRY_REPORTED_BEGIN:
This occurs when the -rptmac switch is specified and windows DLL
import/export macros are defined in header files as import by default
without ccdoc guards.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Originally fixed in r34 (2003/02/18) and verified by test 71.
<p>
Fixed again in r39 and verified by test 86 because I found another
problem related to this when the same macro was defined in different
packages.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0153
ENTRY_TITLE: Add a heuristic to ignore include guards and DLLIMPORT macros.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/17
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/18
ENTRY_REPORTED_BEGIN:
Add a heuristic that ignores certain macros under switch control.
Documentation for include guards and windows DLLIMPORT/DLLEXPORT
macros do not help large systems.
<p>
This heuristic would ignore macros named with the following rules:
<ol>
<li>Macros with a _h or _H suffix (include guards).
<li>Macros with a _hh or _HH suffix (include guards).
<li>Macros with a include_ or INCLUDE_ prefix (include guards).
<li>Macros with a _include or _INCLUDE suffix (include guards).
<li>Macros with a _dll or _DLL suffix (DLL import/export).
<li>Macros with a dll_ or DLL_ prefix (DLL import/export).
</ol>
<p>
In the following example only the DBG macro would be documented:
<blockquote>
<pre>
#ifndef file_h
#define file_h

#ifdef WINDOWS
#include <windows.h>
#  ifndef file_dll
#    define file_dll DLLIMPORT
#  else
#    define file_dll DLLEXPORT
#  endif
#endif

/**
 * This macro defines the debug prefix.
 */
#define DBG cerr &lt;&lt; "DEBUG:" &lt;&lt; __FILE__ &lt;&lt; ":" &lt;&lt; __LINE__ &lt;&lt; " " 

#endif
</pre>
</blockquote>
I propose that the switch be called -rptmac1 (report macros heuristically)
in phase 1.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r34 and verified by test 72.
<p>
This is my best guess at reasonable macro names. In the future it
might be better to make this file driven and use these as the
default if the file is not specified.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0154
ENTRY_TITLE: Eliminate the requirement that the -rptmac and -rptmac1 switches appear in phase 1.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/19
ENTRY_REPORTED_BEGIN:
Requiring that the -rptmac and -rptmac1 switches appear in phase 1 and
phase 3 processing is inconsistent and could lead to user confusion
and unexpected results. These switches should only be required in phase 3.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r35.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0155
ENTRY_TITLE: Incorrect documentation when there is only one ccdoc namespace comment for namespace declarations in multiple files.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/18
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/19
ENTRY_REPORTED_BEGIN:
When a namespace is defined in more than one header file but is only
documented in one place, ccdoc auto generates comments and puts the
user documentation in a table. The test case below illustrates the
problem when the ccdoc is generated.
<blockquote>
<pre>
-----------------------
// file1.h
/**
 * This is the namespace documentation.
 * @author Author
 * @version 1.0
 */
namespace Test {
   int fct1();
}

-----------------------
// file2.h
// No ccdoc documentation here. It should derive
// the documentation from file1.h
namespace Test {
   int fct2();
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r35, verified by test 75.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0156
ENTRY_TITLE: More namespace problems in r35.
ENTRY_REPORTED_BY: <a href="mailto:bednarz@sakari.forsberg@tut.fi">Sakari Forsberg</a>
ENTRY_REPORTED_ON: 2003/02/19
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/19
ENTRY_REPORTED_BEGIN:
Namespace processing gets confused in certain cases.
<p>
<h4>Case #1: Lost N1::Class1,  N2::Class2 is reported as N1::Class2</h4>
In the case below, the N1::Class1 is completely lost during processing.
<blockquote>
<pre>
namespace N1 {
   class Class1
   {
   public:
      Class1();
      ~Class1();
   };
}
namespace N2 {
   class Class2 : public N1::Class1
   {
   public:
      Class2();
      ~Class2();
   };
}
</pre>
</blockquote>
<h4>Case #2: N1::Class1 is reported correctly but N2::Class2 is reported as N1::Class2</h4>
The only difference between this case and the one above
is the presence of ccdoc comments.
<blockquote>
<pre>
/**
 * This namespace should contain Class1.
 * @author Author
 * @version 1.0
 */
namespace N1 {
   class Class1
   {
   public:
      Class1();
      ~Class1();
   };
}
/**
 * This namespace should contain Class2
 * with a reference to N1::Class1.
 * @author Author
 * @version 1.0
 */
namespace N2 {
   class Class2 : public N1::Class1
   {
   public:
      Class2();
      ~Class2();
   };
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r36, verified by test 76.
<p>
This was a critical bug that warrants a new release.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0157
ENTRY_TITLE: In some cases operator code is being processed incorrectly.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/19
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/19
ENTRY_REPORTED_BEGIN:
In some cases the body of an operator is parsed incorrectly because
there was a portion of code in the parser that exited prematurely
before processing the body.
<p>
This has been fixed and will be released in r37 later this week.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 69.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0158
ENTRY_TITLE: Class method implementations are reported as global functions.
ENTRY_REPORTED_BY: Richard Durwin
ENTRY_REPORTED_ON: 2003/02/19
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/19
ENTRY_REPORTED_BEGIN:
In the following code example ccdoc reports the class method implementations
as global functions.
<blockquote>
<pre>
class Test {
public:
   Test();
   Test(const Test& obj);
   ~Test();
   Test& operator=(const Test& obj);
   void Set(int v);
   int Get() const;
private:
   int m_a;
};
namespace {
  const char* rcsid = "$Id: issues.txt,v 1.34 2004/09/30 16:09:26 jlinoff Exp $";
};
Test::Test()
  : m_a(0)
{
}
Test::Test(const Test& obj)
  : m_a(obj.m_a)
{
}
Test::~Test()
{
}
Test& Test::operator=(const Test& obj)
{
  m_a = obj.m_a;
  return *this;
}
void Test::Set(int v)
{
  m_a = v;
}
int Test::Get() const
{
  return m_a;
} 
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 77.
<p>
Modified the parser to ignore these.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0159
ENTRY_TITLE: Very long names make the contents table very hard to read.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/20
ENTRY_REPORTED_BEGIN:
When ids are very long it makes the contents table very difficult to read.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by tests 78,79,80.
<p>
Added a switch called -rptmlcei &lt;num&gt; (maximum length of the contents
entity id) that limits the size of the entity id. When the string exceeds that
length, only the first &lt;num&gt; characters are printed followed by
.. to indicate that it has been truncated. The default length is 32.
If no inherited from column exists, the value of the -rptmlcifi is added
to make this field bigger.
<p>
Also added a switch called -rptmlcifi &lt;num&gt; (maximum length of the
contents inherited from id) that limits the size of the
inherited from column. When the string exceeds that length, only the
first &lt;num&gt; characters are printed followed by .. to indicate
that it has been truncated. The default length is 32.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0160
ENTRY_TITLE: Empty function names appear under certain conditions.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/20
ENTRY_REPORTED_BEGIN:
Empty function names appear when the following syntax is encountered:
<blockquote>
<pre>
#ifdef FOO
int Fct(int arg)
#else
long Fct(long arg)
#endif
{
  return arg;
}
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 81.
<p>
This occurs because ccdoc keeps around the pre-processing directives. The
current solution is to print a warning and let the user fix the problem.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0161
ENTRY_TITLE: Strange function names like "max)" appear sometimes.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/20
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/20
ENTRY_REPORTED_BEGIN:
While parsing some STL header files I came across the following
construct which caused ccdoc to become confused about the method
name. It reported the name as "max)" instead of "max".
<blockquote>
<pre>
class Test {
public:
  static double (_STLP_CALL max)() _STLP_NOTHROW { _STLP_USING_VENDOR_CSTD return DBL_MAX; }
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 81.
<p>
This was occurring because the get_fct_name method in phase 1 parsing was
getting confused under certain conditions.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0162
ENTRY_TITLE: Doxygen compatibility - support single line comments using doxygen syntax.
ENTRY_REPORTED_BY: Richard Durwim
ENTRY_REPORTED_ON: 2003/02/21
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/21
ENTRY_REPORTED_BEGIN:
Single line comments use a different flag. That's a lot of edits to
make!
<hr>
<i>I am all in favor of making ccdoc and doxygen style comments compatible
so that users can use both of them.
I will add support for this in the next release.</i>
<p>
<i>
Here are the flavors that ccdoc will support:
</i>
<blockquote>
<pre>
<i>int var; /*!< Detailed description after the member */</i>
<i>int var; /**< Detailed description after the member */</i>
<i>int var; //!< Brief description after the member</i>
<i>int var; ///< Brief description after the member</i>
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 82.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0163
ENTRY_TITLE: Doxygen compatibility - ignore the @endlink directive.
ENTRY_REPORTED_BY: Richard Durwim
ENTRY_REPORTED_ON: 2003/02/21
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/21
ENTRY_REPORTED_BEGIN:
@link uses @endlink to delimit it, rather than the end-of-line. The
@endlink appears in the ccdoc output.
<hr>
<hr>
<i>I am all in favor of making ccdoc and doxygen style comments compatible
so that users can use both of them.
One possible solution is to modify ccdoc to ignore the @endlink directive.
This would allow users to have links in both systems but they would have to 
exist on the same line for compatibility.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 82.
<p>
Modified ccdoc to ignore the @endlink directive.
<p>
In r38 updated ccdoc to officially recognize the @endlink directive
as part of normal processing.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0164
ENTRY_TITLE: Doxygen compatibility - ignore @file comment blocks.
ENTRY_REPORTED_BY: Richard Durwim
ENTRY_REPORTED_ON: 2003/02/21
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/21
ENTRY_REPORTED_BEGIN:
Doxygen uses @file to document files. You could just ignore this
flag. At the moment it appears in ccdoc documentation.
<hr>
<i>I am all in favor of making ccdoc and doxygen style comments compatible
so that users can use both of them.
One possible solution is to modify ccdoc to ignore the @file directive.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r37, verified by test 82.
<p>
Modified ccdoc to ignore the @file comment blocks.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0165
ENTRY_TITLE: Doxygen compatibility - support virtual grouping of definitions.
ENTRY_REPORTED_BY: Richard Durwim
ENTRY_REPORTED_ON: 2003/02/21
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Doxygen allows a virtual grouping of definitions that is very useful
(@name and @{).
<hr>
<i>I am all in favor of making ccdoc and doxygen style comments compatible
so that users can use both of them.
This change is a challenge because the syntax conflicts with a current
ccdoc usage. I will look into it when I can.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0166
ENTRY_TITLE: Variable values are not reported properly when braces occur in the value.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/23
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/23
ENTRY_REPORTED_BEGIN:
The variable value is not reported properly in the following case:
<blockquote>
<pre>
static const char* s_rcsid = {"value"};
</pre>
</blockquote>
The resulting variable declaration strips out the {"value"} so it looks
like this:
<blockquote>
<pre>
static const char* s_rcs_id =
</pre>
</blockquote>
The good news is that the variable is correctly identified and the comments
are correctly associated. The value is the only thing missing.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r38, verified by tests 2 and 83.
<p>
Ccdoc was discarding what it thought was the function body for this
special case.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0167
ENTRY_TITLE: In German we want to use embedded dots in the short description.
ENTRY_REPORTED_BY: <a href="mailto:Ch.Ehrlicher@gmx.de">Christian Ehrlicher</a>
ENTRY_REPORTED_ON: 2003/02/25
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I've found: another little problem. In German we write for the short
form of "for example" "z.B.". ccdoc ignores silently the rest of the
line after the B:
<p>
--&gt; in .h : /**  das ist z.B. test  */
<br>
--&gt; in .html : "das ist z.B"  without the last point an the rest of the line
<hr>
<i>Your example should work.
This is a bug in ccdoc. It is supposed to terminate the short
description after it encounters a dot that is followed by white space.</i>
<p>
<i>For now you can workaround it by embedding trailing spaces before
the last dot as shown below:</i>
<p>
<i>--&gt; in .h : /**  das ist z.B . test  */</i>
<br>
<i>--&gt; in .html : "das ist z.B. test"</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r39, verified by test 84.
<p>
The short description string size was not updated properly in 
ccdoc::phase1::scanner_doc::add_line.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0168
ENTRY_TITLE: Slow g++ 3.2 compile of help.cc because of the large help string.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/25
ENTRY_REPORTED_BEGIN:
Very slow compilation of help.cc using g++ 3.2 because it tries to verify
the format for the very large help string.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r39.
<p>
Modified the script that generates the help text in help.cc to break it
up periodically. This improved compile times by more than 100X on my
system.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0169
ENTRY_TITLE: Man page has formatting problems.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/25
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/25
ENTRY_REPORTED_BEGIN:
The automatically generated man page has formatting problems.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r39.
<p>
Modified the script that generates the man page to recognize the
constructs that were missed in the previous version.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0170
ENTRY_TITLE: Bug on NT platforms parsing command line with spaces and wildcards.
ENTRY_REPORTED_BY: <a href="mailto:gmatamala@icard.net">Gonzalo Matamala Torres</a>
ENTRY_REPORTED_ON: 2003/02/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/26
ENTRY_REPORTED_BEGIN:
Hello (and sorry by my poor english)!
<p>
I have found a bug over NT platforms parsing command line with spaces and
wildcards:
<p>
Unfortunately, the code I'm documenting has white space in paths. (It's a
horrible name coding, I know it!). But I need document it. For example,
library code in:
<blockquote>
<pre>
smartcard components\scot
</pre>
</blockquote>
<p>
when I try, for example:
<blockquote>
<pre>
ccdoc -db example.db "smartcard components\scot\*.h"
</pre>
</blockquote>
ccdoc try resolve wildcard with (switches.cc, line 411):
<blockquote>
<pre>
cmd = "DIR /B /O:N " + file + " > " + tmp + "\n";
</pre>
</blockquote>
that result (in my example):
<blockquote>
<pre>
DIR /B /O:N smartcard components\scot\*.h
</pre>
</blockquote>
and dir command try list "smartcard" directory first and
"components\scot\*.h" after Then, fail because these paths aren't found.
<p>
A solution is using -files switch of course. But I think the above line
can be modified to:
<blockquote>
<pre>
cmd = "DIR /B /O:N \"" + file + "\" > " + tmp + "\n";
</pre>
</blockquote>
that result:
<blockquote>
<pre>
DIR /B /O:N "smartcard components\scot\*.h"
</pre>
</blockquote>
(double quotes are added to path) and then it's a success.
<hr>
<b>2003/02/26 jdl</b><br>
<i>Your English is excellent and so is your solution.</i>
<p>
<i>Thank you for taking the time to thoroughly analyze the problem and
propose a solution. I will add this fix to the v08r39 release so it
should be available to you next week.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r39.
<p>
Manually tested.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0171
ENTRY_TITLE: Constructors with constructed default arguments are reported with the wrong method name.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/02/26
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/02/26
ENTRY_REPORTED_BEGIN:
Constructors with constructed default arguments are reported with the
wrong method name as shown in the example below:
<blockquote>
<pre>
class Test
{
public:
   typedef Allocator&lt;Property*&gt; allocator_type;
   typedef Allocator&lt;Association*&gt; allocator_type1;
   Test( const allocator_type&amp; x = Allocator&lt;Property*&gt;() ) : m_val(0) {}
   Test( const allocator_type1&amp; x = allocator_type1() ) : m_val(0) {}
private:
   int m_val;
};
</pre>
</blockquote>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r39, verified by test 85.
<p>
Modified ccdoc::phase1::parser::get_fct_id to correctly recognize the
constructor situation.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0172
ENTRY_TITLE: Template friend declarations are not resolved properly when packages are used.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/03/11
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/03/11
ENTRY_REPORTED_BEGIN:
Template friends are not resolved properly when packages are used.
They work correctly when packages are not used.
Here is some source code that demonstrates the problem:
<blockquote>
<pre>
template &lt;class T&gt;
class A {
   friend class B&lt;T&gt;;
   T m_val;
};

template &lt;class T&gt;
class B {
   T m_val1;
   A&lt;T&gt; m_val2;
};
</pre>
</blockquote>
Here is the ccdoc command that triggers the problem:
<blockquote>
<pre>
% ccdoc -db foo.db *.h <font color=red>-pkg test</font> -index -html html/
</pre>
</blockquote>
If the -pkg switch is removed, the reference is found correctly.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r40, verified by test87.
<p>
The phase1 parser was not correctly stripping the names to eliminate
template arguments.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0173
ENTRY_TITLE: The md5hash macro is being improperly ignored by the rptmac1 heuristic.
ENTRY_REPORTED_BY: <a href="mailto:kingsb@mail.ru">Alexander Filonov</a>
ENTRY_REPORTED_ON: 2003/04/09
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/05/15
ENTRY_REPORTED_BEGIN:
I've encountered a problem with ccdoc using -rtpmac1 heuristics:
<p>
Macro called "md5hash" will not appear in final html code.
<p>
I see two solutions for this:
<ol>
<li>fix heuristics algorithm
<li>include option for turning on and off command-line options by
   innline text commands.  (or may be such option already exists? If
   so, then I'm sorry for buzzing)
</ol>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r40, verified by test72.
<p>
The backwards comparison heuristic was not working properly.
The option for telling ccdoc to ignore inline text commands already
exists. You can use the predefined __ccdoc__ macro for this as follows:
<blockquote> 
<pre>
#ifndef _include_guard 
<font color=red>#  ifndef __ccdoc__</font>
#    define _include_guard 
<font color=red>#  endif</font>
#endif
</pre>
</blockquote> 
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0174
ENTRY_TITLE: Bug#195282: ccdoc: FTBFS with g++-3.3
ENTRY_REPORTED_BY: <a href="magnus@debian.org">Magnus Ekdahl</a>
ENTRY_REPORTED_ON: 2003/05/30
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2003/06/05
ENTRY_REPORTED_BEGIN:
<pre>
Package: ccdoc
Version: 0.8.38-1
Severity: serious
&gt;From my build log:

...
source='statement.cc' object='statement.o' libtool=no \
depfile='.deps/statement.Po' tmpdepfile='.deps/statement.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I.  -DCCDOC_CID=\"/usr/bin\"   -g -O2 -c -o statement.o `test -f 'statement.cc' || echo
'./'`statement.cc
statement.cc: In static member function `static bool
   ccdoc::statement::base::is_rptmac1_id(const char*)':
statement.cc:987: error: brace-enclosed initializer used to initialize `const
   char*'
statement.cc:987: error: brace-enclosed initializer used to initialize `const
   char*'
...
make[2]: *** [statement.o] Error 1
make[2]: Leaving directory `/tmp/buildd/ccdoc-0.8.38/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/buildd/ccdoc-0.8.38/src'
make: *** [build-stamp] Error 2

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux frobnitz 2.4.21-pre5 #1 Sat Mar 1 09:01:10 PST 2003 i686
Locale: LANG=C, LC_CTYPE=C
</pre>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r41.
<p>
The array initialization was incorrect (in r40), g++ 3.3 was correct in
reporting it.
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0175
ENTRY_TITLE: Generate an index in HTML and XML.
ENTRY_REPORTED_BY: Joe Linoff
ENTRY_REPORTED_ON: 2003/06/05
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
Several users have requested a search capability in ccdoc. This
capability can be provided in two ways: use a standard HTML based
search engine on the generated files or provide a database of indexed
items that can be used for a custom search engine. Although the standard
HTML based search engine approach works well, there are still some users
who would like a pre-generated index of searchable items.
<p>
My current thinking about how to implement this is to provide a
-rptidx switch for phase 3 that generates two HTML indices: one by
name and one by entity type by name.
<p>
It would also generate an XML based index file that could be used by
3rd party search engines.  Each XML record would contain the name of
the entry (i.e. GetName), the type (method, function, etc.) and the
associated URL. Multiple entries with the same name would be allowed.
<p>
It might also be desirable to have it contain information about the
scope of the name. This means that each enclosing namespace and class
might be specified as list. Consider the case of the X::Y::A::B::GetName()
method where X and Y are namespaces, and B is a nested class inside of
A. The scope information would contain data like
<code>((nsp X) (nsp Y) (cls A) (cls B))</code>.
<p>
Yet another desirable attribute would be to have this index view of
the data tie in to the XML output that is being generated in the
proto-type version for the next major release. In this release the
database format will convert to XML. The phase 2 processing will
generate fully cross-indexed entities that are used in phase 3 to
generate HTML. Of course the user can stop at phase 2 and work directly
with the XML. This is different than today where the database format
is NOT XML and it is not fully cross referenced.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0176
ENTRY_TITLE: Enhance the table of contents for easier navigation with letter based links at the top.
ENTRY_REPORTED_BY: <a href="mailto:ragav@xilinx.com">Ragav Satish</a>
ENTRY_REPORTED_ON: 2003/05/23
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
This suggestion was actually made some time ago but I just got around to adding it.
<p>
Ragav suggested that ccdoc be enhanced to support quick links to entries in the table
of contents. The idea is that for tables with a large number of classes (or methods), the
user could click on a quick link to the region they were interested in. 
<p>
In practice it would look something like this:
<blockquote>
<pre>
Table Of Contents

Quick Links: A B C D E F G H ... Z

.
.
.
</pre>
</blockquote>
I think that this would be very useful for large systems that have
hundreds or even thousands of classes.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0177
ENTRY_TITLE: Invalid link from parameter variable name to member variable.
ENTRY_REPORTED_BY: <a href="mailto:chris.rogers@norcross.com.au">Chris Rogers</a>
ENTRY_REPORTED_ON: 2003/06/18
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I have found something wrong with my output though - not sure if this is a bug or if I
am doing something wrong.  I have the following (simplified) situation:
<blockquote>
<pre>
class SOMECLASS
{
public:
    void  DoSomething(int x);
    int x;
};
</pre>
</blockquote>
You'll see that I have a member variable 'x' and also a member
function which has 'x' in it's argument list.  This causes CcDoc to
place a link from the argument name 'x' to the documentation for the
member variable 'x'.
<p>
I could simply change one of these names to ensure that there is no
clash, however I thought you'd like this kind of problem submitted as
a bug.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0178
ENTRY_TITLE: Namespace/anonymous enum interaction bug.
ENTRY_REPORTED_BY: <a href="mailto:william.rivet@hs.utc.com">William A. Rivet</a>
ENTRY_REPORTED_ON: 2003/06/26
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I have a file as_config.h:
<blockquote>
<pre>
#ifndef AS_CONFIG_H
#define AS_CONFIG_H

namespace ApplicationInterface
{
   enum 
      {  zero=0,
         one=1,
         two=2
      };
   enum {
      number_of_tasks         = 60,
      task_stack_size         = 4096,
      number_of_queues        = 32,
      number_of_event_groups  = 32,
      number_of_timers        = 32
   };
   
} // namespace ApplicationInterface
</pre>
</blockquote>

#endif
<p>
The problem is that I see two "$anonymous$" enum entities in the namespace
page, but both link only to a page that lists only the first enum.
<p>
I know that in this case the enums could be combined, but this seems less
than satisfactory as a general solution. Is this a known issue? (I couldn't
find one that seemed to match on the ccdoc website) Is there interest in
fixing this? I have no idea how hard it is to change this. Either way I
likely will have to do something to at least address this in-house.(perhaps
just complain when the second enum is detected...this would at least allow
us to detect the problem and perhaps "invent" a name for at least one of
them).
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0179
ENTRY_TITLE: Add a new @entity directive to allow referencing.
ENTRY_REPORTED_BY: <a href="mailto:Steve.Perry@xilinx.com">Steve Perry</a>
ENTRY_REPORTED_ON: 2003/07/15
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
It would be nice if ccdoc had a directive like "@entity &lt;entityName&gt;".
<p>
Here is how I would want to use it.  I have a macro which declares and
defines a static member function.  It is a macro because every class
in the hierarchy should have this function (it returns an "interface
ID").  The code currently looks like this:
<blockquote>
<pre>
  //@{
  // Returns the ID value for this interface.
  //@}
  Gf_DECL_INTERFACE_ID("{8DC3F1C6-F7CA-42d8-AFD6-7AF950C5C11E}")
# if defined(__ccdoc__)
  static Gf_GUID InterfaceID();
# endif
</pre>
</blockquote>
It would be nicer if I could write:
<blockquote>
<pre>
  //@{
  // Returns the ID value for this interface.
  // @entity static Gf_GUID InterfaceID()
  //@}
  Gf_DECL_INTERFACE_ID("{8DC3F1C6-F7CA-42d8-AFD6-7AF950C5C11E}")
</pre>
</blockquote>
<p>
If there is already a way to do this, I'd appreciate hearing about it.
If not, please consider adding a feature of this sort sometime in the
future.
<hr>
<i>I can see where it would be useful to have real function name
in the table of contents. The #ifdef workaround will certainly
work until this issue is addressed.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0180
ENTRY_TITLE: Limit the length of generated file names.
ENTRY_REPORTED_BY: <a href="mailto:wsakai@cts.com@xilinx.com">Willie Sakai</a>
ENTRY_REPORTED_ON: 2003/08/15
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I've been happily using CCDOC for quite some time, but I'm stumped on 
how to control the length of the generated HTML filenames.  I'm using 
nested packages and the generated filenames are so long that some 
filenames get truncated when written to a CD-ROM.  This results in 
broken links when the documentation tree is copied from the CD-ROM.
<p> 
I've tried using the -maxpathlen option during the (-htm) output 
generation phase, but this doesn't shorten the filename length.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0181
ENTRY_TITLE: Copy constructor documented incorrectly under some conditions.
ENTRY_REPORTED_BY: <a href="mailto:Charles.Doland@xilinx.com">Charles Doland</a>
ENTRY_REPORTED_ON: 2003/08/15
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I would like to report a minor issue with ccdoc, described below.
<p>
The documents created by ccdoc indicate that a constructor will be
generated automatically by the compiler even if one is specified. This
seems to occur when the constructor for class X is specified as X(X
const &), but does not occur when the constructor is specifed as X(const
X &), although these are equivalent.
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0182
ENTRY_TITLE: Add directory tree/outline expansion (+/-) capabilities to better organize the information.
ENTRY_REPORTED_BY: <a href="mailto:Brian.Alexander@xilinx.com">Brian Alexander</a>
ENTRY_REPORTED_ON: 2004/06/04
ENTRY_STATUS: OPEN
ENTRY_RESOLVED_BY:
ENTRY_RESOLVED_ON:
ENTRY_REPORTED_BEGIN:
I was going through the ccdoc for [one of my classes] this morning
when I had a couple of feature ideas for ccdoc.  I was thinking that
it would be nice if overloaded methods in a class could be collapsed
and expanded so that you only saw one line with the function name.  If
all of the short descriptions matched for the method, you could see
the short description - if the short descriptions didn't match you
would see something like "6 overloads".  E.g. you might see something
like this:
<blockquote>
<pre>
 +   GetClient                       Xdm_ObjectDerived       method protected   16 overloaded methods (click '+' to expand)
</pre>
</blockquote>
When you click the + to expand you would see the display much like it is
today with each overload displayed on its line with its short
description.  At this point the '+' would turn into a '-' and clicking
the '-' would collapse it back down.
<p>
Extending that idea, I thought it would be nice if we had an extra tag
that we could tag methods with to categorize them -
E.g. "@category Debug Helper".  All methods with matching categories
would go into an expandable / collapsable grouping like the overloaded
methods.  (If there's just one or two methods in a category maybe it
defaults to expanded but more than two and the category defaults to
collapsed.)  Methods with no category would be displayed as they are
today without the expand/collapse capability.  Methods within a category
are alphabetized within the category.  We would also probably want
links at the top and bottom to 'expand all' and 'collapse all' - maybe
throw in some cookies to store the user's preferences (overall and for
each class) - hah.
<p>
Then I also thought that it was somewhat annoying with the ccdoc for
some classes - Xdm_Model is one example - where there is a lot of good
documentation for the class but it's a pain to have to scroll through
all of that to try and find the method index so I can see if it supports
the method I'm looking for.  Having all of the class documentation and
examples are great for the first time you're using a class but for quick
reference which is most of the time after the first time you've used a
class, all of that stuff gets in the way.  If classes could have extra
tags to separate things out like @Examples, @Extending, @UserGuide  or
something like that then in the ccdoc, you could either have expand /
collapse things like above to expand out the examples text - or you
could have links that take you to the examples for a specific class
etc.  I like the expand/collapse symbols just to keep everything on one
page but it would take some javascript or something I'm sure and may be
more pain than it's worth.
<p>
Anyway,  these were just some pie in the sky ideas I had this morning.
I didn't think them through a whole lot - just wanted to send them off
to you to see if you liked them.
<hr>
<i>These are very interesting ideas. I will definitely look into them for
future releases.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
ENTRY_RESOLVED_END:

# ================================================
ENTRY_ID: 0183
ENTRY_TITLE: Ccdoc started failing with a segment violation in phase 3 when processing a large system (thousands of classes) after a small change to one of the header files.
ENTRY_REPORTED_BY: Xilinx
ENTRY_REPORTED_ON: 2004/09/16
ENTRY_STATUS: FIXED
ENTRY_RESOLVED_BY: Joe Linoff
ENTRY_RESOLVED_ON: 2004/09/29
ENTRY_REPORTED_BEGIN:
Ccdoc started failing with a segment violation in phase 3 when
processing a large system (thousands of classes) after a small change
to one of the header files. This system had been running for years without
a problem.
<hr>
<i>This is a critical bug.</i>
ENTRY_REPORTED_END:
ENTRY_RESOLVED_BEGIN:
Fixed in r41, verified by test88.
<p>
There was a particular order of entities in the class that was causing
consternation in the compare method used during the sorting of the
table of contents in phase3_html.c. I was able to duplicate the
problem (test88) and then fix it by using a std::stable_sort() instead
of a std::sort(). It is interesting to note that this failure occurred
on solaris and linux but it did not occur on windows.
ENTRY_RESOLVED_END:
