ccdoc home page
Ccdoc Issues
FIXED Status
All
Joe Linoff
$Date: 2004/09/30 16:09:26 $
$Revision: 1.35 $

Entry Summary

Id | Title | Status
--- | --- | ---
0001 | The -rootfile switch parses relative names improperly. | FIXED
0002 | The ccdoc_top tage is incorrectly placed in the HEAD section. | FIXED
0003 | Need a new switch, similar to -head, that inserts a file after the head tag to insert custom META elements. | FIXED
0004 | HTTP server problem with uncommon extensions like .exe_gz and .taz. | FIXED
0005 | Log output is not flushed properly on solaris platforms. | FIXED
0006 | Tests weren't working properly. | FIXED
0007 | WARNING: File '*.h' cannot be read so it will be ignored. | FIXED
0008 | Turn off the ccdoc generation of special members. | FIXED
0009 | Compile problem in gcc 3.0 on SuSE linux platform. | FIXED
0010 | Random character appears between package name and function/macro/etc. name in the HTML title. | FIXED
0012 | Ccdoc should ignore template method instantiations. | FIXED
0013 | Add ccdoc to source forge. | FIXED
0014 | The typedef id for function pointer doesn't get extracted properly by ccdoc. | FIXED
0015 | Methods with throw clauses surrounded by parentheses don't get extracted properly by ccdoc. | FIXED
0016 | Source file names of the form ../folder/file.ext don't work properly in the cmd.exe shell under windows. | FIXED
0017 | Can't differentiate between different revisions of ccdoc 0.8. | FIXED
0018 | Directory separators in -root names cause run time errors. | FIXED
0019 | The @see directive no longer accepts user defined links. | FIXED
0020 | ccdoc crashes | FIXED
0021 | Report the version/revision information in the default trailer. | FIXED
0022 | Centralize the version/revision information. | FIXED
0024 | Missing comma separator in @see output for the alternative URL form. | FIXED
0025 | Undocumented 0.7a feature for explicitly specifying @pkgdoc URLs is no longer supported. | FIXED
0026 | Provide an expanded package contents view. | FIXED
0027 | Provide a way to turn off package source. | FIXED
0028 | Provide a way to turn off the default author on the package page. | FIXED
0029 | Provide a way to turn off the default version on the package page. | FIXED
0030 | Provide a way to turn off default description comments on the page. | FIXED
0031 | Provide a way to change the "package" string in the title on package pages. | FIXED
0032 | Users guide and on-help report than -norptpub is the default. | FIXED
0033 | This construct is incorrectly recognized as a struct: void foo(struct bar* spam). | FIXED
0034 | For -rpthpc only show packages. | FIXED
0035 | ccdoc 0.7a to 08 quick reference | FIXED
0036 | Comments get lost. | FIXED
0037 | Change the asterisk column header to "Inherited From". | FIXED
0038 | Change the Path column header to "Entity". | FIXED
0039 | Performance problem in phase3. | FIXED
0040 | Protected inherited methods reported. | FIXED
0041 | Improve 0039 performance enhancement. | FIXED
0042 | ccdoc bug notification - not correctly determining variable name | FIXED
0043 | Old hash mark syntax for @see does not work. | FIXED
0044 | The summary report could use a little more indenting. | FIXED
0045 | The variable width font in the Code: section is not as readable as the fixed width font used in 0.7a. | FIXED
0046 | The @see index doesn't seem to work. | FIXED
0047 | The indenting on the contents page should be the same as the summary report. | FIXED
0048 | Derived classes in namespaces are not recognized correctly. | FIXED
0049 | Non-template class method instantiation not recognized correctly. | FIXED
0050 | Ccdoc fails to parse methods with fct args properly. | FIXED
0051 | External class method implementations with default arguments are not correctly recognized. | FIXED
0052 | Backslash character definition ('\\') confuses the ccdoc scanner. | FIXED
0053 | No line numbers for internal comment parsing warnings. | FIXED
0054 | Serious problem with typedef of struct | FIXED
0056 | Incorrect line numbers reported in warning messages. | FIXED
0059 | Validate ccdoc generated HTML. | FIXED
0063 | Allow user defined defaults for author, short description and version. | FIXED
0064 | Friend classes in namespaces are not recognized correctly. | FIXED
0066 | The <sstream> header is not needed in phase3_html.cc. | FIXED
0068 | Core dump on solaris in the index phase. | FIXED
0069 | Cannot handle construct: "Float operator/(const Float & rval)" | FIXED
0070 | Users guide documentation error. | FIXED
0071 | Operator keyword duplicated for method operators. | FIXED
0072 | New switch to turn off sorting of class entities. | FIXED
0073 | Can't tell ccdoc to ignore a privately declared default constructor. | FIXED
0074 | Ccdoc cannot handle international character sets. | FIXED
0075 | Ccdoc cannot handle function typedef of the form: typedef void fct(int arg1); | FIXED
0076 | Conflict between -meta switch and ccdoc defined meta variables. | FIXED
0077 | Ccdoc incorrectly identifies a class attribute name. | FIXED
0078 | Ccdoc incorrectly identifies a variable as a function. | FIXED
0079 | platform.pl cannot handle embedded parentheses. | FIXED
0080 | Trim trailing spaces in path name for get_stmt_no_pkgs(). | FIXED
0082 | Add the @since directive per the javadoc 1.2 specification. | FIXED
0083 | Modify ccdoc to create a separate links page (as was done in v0.7a). | FIXED
0084 | Alias @exception to @throws per javadoc 1.2. | FIXED
0085 | Ccdoc not recognize default constructors with member initialization. | FIXED
0086 | Comment form to handle single line suffix comments. | FIXED
0087 | Exceptions were not reported as links. | FIXED
0088 | An extra invalid link reported for @link references to classes. | FIXED
0089 | Ccdoc short description syntax is not compliant with javadoc. | FIXED
0090 | Support the {@link ...} javadoc syntax. | FIXED
0091 | Constant values are not hyperlinked in the documentation for function arguments. | FIXED
0092 | The @link syntax does not support the # scoping operator. | FIXED
0095 | Comma's inserted for each line in @returns and @deprecated comments. | FIXED
0097 | Private method is reported incorrectly for overloaded methods with different scopes. | FIXED
0098 | It would be a help if you made the reference red if the class cannot be found for @link. | FIXED
0099 | Ccdoc does not correctly follow the standard for default constructors. | FIXED
0101 | Template problem. | FIXED
0102 | Returned nested classes and types in namespaces are not recognized correctly. | FIXED
0103 | Invalid processing of operator~(). | FIXED
0104 | Invalid processing of operator&(). | FIXED
0107 | javadoc # syntax is not supported in the {@link...} directive. | FIXED
0109 | Print warnings to stderr. | FIXED
0110 | Invalid processing of operator[]. | FIXED
0111 | Multiple link file overflow problem. | FIXED
0112 | Phase 3 exception for operator|. | FIXED
0114 | Error processing of a operator unsigned long(). | FIXED
0115 | Mangled links for .\doc\ references on the command line. | FIXED
0116 | The string constant "\\" isn't parsed correctly. | FIXED
0117 | Class method reported as global function. | FIXED
0118 | Resolve partially scoped references. | FIXED
0120 | Add support for the proposed todo tag in javadoc. | FIXED
0122 | Enhance template reporting. | FIXED
0123 | {@link ...} not reported correctly in the @deprecated directive | FIXED
0124 | Scanner condition evaluates to a constant value. | FIXED
0125 | Hash mark displayed for default {@link...} reference. | FIXED
0127 | CcDoc does not recognize recognize template derivations. | FIXED
0129 | All subdirectories are picked up on NT when the * wildcard is specified. | FIXED
0130 | Code section wraps in a strange way for small browser windows. | FIXED
0133 | Anonymous namespaces are not handled correctly. | FIXED
0134 | Need a forward link to the contents section for classes and packages. | FIXED
0135 | Fix the copyright notice in the code. | FIXED
0136 | Ccdoc gets confused by a nested struct. | FIXED
0138 | The @see and {@link} directives do not correctly reference entities in different packages. | FIXED
0139 | Core dump when an invalid package name of the form "A::B:" appears. | FIXED
0140 | Core dump when a friend declaration of the form: foo&operator<< appears. | FIXED
0141 | Architecture is not reflected in the bin directory name. | FIXED
0142 | No man page for linux ports. | FIXED
0144 | Mark static members and methods in the class overview. | FIXED
0145 | It is impossible to reference an operator in the @see and {@link..} directives. | FIXED
0146 | Namespace processing doesn't work properly in certain cases. | FIXED
0147 | Lots of compiler warnings when building ccdoc using the Borland C++ compiler. | FIXED
0149 | Template method implementations confuse ccdoc. | FIXED
0150 | Make it easier to update the revision number in the source files. | FIXED
0152 | Ignore duplicate macros names. | FIXED
0153 | Add a heuristic to ignore include guards and DLLIMPORT macros. | FIXED
0154 | Eliminate the requirement that the -rptmac and -rptmac1 switches appear in phase 1. | FIXED
0155 | Incorrect documentation when there is only one ccdoc namespace comment for namespace declarations in multiple files. | FIXED
0156 | More namespace problems in r35. | FIXED
0157 | In some cases operator code is being processed incorrectly. | FIXED
0158 | Class method implementations are reported as global functions. | FIXED
0159 | Very long names make the contents table very hard to read. | FIXED
0160 | Empty function names appear under certain conditions. | FIXED
0161 | Strange function names like "max)" appear sometimes. | FIXED
0162 | Doxygen compatibility - support single line comments using doxygen syntax. | FIXED
0163 | Doxygen compatibility - ignore the @endlink directive. | FIXED
0164 | Doxygen compatibility - ignore @file comment blocks. | FIXED
0166 | Variable values are not reported properly when braces occur in the value. | FIXED
0168 | Slow g++ 3.2 compile of help.cc because of the large help string. | FIXED
0169 | Man page has formatting problems. | FIXED
0170 | Bug on NT platforms parsing command line with spaces and wildcards. | FIXED
0171 | Constructors with constructed default arguments are reported with the wrong method name. | FIXED
0172 | Template friend declarations are not resolved properly when packages are used. | FIXED
0173 | The md5hash macro is being improperly ignored by the rptmac1 heuristic. | FIXED
0174 | Bug#195282: ccdoc: FTBFS with g++-3.3 | FIXED
0183 | 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. | FIXED

Title: | The -rootfile switch parses relative names improperly.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/22

Id: 0001
[Top]
[Summary]
[Next]

Problem Description:

> Little bug: Switch '-rootfile': If there is no parh given, the first letter of filename will missing from the HTML hrefs. Eg:
> '-rootfile index.html' => '<a href='ndex.html'>@root</a>' ('i' missing)
> but
> '-rootfile ./index.html' => '<a href='index.html'>@root</a>'

Solution Description:

> Found a problem in make_file_url. The separator iterator was being incremented when the path was completely relative.

> #### Broken Code: phase3_html.c:1845

>       // ================================================================
>       // 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(++relpath_itr;relpath_itr!=fn.end();++relpath_itr) {
>           url += *relpath_itr;
>         }
>       }

> #### Fixed Code

>       // ================================================================
>       // 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;
>             ++relpath_itr; // ISSUE 001 FIX
>           }
>         }
>         url = "";
>         for(;relpath_itr!=fn.end();++relpath_itr) {
>           url += *relpath_itr;
>         }
>       }

Title: | The ccdoc_top tage is incorrectly placed in the HEAD section.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/22

Id: 0002
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Very little bug: <a name=ccdoc_top></a> 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 <table border=0 width="100%"> in the BODY. However I don't know a browser which is confused by this.

Solution Description:

> Moved <a name=ccdoc_top></a> to the BODY section.

Title: | Need a new switch, similar to -head, that inserts a file after the head tag to insert custom META elements.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/22

Id: 0003
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> What is missing, a switch similar to '-head' which inserts the specified file just after the <head> 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.)

> Perhaps a -meta <file> switch?

Solution Description:

> Added a -meta <file> switch that allows the user to specify a file that contains custom meta variables.

Title: | HTTP server problem with uncommon extensions like .exe_gz and .taz.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/23

Id: 0004
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.)

> (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.)

> 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.

Solution Description:

> I resolved this by renaming the archives that were causing problems. Apparently the ".gz" extension does the right thing.

Title: | Log output is not flushed properly on solaris platforms.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/22

Id: 0005
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> This was resolved by flushing the s_log object before the program exits.

Title: | Tests weren't working properly.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/22
Resolved By: | Joe Linoff
Resolved On: | 2001/08/22

Id: 0006
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Tests are being reported as successful when they are not.

Solution Description:

> There was a bug in the test.pl file that caused all tests to pass.

Title: | WARNING: File '*.h' cannot be read so it will be ignored.
Status: | FIXED
Reported By: | Yuriy Stul
Reported On: | 2001/08/23
Resolved By: | Joe Linoff
Resolved On: | 2001/08/23

Id: 0007
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Wildcards do not work in my cmd.exe shell. Here is my example:

>         C:> ccdoc.exe -db LB.db -pkg LBTools *h
>         WARNING: File '*.h' cannot be read so it will be ignored.

Solution Description:

> Fixed in r10.

> 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.

> When I originally closed this issue, I used the following reasoning.

> > 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.

> > 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.

> > 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.

> > You can work around this problem by using the new -files switch as follows:

> >         C:> DIR \B *.h > hfiles.txt
> >         C:> ccdoc -db foo.db -pkg foo -files hfiles.txt

Title: | Turn off the ccdoc generation of special members.
Status: | FIXED
Reported By: | Martin Trappel
Reported On: | 2001/08/23
Resolved By: | Joe Linoff
Resolved On: | 2001/08/23

Id: 0008
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc seems to generate automatic comments for Standard Copy Constructor, Destructor and Assignment Operator.

> 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?

> 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 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.

Solution Description:

> Added the -[no]cdsm switches to phase 1 to allow users to control whether or not default special members are created.

Title: | Compile problem in gcc 3.0 on SuSE linux platform.
Status: | FIXED
Reported By: | Michael Davis
Reported On: | 2001/08/23
Resolved By: | Joe Linoff
Resolved On: | 2001/08/23

Id: 0009
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

>     *** 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<statement::base*>::iterator xitr = itr;
>             ++xitr;
>             if( xitr != contents.end() ) {
>     --- 476,482 ----
>             --xitr;
>             make_tag_id(*xitr,prev_tag);
>             }
>     !       if( itr != contents.end() ) {
>             vector<statement::base*>::iterator xitr = itr;
>             ++xitr;
>             if( xitr != contents.end() ) {

Solution Description:

> Thank you. I have updated and released the fix.

Title: | Random character appears between package name and function/macro/etc. name in the HTML title.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/08/23
Resolved By: | Joe Linoff
Resolved On: | 2001/08/23

Id: 0010
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Random character appears between package name and function/macro/etc. name in the HTML title.

> Eg. this is the title for function RcMalloc in rcheap.h:

>       <title>ccdoc RcMalloc rcheap.h:C:function</title>

> 'C' should not be there.

Solution Description:

> 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.

Title: | Ccdoc should ignore template method instantiations.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/24
Resolved By: | Joe Linoff
Resolved On: | 2003/02/17

Id: 0012
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> See issue 0011 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.

Solution Description:

> Fixed in r33 and verified by test 69.

> See issue 0149 for more details.

Title: | Add ccdoc to source forge.
Status: | FIXED
Reported By: | Scott MacDiarmid
Reported On: | 2001/08/24
Resolved By: | Joe Linoff
Resolved On: | 2002/01/02

Id: 0013
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I am sure you have been asked this before, but have you ever considered moving this project to SourceForge (http://www.sf.net)? 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.

> I think that this is a great idea and have initiated the process. I will close this issue when the transfer is complete.

Solution Description:

> I finally got around to it. See http://ccdoc.sourceforge.net.

Title: | The typedef id for function pointer doesn't get extracted properly by ccdoc.
Status: | FIXED
Reported By: | Chi-Fung Fan
Reported On: | 2001/08/24
Resolved By: | Joe Linoff
Resolved On: | 2001/08/24

Id: 0014
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The typedef id for function pointer doesn't get extracted properly by ccdoc. Example:

>         /** Zero-argument const method type for Node */
>         typedef Node* (Node:*NodeConstMeth) () const;

> Ccdoc will generate an entry with 'const' instead of NodeConstMeth.

> This is a serious problem, I will look into it as soon as possible.

Solution Description:

> The problem was in phase1_parser.c. The parse_typedefs id heuristic did not how to deal with a trailing const keyword.

Title: | Methods with throw clauses surrounded by parentheses don't get extracted properly by ccdoc.
Status: | FIXED
Reported By: | Chi-Fung Fan
Reported On: | 2001/08/25
Resolved By: | Joe Linoff
Resolved On: | 2001/08/27

Id: 0015
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Methods with throw claused don't extracted properly by ccdoc. Example:

>       void PlotDown(const doc::CC* pCC) const
>         throw (RunTimeError);

> I will fix this as soon as possible. Meanwhile, here is a workaround that you can use.

>       void PlotDown(const doc::CC* pCC) const
>     #if !defined(__ccdoc__)
>         throw (RunTimeError)
>     #endif
>         ;

Solution Description:

> Fixed in r5.

> 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.

Title: | Source file names of the form ../folder/file.ext don't work properly in the cmd.exe shell under windows.
Status: | FIXED
Reported By: | Yuriy Stul
Reported On: | 2001/08/26
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0016
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Source file names of the form ../folder/file.exe don't work properly. The error message that it report is:

>       The instruction at "0x00402330" referenced memory at "0x6e64658f".
>       The memory could not be read.

> I need your help. I cannot reproduce this bug. I have created half a dozen test cases and they all work.

> Here are two examples of the command lines I was testing:

>       ..\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

> I tried multiple levels of directories. I tried different source file extensions and everything else I could think of.

> All of this testing was done under Win2K using the MS-DOS command interpreter (cmd.exe).

> Can you help figure out what am I doing wrong so that I can track down and fix this problem?

Solution Description:

> Fixed in r8.

> First, my thanks to Yuriy for helping me track this down.

> This was a different manifestation of issue 0020. The fix was the same.

Title: | Can't differentiate between different revisions of ccdoc 0.8.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/26
Resolved By: | Joe Linoff
Resolved On: | 2001/08/26

Id: 0017
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> It is difficult to distinguish between different versions of ccdoc 0.8.

> I need to a -version switch to report the version/revision of the program.

Solution Description:

> Fixed in r5.

> Added the -version switch. Deprecated the -cid switch.

Title: | Directory separators in -root names cause run time errors.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/27
Resolved By: | Joe Linoff
Resolved On: | 2001/08/27

Id: 0018
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> Fixed in r6.

> Added '/' and '\' filtering in ccdoc::phase3::html::format_name().

Title: | The @see directive no longer accepts user defined links.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/27
Resolved By: | Joe Linoff
Resolved On: | 2001/08/27

Id: 0019
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The @see directive no longer accepts user defined links. In the previous version of ccdoc I could put in a direct link as follows:

>     @see <a href=mywebpage.html>Useful Stuff</a>

> This is an oversight. It will be fixed immediately.

Solution Description:

> Fixed in r7.

> Modified the scanner to accept @see arguments that begin with a '<'. Modified the html generator to output these without interpretation.

Title: | ccdoc crashes
Status: | FIXED
Reported By: | Chi-Fung Fan
Reported On: | 2001/08/27
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0020
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Both MSVC and cygwin versions of ccdoc crashed on generating docs for my program source. Attached is the debug messages before ccdoc dumped core.

> 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.

> What information do you need to debug this problem?

>     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

Solution Description:

> Fix in r8.

> 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.

Title: | Report the version/revision information in the default trailer.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/28
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0021
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Report the version/revision information in the default trailer. This makes error reporting easier.

Solution Description:

> Fixed in r8.

Title: | Centralize the version/revision information.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/28
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0022
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Currently there are several references to "0.8" in phase3_html.c and in switches.cc. These should be centralized to make maintenance easier.

Solution Description:

> Fixed in r8.

> All references to version are now funneled through ccdoc::switches::version().

Title: | Missing comma separator in @see output for the alternative URL form.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/08/28
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0024
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The @see directive does not correct separate entries with commas if there an alternative form URL specified.

Solution Description:

> Fixed in r9.

> Forgot to output leading comma's for the alternative URL form of the @see directive.

Title: | Undocumented 0.7a feature for explicitly specifying @pkgdoc URLs is no longer supported.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/28
Resolved By: | Joe Linoff
Resolved On: | 2001/08/28

Id: 0025
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

>         /** @pkgdoc A.B ../A_B.html*/

> 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?

> Yes. This is an oversight. All features that ccdoc can reasonably support will be supported.

Solution Description:

> Fixed in r9.

> Added support for the two argument form of @pkgdoc and documented it in the on-line help and in the users guide.

Title: | Provide an expanded package contents view.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0026
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> I think that this is a great idea. The switch name will be something like -[no]rpthpc (hierarchical package contents).

Solution Description:

> Fixed in r10.

> 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.

> I also added the -[no]rptcsd to allow you to control whether details are reported on the class summary page (report class summary details).

Title: | Provide a way to turn off package source.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0027
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The source entry on the package page always points to a ccdoc db file. This is not useful to casual readers.

> I agree. I will remove this from the next release.

Solution Description:

> Fixed in r10.

> Completely removed source statements for packages. The db reference does not make sense for users.

Title: | Provide a way to turn off the default author on the package page.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0028
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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?

> Not right now, I will add a switch called -[no]rptdpa (default package author) to give you that control.

Solution Description:

> Fixed in r10.

> Added the -[no]rptdpa switches. The default is -norptdpa.

Title: | Provide a way to turn off the default version on the package page.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0029
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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?

> Not right now, I will add a switch called -[no]rptdpv (default package version) to give you that control.

Solution Description:

> Fixed in r10.

> Added the -[no]rptdpa switches. The default is -norptdpv.

Title: | Provide a way to turn off default description comments on the page.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0030
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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?

> Not right now, I will add a switch called -[no]rptdpd (default package comment) to give you that control.

Solution Description:

> Fixed in r10.

> Added the -[no]rptdpd switches, made -norptdpd the default.

Title: | Provide a way to change the "package" string in the title on package pages.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0031
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

Solution Description:

> Fixed in r10.

> Added the @pkgdoctid directive. See the on-line help or the users guide for additional details.

Title: | Users guide and on-help report than -norptpub is the default.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/08/29
Resolved By: | Joe Linoff
Resolved On: | 2001/08/29

Id: 0032
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Minor documentation nit, help and the users guide report that -norptpub is the default when the real default is -rptpub.

Solution Description:

> Fixed in r10.

Title: | This construct is incorrectly recognized as a struct: void foo(struct bar* spam).
Status: | FIXED
Reported By: | Wawszczak, Jarosław
Reported On: | 2001/08/30
Resolved By: | Joe Linoff
Resolved On: | 2001/08/30

Id: 0033
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> This construct is incorrectly recognized as a struct: void foo(struct bar* spam).

Solution Description:

> Fixed in r10.

> This occurred because the parsing heuristic didn't recognize the the struct declaration was inside an argument list.

Title: | For -rpthpc only show packages.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/02
Resolved By: | Joe Linoff
Resolved On: | 2001/09/04

Id: 0034
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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'.

> 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.

Solution Description:

> Fixed in r11.

Title: | ccdoc 0.7a to 08 quick reference
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/02
Resolved By: | 2001/09/04
Resolved On: | Joe Linoff

Id: 0035
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> I think that this is a good idea. I will add something as soon as I can.

Solution Description:

> Fixed in r11.

> Added a quick reference guide at the top level.

Title: | Comments get lost.
Status: | FIXED
Reported By: | Yuriy Stul
Reported On: | 2001/09/03
Resolved By: | Joe Linoff
Resolved On: | 2001/09/04

Id: 0036
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Comments get lost under the following conditions:

>       /**
>        * This is a dangling comment at the head of a file.
>        */
>       /**
>        * This is a class comment that gets lost.
>        */
>       class A {};

> You can work around this problem by changing the initial comment to a non-ccdoc style comment as follows:

>       /*
>        * This is a dangling comment at the head of a file.
>        */
>       /**
>        * This is a class comment that gets lost.
>        */
>       class A {};

Solution Description:

> Fixed in r12.

> 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.

Title: | Change the asterisk column header to "Inherited From".
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/05
Resolved By: | Joe Linoff
Resolved On: | 2001/09/05

Id: 0037
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Change the asterisk column header to "Inherited From". The asterisk is not very meaningful.

Solution Description:

> Fixed in r13.

Title: | Change the Path column header to "Entity".
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/05
Resolved By: | Joe Linoff
Resolved On: | 2001/09/05

Id: 0038
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Change the asterisk column header to "Inherited From". The asterisk is not very meaningful.

Solution Description:

> Fixed in r13.

Title: | Performance problem in phase3.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/05
Resolved By: | Joe Linoff
Resolved On: | 2001/09/07

Id: 0039
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The new version of ccdoc seems to generate HTML files much slower than v0.7a. In our tests it was running about 10X slower.

Solution Description:

> Fixed in r14.

> 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.

> 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.

> Made the generated HTML slightly more compact. The resulting output in the browers is identical.

> - Modified indenting to use <blockquote> and </blockquote> instead of <table><tr><td><&nbsp;&nbsp;&nbsp;&nbsp;></td><td> and </td></tr></table> because it saves characters and achieves the same result.
> - Removed extraneous carriage returns.
> - Removed the comment banner in the trailer.

> Summary of performance improvements:

> - Added m_path_map and support to database.h.
> - Use m_path_map in phase3::html to improve performance.
> - Removed the redundant calculation of the previous link in phase3::html::write_class_details.
> - Improved phase2 performance as well.

> Summary of other miscellanous changes:

> - 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.
> - Removed the old, slow tree lookup code.

Title: | Protected inherited methods reported.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/09/05
Resolved By: | Joe Linoff
Resolved On: | 2001/09/06

Id: 0040
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> In some cases, it looks like protected inherited methods are reported.

Solution Description:

> Fixed in r13.

> The make_class_contents() method in phase3_html.cc was not verifying that the inherited methods were accessible.

Title: | Improve 0039 performance enhancement.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/09/07
Resolved By: | Joe Linoff
Resolved On: | 2001/09/08

Id: 0041
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following changes would improve the issue 0039 performance fix even more:

> - 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.
> - Ignore comments. Although comments have ids, they are not used. This would reduce the memory footprint somewhat.
> - Don't write out the database if it hasn't changed. This occurs when phase3 is run independently.

Solution Description:

> Fixed in r15.

Title: | ccdoc bug notification - not correctly determining variable name
Status: | FIXED
Reported By: | Paul Kohler
Reported On: | 2001/09/10
Resolved By: | Joe Linoff
Resolved On: | 2001/09/10

Id: 0042
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Version: ccdoc v0.8 r14 2001/09/07 bin_opt_msvc_MSWin32-4.0
> Shell: cmd.exe
> Platform: Windows 2000

> 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.

> Here is the snippet of code with comments:

> >     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;

> And this is the resulting html snippit:

> >     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.

> 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.

Solution Description:

> Fixed in r15.

> 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.

Title: | Old hash mark syntax for @see does not work.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/09/10
Resolved By: | Joe Linoff
Resolved On: | 2001/09/10

Id: 0043
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The old @see #foo syntax no longer works.

> This was an oversight. I inadvertently deprecated it. It will be fixed in the next release.

Solution Description:

> Fixed in r15.

Title: | The summary report could use a little more indenting.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/09/10
Resolved By: | Joe Linoff
Resolved On: | 2001/09/10

Id: 0044
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> It would be nice to be able to control the indenting level for reporting hierarchical objects on the summary page..

> Perhaps I could add a switch that would allow you to control the level of indenting.

Solution Description:

> Fixed in r15.

> Added the -rptcsi (Class Summary Indent) switch.

Title: | The variable width font in the Code: section is not as readable as the fixed width font used in 0.7a.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/09/10
Resolved By: | Joe Linoff
Resolved On: | 2001/09/11

Id: 0045
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The variable width font in the Code: section is not as readable as the fixed width font used in 0.7a.

> 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 have no opinion one way or the other.

> I will add a switch that allows the user to control this. of indenting.

Solution Description:

> Fixed in r17.

> Added the -rptfwcf (Fixed Width Code Font) switch.

> I originally reported this as fixed in r15 but the generate HTML still seemed to be proportional so I changed the generated output.

Title: | The @see index doesn't seem to work.
Status: | FIXED
Reported By: | Chris Meuzelaar
Reported On: | 2001/09/10
Resolved By: | Joe Linoff
Resolved On: | 2001/09/10

Id: 0046
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> Here is a bit of sample code that doesn't work.

> >     class A {
> >     public:
> >       /**
> >        * Do stuff.
> >        * @see A::B 1
> >        * @see A::B 2
> >        */
> >       void B();
> >       void B(int);
> >       void B(double);
> >     };

Solution Description:

> Fixed in r16.

> I thought that this bug was important enough to warrant a re-release.

Title: | The indenting on the contents page should be the same as the summary report.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/09/11
Resolved By: | Joe Linoff
Resolved On: | 2001/09/11

Id: 0047
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The indenting on the contents page should be the same as the summary report.

Solution Description:

> Fixed in r17.

> Modified the -rptcsi (Class Summary Indent) switch to also change the contents indenting.

Title: | Derived classes in namespaces are not recognized correctly.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/09/11
Resolved By: | Joe Linoff
Resolved On: | 2001/09/11

Id: 0048
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> In the following example, the HTML for class_two does not correctly link to class_one.

> >     namespace ccdoc_test {
> >       class class_one {
> >       };
> >       class class_two : public class_one {
> >       };
> >     }

Solution Description:

> Fixed in r17.

> Partially scoped names were not being expanded in the extends clause processing in phase3_html.cc.

Title: | Non-template class method instantiation not recognized correctly.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/09/11
Resolved By: | Joe Linoff
Resolved On: | 2003/02/17

Id: 0049
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> In the following example, some_method() is reported as a separate function.

> >     namespace ccdoc_test {
> >       class class_one {
> >       public:
> >         int some_method();
> >       };
> >       inline int class_one::some_method()
> >       {
> >         return 0;
> >       }
> >     }

> This is not quite as serious as the previous bug because it can be worked around as follows:

> >     namespace ccdoc_test {
> >       class class_one {
> >       public:
> >         int some_method();
> >       };
> >       #if !defined( __ccdoc__ )
> >       inline int class_one::some_method()
> >       {
> >         return 0;
> >       }
> >       #endif
> >     }

Solution Description:

> Fixed in r33 and verified by test 69.

> This was fixed as part of the issue 0149 work.

Title: | Ccdoc fails to parse methods with fct args properly.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/09/11
Resolved By: | Joe Linoff
Resolved On: | 2001/09/11

Id: 0050
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following example is reported incorrectly as a variable of name fp:

> >     class A {
> >     public:
> >       int fct2( void ( * fp ) ( ) ) ;
> >     };

Solution Description:

> Fixed in r17.

> This bug resulted from the phase_parser not being able to correctly identify methods under certain conditions.

Title: | External class method implementations with default arguments are not correctly recognized.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/09/17
Resolved By: | Joe Linoff
Resolved On: | 2003/02/17

Id: 0051
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> External class method implementations with default arguments are not correctly recognized. Here is an example:

> >     class A {
> >     public:
> >       void fct(int x=0);
> >     };
> >     void A::fct(int x)
> >     {
> >     }

> Ccdoc treats the implementation as a separate function.

> 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:

> > Workaround #1 | Workaround #2
> > --- | ---

> >     class A {
> >     public:
> >       void fct(int x=0);
> >     };
> >     #if !defined(__ccdoc__)
> >     void A::fct(int x)
> >     {
> >     }
> >     #endif

> >     class A {
> >     public:
> >       void fct(int x /**@#-*/ =0 /**@#+*/ );
> >     };

> >     void A::fct(int x)
> >     {
> >     }

> Because there are workarounds, this a low priority bug.

Solution Description:

> Fixed in r33 and verified by test 69.

> This was fixed as part of the issue 0149 work.

Title: | Backslash character definition ('\\') confuses the ccdoc scanner.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/09/18
Resolved By: | Joe Linoff
Resolved On: | 2001/09/18

Id: 0052
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following definition confuses the ccdoc parser.

> >     const char X = '\\';

> This is a serious bug that will be fixed as soon as possible.

Solution Description:

> Fixed in r18.

> There was a scanner problem for detecting the ends of character constants in some cases.

Title: | No line numbers for internal comment parsing warnings.
Status: | FIXED
Reported By: | Ray Rizzuto
Reported On: | 2001/09/18
Resolved By: | Joe Linoff
Resolved On: | 2001/09/21

Id: 0053
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Error during parse of header file with a package comment:

> >     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.

Solution Description:

> Fixed in r19.

Title: | Serious problem with typedef of struct
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/09/20
Resolved By: | Joe Linoff
Resolved On: | 2001/09/21

Id: 0054
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following struct typedef conduses ccdoc.

>     typedef struct _TEST {
>         int a;
>         int b;
>     } TEST1;

> It generates the following documentation:

>     package ccdocTest

>     Contents

>         Entity    Type       Scope    Short Description
>         a         typedef    public   undocumented
>         b         variable   public   undocumented

> This is definitely a bug. When I revisited the test suite I noticed that there were no cases for struct and class typedefs.

> You might be able to workaround this problem as follows:

>       struct _TEST {
>         int a;
>         int b;
>       };
>       typedef _TEST TEST1;

Solution Description:

> Fixed in r19.

> The ccdoc::phase1::parser::parse_typedef() method did not correctly recognize embedded structures.

Title: | Incorrect line numbers reported in warning messages.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/09/20
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0056
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Try this:

>     ---[ccdoctest.h]---
>     /** @pkg ccdocTest */

>     int x;

> 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.

Solution Description:

> Fixed in r34, verified by test 13.

> 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.

Title: | Validate ccdoc generated HTML.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/09/20
Resolved By: | Joe Linoff
Resolved On: | 2001/09/20

Id: 0059
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> You can use the verifier at http://validator.w3.org to find errors in ccdoc generated output.

> Thank you for a great suggestion! I never knew that an HTML verifier existed.

Solution Description:

> Modified the ccdoc output to conform to the HTML 4.01 Transitional specification.

Title: | Allow user defined defaults for author, short description and version.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/09/23
Resolved By: | Joe Linoff
Resolved On: | 2001/09/24

Id: 0063
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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?

> This is what issues 0058 and 0059 were originally supposed to address. I misinterpreted the request and addressed the wrong problem.

> 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.

Solution Description:

> Fixed in r20.

> Added:

> - -rptdefa <default_author>
> - -rptdefasd <default_autogen_short_desc>
> - -rptdefsd <default_short_desc>
> - -rptdefv <default_version>

Title: | Friend classes in namespaces are not recognized correctly.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/09/25
Resolved By: | Joe Linoff
Resolved On: | 2001/09/26

Id: 0064
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Code Sample:

> >     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();
> >         };
> >     }

> 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.

> In this particular case, I can modify ccdoc to try looking in the parents namespace it the id is not found.

Solution Description:

> Fixed in r21.

> 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.

Title: | The <sstream> header is not needed in phase3_html.cc.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/09/25
Resolved By: | Joe Linoff
Resolved On: | 2001/09/27

Id: 0066
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The <sstream> header is not needed in phase3_html.cc.

Solution Description:

> Fixed in r21.r

> You are absolutely correct. The <sstream> header is not needed.

> 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.

> Thanks for pointing it out.

Title: | Core dump on solaris in the index phase.
Status: | FIXED
Reported By: | John Rostykus
Reported On: | 2001/10/01
Resolved By: | Joe Linoff
Resolved On: | 2001/10/01

Id: 0068
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Under certain conditions a core dump is generated during the index phase for ccdoc r20.

Solution Description:

> Fixed in r21.

> 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.

Title: | Cannot handle construct: "Float operator/(const Float & rval)"
Status: | FIXED
Reported By: | Gustavsson Mĺrten
Reported On: | 2001/10/04
Resolved By: | Joe Linoff
Resolved On: | 2001/10/08

Id: 0069
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc cannot handle the construct:

> >     Float operator/(const Float & rval)

> You can work around this problem by inserting a space after the forward slash as follows:

> >     Float operator/ (const Float & rval)

Solution Description:

> Fixed in r22.

> 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.

Title: | Users guide documentation error.
Status: | FIXED
Reported By: | Gustavsson Mĺrten
Reported On: | 2001/10/04
Resolved By: | Joe Linoff
Resolved On: | 2001/10/08

Id: 0070
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> By the way, the following section in the user documentation contains an error:

> > ### Directive: /**@#-*/, /**@#+*/

> > > 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:

> > > >     // Turn off sections of code using __ccdoc__
> > > >     #if defined(__ccdoc__)
> > > >       // Ignore stuff until the end
> > > >     #endif

> It should be:

> >     #if !defined(__ccdoc__)

Solution Description:

> Fixed in r22.

Title: | Operator keyword duplicated for method operators.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/10/08
Resolved By: | Joe Linoff
Resolved On: | 2001/10/08

Id: 0071
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Operator keyword duplicated for method operators.

Solution Description:

> .

> 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.

> This is verified by test19.

Title: | New switch to turn off sorting of class entities.
Status: | FIXED
Reported By: | Michael Wang
Reported On: | 2001/10/11
Resolved By: | Joe Linoff
Resolved On: | 2001/10/12

Id: 0072
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

> In keeping with the current naming convention this switch should be called something like -rptdsfce (disable sorting for class entities).

Solution Description:

> Fixed in r22.

> 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.

> The idea is that programmers may wish to logically organize class information in a way that is more understandable than a simple sort.

Title: | Can't tell ccdoc to ignore a privately declared default constructor.
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/10/11
Resolved By: | Joe Linoff
Resolved On: | 2001/10/12

Id: 0073
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> When I create a class with a private default constructor ccdoc still reports it. Here is an example:

> >     class A {
> >     private:
> >       A(); // ccdoc always reports this
> >     public:
> >       A(int);
> >     };

> 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.

> I don't think that a new directive is needed to solve this problem. In fact, I think it is a simple bug.

> Ccdoc must be fixed to not report private entities (even those generated by default) unless the -rptpri switch is specified.

Solution Description:

> Fixed in r22.

> Ccdoc will not report the methods and operators generated by default if they are privately declared.

Title: | Ccdoc cannot handle international character sets.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/10/12
Resolved By: | Joe Linoff
Resolved On: | 2001/10/12

Id: 0074
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> CCDoc inserts a generated html meta variable:

> >     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

> Please, provide any command line arguments for switching to user specified charset.

> Thank you for pointing this out. The charset was added for compliance with the HTML 4.01 Transitional specification (see issue 0059).

> I will add a switch that allows you to define your own character set in the next release (probably on Monday).

Solution Description:

> Fixed in r22.

> Added a new switch called -rptctcs that allows users to specify the character set that they wish to use.

Title: | Ccdoc cannot handle function typedef of the form: typedef void fct(int arg1);
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/10/13
Resolved By: | Joe Linoff
Resolved On: | 2001/10/14

Id: 0075
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc cannot handle function typedef of the form: typedef void fct(int arg1);. It reports arg1 as the typedef rather than fct.

Solution Description:

> Fixed in r23. Verified by test33.

> The phase1_parser did not understand this syntax correctly.

Title: | Conflict between -meta switch and ccdoc defined meta variables.
Status: | FIXED
Reported By: | Dékány Dániel
Reported On: | 2001/10/14
Resolved By: | Joe Linoff
Resolved On: | 2001/10/16

Id: 0076
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

> 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.

Solution Description:

> Fixed in r23. Verified by test34.

> Also added a warning if both -meta and -rptctcs are specified.

Title: | Ccdoc incorrectly identifies a class attribute name.
Status: | FIXED
Reported By: | Clint Bauer
Reported On: | 2001/10/18
Resolved By: | Joe Linoff
Resolved On: | 2001/10/19

Id: 0077
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc identifies the attribute name as BAR instead of m_foo:

> >     class A {
> >     public:
> >       char m_foo[BAR];
> >     };

Solution Description:

> Fixed in r23. Verified by test35.

> The variable id recognizer in ccdoc::phase1::parser::parse_var_or_fct (phase1_parser.c) was confused by the square brackets.

Title: | Ccdoc incorrectly identifies a variable as a function.
Status: | FIXED
Reported By: | Clint Bauer
Reported On: | 2001/10/18
Resolved By: | Joe Linoff
Resolved On: | 2001/10/19

Id: 0078
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc incorrectly identifies a variable as a function in the following case:

> >     const long is_not_a_function = (1+1);

> If the parentheses are removed, ccdoc correctly identifies it as a variable.

Solution Description:

> Fixed in r23. Verified by test36.

> 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.

Title: | platform.pl cannot handle embedded parentheses.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Ben Zoe
Resolved On: | 2001/10/24

Id: 0079
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I use cygwin and it attaches a trailer build number in parentheses which is an illegal path name.

Solution Description:

> Fixed in r24.

> Ben added a line to filter out parentheses to platform.pl.

Title: | Trim trailing spaces in path name for get_stmt_no_pkgs().
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Ben Zoe
Resolved On: | 2001/10/24

Id: 0080
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> If the path name has trailing spaces, the get_stmt_no_pkgs() may fail unexpectedly.

Solution Description:

> Fixed in r24. Verified by test #38.

> Ben added code that will trim trailing white space. I modified it slightly to include the \r white space character for PCs.

> It looks like this problem can be tickled by @links with trailing spaces.

Title: | Add the @since directive per the javadoc 1.2 specification.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Ben Zoe & Joe Linoff
Resolved On: | 2001/10/25

Id: 0082
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Add the @since directive per the javadoc specification.

Solution Description:

> Fixed in r24. Verified by test #39.

> This change invalidates old ccdoc db files.

Title: | Modify ccdoc to create a separate links page (as was done in v0.7a).
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Joe Linoff
Resolved On: | 2001/10/26

Id: 0083
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> That is an intriguing idea. I will look into it in the near future.

Solution Description:

> Fixed in r24. Verified by test #43.

> 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.

Title: | Alias @exception to @throws per javadoc 1.2.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Ben Zoe & Joe Linoff
Resolved On: | 2001/10/25

Id: 0084
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Alias @exception to @throws per javadoc 1.2.

Solution Description:

> Fixed in r24. Verified by test #39.

Title: | Ccdoc not recognize default constructors with member initialization.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Joe Linoff
Resolved On: | 2001/10/25

Id: 0085
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc not recognize default constructors with member initialization as shown in the following example:

> >     class A {
> >     public:
> >       A() : x(0), y(0) {}
> >     private:
> >       int x,y;
> >     };

Solution Description:

> Fixed in r24. Verified by test #42.

Title: | Comment form to handle single line suffix comments.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/24
Resolved By: | Ben Zoe
Resolved On: | 2001/11/25

Id: 0086
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> One another topic, I was looking for a way to do a one line ccdoc comment for this type of suffix documentation:

> >     class A
> >     {
> >     public:
> >       /** An int variable */
> >       int intVar;

> >       /** A long variable */
> >       long longVar;
> >     };

> as

> >     class A
> >     {
> >     public:
> >       int   intVar;  //@- An int variable
> >       long  longVar; //@- A long Var
> >     };

> 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.

> This is an interesting idea. Your idea of a //@- syntax makes sense.

Solution Description:

> Fixed in r26. Verified by test 53.

> Ben did all of the work to implement the changes to phase1_scanner.cc.

Title: | Exceptions were not reported as links.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/10/25
Resolved By: | Joe Linoff
Resolved On: | 2001/10/25

Id: 0087
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc was not reporting links to exceptions in @exception and @throws directives.

Solution Description:

> Fixed in r24. Verified by test #39.

> The code for resolving the exception class was not implemented in ccdoc::phase3::html::write_ccdoc_exception_directive_info() (phase3_html.c).

Title: | An extra invalid link reported for @link references to classes.
Status: | FIXED
Reported By: | Ben Zoe
Reported On: | 2001/10/23
Resolved By: | Joe Linoff
Resolved On: | 2001/10/25

Id: 0088
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> An extra invalid link reported for @link references to classes. The following code fragment demonstrates the problem:

> >     class A {
> >     };
> >     class B {
> >     public:
> >       /**
> >        * Comment.
> >        * @link A
> >        */
> >       void fct();
> >     };

> The link will be reported as "link: A {A}" where the second link is invalid.

Solution Description:

> Fixed in r24. Verified by test #39.

> 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.

Title: | Ccdoc short description syntax is not compliant with javadoc.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/10/25
Resolved By: | Joe Linoff
Resolved On: | 2001/10/25

Id: 0089
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> From the javadoc manual http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#generalform:

> > First Sentence
> > 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.

> > 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.":

> >     /**
> >       * This is a simulation of Prof. Knuth's MIX computer.
> >       */

> Ccdoc doesn´t handle first sentences according to javadoc standard. I believe the summary is created from the first paragraph.

> I think that there is a point in following the javadoc specification as close as possible, the documentation is for free.

> 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 feel that the best solution is to modify ccdoc to conform to the javadoc standard but provide a switch that allows the current behavior.

Solution Description:

> Fixed in r24. Verified by test #40.

> 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.

> Beware! This change will affect your output. Use the -nojdsds switch to enable the old behavior.

Title: | Support the {@link ...} javadoc syntax.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/10/25
Resolved By: | Joe Linoff
Resolved On: | 2001/10/26

Id: 0090
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc does not support inline link references. It should be enhanced to support the {@link ...} directive.

> As an interesting aside, the @link directive in ccdoc was developed independently of javadoc.

Solution Description:

> Fixed in r24. Verified in test #44.

Title: | Constant values are not hyperlinked in the documentation for function arguments.
Status: | FIXED
Reported By: | David McBride
Reported On: | 2001/10/25
Resolved By: | Joe Linoff
Resolved On: | 2001/10/25

Id: 0091
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> Example:

> >     enum myEnum {..........};
> >     const double myConstant = 30.0;

> >     class myClass
> >     {
> >     public:
> >       void myFunct(myEnum fred, double ethel = myConstant);
> >     }

> ccdoc creates a link in myFunct at "myEnum" back to the definition of "myEnum". However, no link is created in myFunct at "myConstant".

Solution Description:

> Fixed in r24. Verified by test #41.

> The ccdoc::phase3::html::write_code_subsection_token() method was not looking for variables or functions.

Title: | The @link syntax does not support the # scoping operator.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/10/26
Resolved By: | Joe Linoff
Resolved On: | 2001/10/26

Id: 0092
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc does not support the '#' scoping operator in @link directives. It works correctly for @see directives. The example below illustrates the problem.

> >     class A {
> >     public:
> >       void fct();
> >       /**
> >        * {@link #fct foo}
> >        * @link #fct
> >        * @see #fct
> >        */
> >       void fct1();
> >     };

Solution Description:

> Fixed in r24. Verified in test #44.

Title: | Comma's inserted for each line in @returns and @deprecated comments.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/11/02
Resolved By: | Joe Linoff
Resolved On: | 2001/11/02

Id: 0095
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc inserts comma's for each new line in an @returns comment. The example below illustrates the problem:

> >     /**
> >      * Returns bug?
> >      * @returns Are extra
> >      * comma's inserted
> >      * at each
> >      * new line?
> >      */
> >     void fct();

> The output looks like this:

> > Are extra , comma's inserted , at each , new line?

> The workaround is to wrap the comment so there are no newlines. This will be fixed in r25.

Solution Description:

> Fixed in r25. Verified by test #45.

Title: | Private method is reported incorrectly for overloaded methods with different scopes.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/11/02
Resolved By: | Joe Linoff
Resolved On: | 2001/11/12

Id: 0097
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Private method is reported incorrectly for overloaded methods with different scopes. The following example illustrates the case.

> >     class A {
> >     public:
> >       void fct();
> >     private:
> >       void fct();
> >     };

> The private void fct shows up in the list.

> The workaround is to tell ccdoc to ignore the private function using the __ccdoc__ pragma. This will be fixed in r25.

Solution Description:

> Fixed in r25. Verified by test #46.

Title: | It would be a help if you made the reference red if the class cannot be found for @link.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/11/09
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0098
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> It would be a help if you made the reference red if the class cannot be found for @link.

Solution Description:

> Fixed in r34, verified by test 73.

Title: | Ccdoc does not correctly follow the standard for default constructors.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/11/09
Resolved By: | Joe Linoff
Resolved On: | 2001/11/28

Id: 0099
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

> Also if you call generated member functions "implicitly defined" this will improve understanding since it will adhere to C++ lingo.

Solution Description:

> Fixed in r26. Verified by test 55.

> Modified special member processing to recognize when any constructor is declared so that it can turn off the generation of the default constructor correctly.

Title: | Template problem.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/11/09
Resolved By: | Joe Linoff
Resolved On: | 2001/11/27

Id: 0101
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following code

>         template<class VALUE_TYPE> 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>>(). A reference to the
>              * internal object is returned.
>              */
>             Input< ReturnPrimitiveInterface<const VALUE_TYPE&, const Event&> > in;

> generates this output:

>     attribute const ? ^ < >
>     Undocumented

>        Source:

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

>        Code:

>           public Input < ReturnPrimitiveInterface < const VALUE_TYPE const Event & > > in

Solution Description:

> Fixed in r26. Verified in test 54.

> The variable recognition heuristic in phase1::parser::parse_var_or_fct did not correctly recognize template arguments.

Title: | Returned nested classes and types in namespaces are not recognized correctly.
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/11/10
Resolved By: | Joe Linoff
Resolved On: | 2001/11/26

Id: 0102
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Returned nested classes and types in namespaces are not recognized correctly.

> Code Sample:

> >     namespace nms {
> >     class some_class
> >     {
> >        public:
> >          typedef int nested_type;
> >          class nested_class {};
> >     };

> >     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();
> >     };
> >     }

Solution Description:

> Fixed in r26. Verified by test 52.

> See issue 0118 for more details.

Title: | Invalid processing of operator~().
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/11/10
Resolved By: | Joe Linoff
Resolved On: | 2001/11/12

Id: 0103
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Sample code:

> >     class some_class
> >     {
> >       public:
> >         some_class operator~();
> >     };

> CCDoc output:

> >     ~    operator public undocumented

Solution Description:

> Fixed in r25. Verified by test #47.

> The ccdoc::phase1::parser::get_fct_id() method was being called for operators.

Title: | Invalid processing of operator&().
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/11/10
Resolved By: | Joe Linoff
Resolved On: | 2001/11/12

Id: 0104
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Sample code:

> >     class some_class
> >     {
> >       public:
> >         some_class operator&( const some_class& );
> >     };

> CCDoc output:

> >     some_classoperator & operator public undocumented

Solution Description:

> Fixed in r25. Verified by test #47.

> The ccdoc::phase1::parser::get_fct_id() method was being called for operators.

Title: | javadoc # syntax is not supported in the {@link...} directive.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/11/08
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0107
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> It seems like it isn´t possible to link to a member function in another class. Example from my code: * {@link metaf::ComAbstractGetAdoRecord#get_one_record ComAbstractGetAdoRecord::get_one_record()}

> Javadoc allows this construct: http://java.sun.com/j2se/1.4/docs/tooldocs/win32/javadoc.html#@see

> The syntax would be quite useful.

> 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.

> 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.

>          class A {
>          public:
>            void fct();
>          };
>          class B {
>          public:
>            /**
>             * See the {@link A::fct fct} for additional details.
>             * @see A::fct
>             */
>            void bar();
>          };

> I completely agree that ccdoc should support the javadoc syntax and will schedule this fix for the next release.

Solution Description:

> Fixed in r34.

Title: | Print warnings to stderr.
Status: | FIXED
Reported By: | Mĺrten Gustavsson
Reported On: | 2001/11/08
Resolved By: | Joe Linoff
Resolved On: | 2001/02/18

Id: 0109
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

> 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.

> 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.

Solution Description:

> Fixed in r34, verified by test 73.

> Added warning messages for all conditions that trigger red in the HTML code.

Title: | Invalid processing of operator[].
Status: | FIXED
Reported By: | Lou Sanchez-Chopitea
Reported On: | 2001/11/16
Resolved By: | Joe Linoff
Resolved On: | 2001/11/12

Id: 0110
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Invalid processing of operator~[]. This is exactly the same problem as issues 0103 and 0104.

Solution Description:

> Fixed in r25.

Title: | Multiple link file overflow problem.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/11/16
Resolved By: | Joe Linoff
Resolved On: | 2001/11/17

Id: 0111
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I ran across a problem where multiple links caused too many files to be generated.

Solution Description:

> Fixed in r25.

> The problem was fixed by re-using common link files.

Title: | Phase 3 exception for operator|.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/11/19
Resolved By: | Joe Linoff
Resolved On: | 2001/11/19

Id: 0112
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Operator | clauses cause an exception to be generated in phase3.

Solution Description:

> Fixed in r25. Verified by test48.

Title: | Error processing of a operator unsigned long().
Status: | FIXED
Reported By: | Dmitry A.Steklenev
Reported On: | 2001/11/22
Resolved By: | Joe Linoff
Resolved On: | 2001/11/26

Id: 0114
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Error processing of a operator unsigned long().

> Sample code:

> >     class some_class
> >     {
> >       public:
> >         some_class operator unsigned long();
> >     }

> CCDoc output:

> >     operator unsignedlong operator public undocumented

Solution Description:

> Fixed in r26. Verified by test49.

> 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".

Title: | Mangled links for .\doc\ references on the command line.
Status: | FIXED
Reported By: | Richard Cooper
Reported On: | 2001/11/22
Resolved By: | Joe Linoff
Resolved On: | 2001/11/27

Id: 0115
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Running ccdoc with the following command line produces documentation with mangled links. The documents are in .\doc but the hyperlinks link to .\doc\doc

> >     ccdoc -db docs.db -html .\doc\ ..\Headers\*.h

> The system works fine if I do the following but as this will be part of an automatic process I don't want to.

> >     cd .\doc
> >     ccdoc -db docs.db -html .\ ..\..\Headers\*.h

> It also works if I move the doc directory to the same level as the Headers directory

> >     ccdoc -db docs.db -html ..\doc\ ..\Headers\*.h

> but not if I move it further up

> >     ccdoc -db docs.db -html ..\..\doc\ ..\Headers\*.h

> 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.

> 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 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.

Solution Description:

> Updated the documentation to reflect the requirement that -html path specifications must use forward slashes on all platforms (even DOS).

Title: | The string constant "\\" isn't parsed correctly.
Status: | FIXED
Reported By: | Chris Martin
Reported On: | 2001/11/25
Resolved By: | Chris Martin
Resolved On: | 2001/11/25

Id: 0116
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The string constant "\\" isn't parsed correctly; resulting in a spurious "unterminated string literal" warning.

> Fix:

> >     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;
> >        }
> >        .
> >        .

> Thank you for taking the time to track down and fix this problem. I will incorporate it in the next release.

Solution Description:

> Fixed in r26. Verified by test 50.

> Incorporated the fix by Chris and added a verification test.

Title: | Class method reported as global function.
Status: | FIXED
Reported By: | Chris Martin
Reported On: | 2001/11/25
Resolved By: | Chris Martin
Resolved On: | 2001/11/25

Id: 0117
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following code results in the second "Set" method appearing incorrectly as a standalone (global) function:

> >     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 */
> >     }

> 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.

> My suggested fix is as follows:

> >     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);
> >          }
> >        }
> >        .
> >        .

> Thank you for taking the time to track down and fix this problem. I will incorporate it in the next release.

Solution Description:

> Fixed in r26. Verified by test 51.

> Incorporated the fix by Chris and added a verification test.

Title: | Resolve partially scoped references.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2001/11/26
Resolved By: | Joe Linoff
Resolved On: | 2001/11/26

Id: 0118
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> This is similar to issue 0065.

> Ccdoc does not manage partially scoped names as shown in the following example:

> >     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();
> >       };
> >     }

Solution Description:

> Fixed in r26. Verified by test 52.

> 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.

Title: | Add support for the proposed todo tag in javadoc.
Status: | FIXED
Reported By: | Gustavsson Mĺrten
Reported On: | 2001/11/28
Resolved By: | Joe Linoff
Resolved On: | 2002/11/11

Id: 0120
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I think that a todo tag would be very useful. It is a javadoc proposed tag: http://java.sun.com/j2se/javadoc/proposed-tags.html.

> I agree. I will schedule it for the relatively near future.

Solution Description:

> Fixed in r27. Tested in test59.

Title: | Enhance template reporting.
Status: | FIXED
Reported By: | Gustavsson Mĺrten
Reported On: | 2001/11/29
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0122
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Template classes are reported ordinary classes in html output. It would be great if the html showed that a class is a template class.

> It would also be nice if the template definition was shown just like a function declaration.

> I like this idea.

Solution Description:

> Fixed in r34.

Title: | {@link ...} not reported correctly in the @deprecated directive
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2002/02/25
Resolved By: | Joe Linoff
Resolved On: | 2002/11/11

Id: 0123
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following comments does not report the link correctly:

> >     struct A {
> >       /**
> >        * Do stuff.
> >        */
> >       void do_stuff();
> >     };
> >     struct B {
> >       /**
> >        * Do stuff.
> >        * @deprecated See {@link A::do_stuff}.
> >        */
> >       void fct();
> >     };

> This was actually reported by a number of folks.

Solution Description:

> Fixed in r27. Verified by test58.

Title: | Scanner condition evaluates to a constant value.
Status: | FIXED
Reported By: | Michel Joly de Lotbiniere
Reported On: | 2002/02/25
Resolved By: | Joe Linoff
Resolved On: | 2002/03/21

Id: 0124
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

> CPPC1104I:The condition evaluates to a constant value. ("phase1_scanner.cc", line 179.9: )

> The code around that is:

> >     // ================================================
> >     // 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);
> >     }

> Did you intend to write: if( '\n' == ch1 ) { etc.?

> I did indeed mean that. This is fixed in r27.

Solution Description:

> Fixed in r27.

> This was rolled in with the fixed for issue 129.

Title: | Hash mark displayed for default {@link...} reference.
Status: | FIXED
Reported By: | Ethan Nagel
Reported On: | 2002/02/25
Resolved By: | Joe Linoff
Resolved On: | 2002/11/11

Id: 0125
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

> >     class Sample
> >     {
> >     public:
> >        /**
> >         * Calls {@link #b}.
> >         */
> >        int A();
> >        /**
> >         * Calls {@link #A A}.
> >         */
> >     } ;

> 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.

> You are not using ccdoc the wrong way. This is an annoying bug and will be fixed in the next release.

Solution Description:

> Fixed in r27. Verified by test60.

Title: | CcDoc does not recognize recognize template derivations.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2002/03/01
Resolved By: | Joe Linoff
Resolved On: | 2002/11/11

Id: 0127
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> CcDoc does not recognize recognize template derivations. The following example does not work properly:

> >     template <class T>
> >     struct A {
> >        void fct1();
> >     };

> >     struct B {
> >        void fct2();
> >     };

> >     struct C : public A<B>
> >     {
> >        void fct3();
> >     };

> You can work around this bug as follows:

> >     template <class T>
> >     struct A {
> >        void fct1();
> >     };

> >     struct B {
> >        void fct2();
> >     };

> >     struct C : public A /**@#-*/<B>/**@#+*/
> >     {
> >        void fct3();
> >     };

> But, as you can see, it is ugly. I will fix this in r27.

Solution Description:

> Fixed in r27. Added test57 to verify it.

Title: | All subdirectories are picked up on NT when the * wildcard is specified.
Status: | FIXED
Reported By: | Clint Bauer
Reported On: | 2002/03/14
Resolved By: | Joe Linoff
Resolved On: | 2002/03/21

Id: 0129
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> 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.

Solution Description:

> Fixed in r27.

> 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.

Title: | Code section wraps in a strange way for small browser windows.
Status: | FIXED
Reported By: | Doug Wieland
Reported On: | 2002/03/15
Resolved By: | Joe Linoff
Resolved On: | 2002/11/12

Id: 0130
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The ccdoc output for code segment can cause unreadable output if the browser window is too small.

> This is a good point. I will add the HTML <TD> attribute tag NOWRAP in the next release for Code sections.

Solution Description:

> Fixed in r27.

Title: | Anonymous namespaces are not handled correctly.
Status: | FIXED
Reported By: | Esmond Pitt
Reported On: | 2002/09/24
Resolved By: | Joe Linoff
Resolved On: | 2002/11/12

Id: 0133
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> We use anonymous namespaces extensively. Each source file has one or more of these:

>       namespace
>       {
>         // local static stuff, classes, constants, ...
>       }

> These are supposed to be merged within a single source file but distinct across source files.

> Problems which occur:

> 1. the namespace name is reported as 'namespace'
> 2. a single 'Source:' file is reported
> 3. all but the latest namespace contents are lost

> 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 <anonymous>), something like:

>       <anonymous>     namespace       // documentation or 'undocumented'
>         // contents of this anonymous namespace
>       <anonymous>     namespace       // documentation or 'undocumented'
>         // contents of this anonymous namespace
>       <anonymous>     namespace       // documentation or 'undocumented'
>         // contents of this anonymous namespace
>       <anonymous>     namespace       // documentation or 'undocumented'
>         // contents of this anonymous namespace

> I agree. This fix has been scheduled for r27.

Solution Description:

> Fixed in r27. Verified by tests 61 and 62.

> 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).

> Two new switches were added: -[no]rptcfuns to provide users with some level of control over the namespace output.

Title: | Need a forward link to the contents section for classes and packages.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2002/11/11
Resolved By: | Joe Linoff
Resolved On: | 2002/11/12

Id: 0134
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> Fixed in r27.

Title: | Fix the copyright notice in the code.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2002/11/13
Resolved By: | Joe Linoff
Resolved On: | 2002/11/13

Id: 0135
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> > This license's intentions are clearly DFSG-free, but I think it leaves a couple of things unclear.
> > - Permission to distribute UNmodified copies of the software is not granted. This is the only potential DFSG problem I can see.
> > - 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.

> >   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:

> >          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.

> >   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.

> 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:-)

Solution Description:

> Fixed in r28.

Title: | Ccdoc gets confused by a nested struct.
Status: | FIXED
Reported By: | Dennis Marsa
Reported On: | 2002/11/13
Resolved By: | Joe Linoff
Resolved On: | 2002/11/14

Id: 0136
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The following code fragment causes ccdoc problems:

> >     class A {
> >     protected:
> >        A();
> >     public:
> >        virtual ~A() = 0;
> >     private:
> >        A(const A& rhs);
> >        A& operator=(const A& rhs);
> >     public:
> >        struct B {
> >           int type;
> >        };
> >     };

> The problems are:
> 1. The A default constructor was reported as automatically generated. It was defined as a protected member.
> 2. The A copy constructor was reported as automatically generated. It was defined as a private member.
> 3. The A copy operator was reported as automatically generated. It was defined as a private member.
> 4. The A::B default constructor was not defined.
> 5. The A::B destructor was not defined.

> This bug has been scheduled to be fixed in r28.

Solution Description:

> Fixed in r28 and verified by tests 63 and 64.

Title: | The @see and {@link} directives do not correctly reference entities in different packages.
Status: | FIXED
Reported By: | Markus Stulle
Reported On: | 2003/01/09
Resolved By: | Joe Linoff
Resolved On: | 2003/01/13

Id: 0138
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

> >     // file 'foo.c':
> >     /**
> >      * @pkg A.B.C
> >      */

> >     /**
> >      * this function does nothing,
> >      * so it is error-free by design.
> >      */
> >     void foo( void );

> >     // file 'bar.c':
> >     /**
> >      * @pkg D.E
> >      */

> >     /**
> >      * again an important procedure.
> >      * functionality is identical to {@link A.B.C#foo foo}.
> >      */
> >     void bar( void );

> We tried the following entity strings for referencing 'foo', but none of them produced a link in the resulting hypertext document:

> >     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

> 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.

Solution Description:

> Fixed in r29 and verified by test 65.

> 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.

Title: | Core dump when an invalid package name of the form "A::B:" appears.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/01/13
Resolved By: | Joe Linoff
Resolved On: | 2003/01/13

Id: 0139
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

Solution Description:

> Fixed in r29 and verified by test 66.

> There was a missing break that caused the iterator in void ccdoc::database::parse_path() to run off of the end.

Title: | Core dump when a friend declaration of the form: foo&operator<< appears.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/01/14
Resolved By: | Joe Linoff
Resolved On: | 2003/01/14

Id: 0140
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

Solution Description:

> Fixed in r29 and verified manually. This caused the release date to bump up to 2003/01/15.

> There was a missing break that caused the iterator in void ccdoc::database::parse_path() to run off of the end for angle brackets.

Title: | Architecture is not reflected in the bin directory name.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/01/21
Resolved By: | Joe Linoff
Resolved On: | 2003/01/21

Id: 0141
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The problem is that I can't differentiate between linux on an i386 platform, linux on MacOS X and linux on a sparc station.

Solution Description:

> 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.

Title: | No man page for linux ports.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/01/21
Resolved By: | Joe Linoff
Resolved On: | 2003/01/21

Id: 0142
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The Debian linux port had to create its own man page for ccdoc.

Solution Description:

> 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.

Title: | Mark static members and methods in the class overview.
Status: | FIXED
Reported By: | Thomas Bednarz
Reported On: | 2003/01/24
Resolved By: | Joe Linoff
Resolved On: | 2003/02/17

Id: 0144
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> It would be helpful, if static members and methods would be specially marked in the class overview.

> 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?

Solution Description:

> Fixed in r33 and verified by test 70.

> 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.

Title: | It is impossible to reference an operator in the @see and {@link..} directives.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/01/30
Resolved By: | Joe Linoff
Resolved On: | 2003/01/30

Id: 0145
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I cannot reference an operator== in the @see and {@link..} directives.

Solution Description:

> Fixed in r31 and verified by test 67.

> 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:

> >     namespace test67
> >     {
> >       class Test
> >       {
> >       public:
> >          /**
> >           * Is equal, this is the same as {@link #is_equal is_equal}.
> >           * @see #is_equal
> >           */
> >          bool operator==(const Test&) const;
> >          /**
> >           * Test method, this is the same as {@link #operator== ==}.
> >           * @see #operator==
> >           */
> >          bool is_equal(const Test&) const;
> >       };
> >     }

Title: | Namespace processing doesn't work properly in certain cases.
Status: | FIXED
Reported By: | Sakari Forsberg
Reported On: | 2003/02/07
Resolved By: | Joe Linoff
Resolved On: | 2003/02/10

Id: 0146
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The current version of ccdoc fails to correctly associated entities between two entities in the same namespace in the following example:

> >     // file1.h
> >     namespace A {
> >        int B;
> >     }

> >     // file2.h
> >     namespace A {
> >        /**
> >         * @see #B
> >         */
> >        int C;
> >     }

Solution Description:

> Fixed in r32 and verified by test 68.

> 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.

Title: | Lots of compiler warnings when building ccdoc using the Borland C++ compiler.
Status: | FIXED
Reported By: | Sakari Forsberg
Reported On: | 2003/02/07
Resolved By: | Joe Linoff
Resolved On: | 2003/02/10

Id: 0147
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Saw lots of warnings when compiling ccdoc using the Borland C++ compiler.

Solution Description:

> Fixed in r32.

> 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.

Title: | Template method implementations confuse ccdoc.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/17
Resolved By: | Joe Linoff
Resolved On: | 2003/02/17

Id: 0149
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Ccdoc still gets confused by the following code:

> >     template <class T>
> >     class Test
> >     {
> >     public:
> >        Test();
> >        ~Test();
> >        T GetValue() const {return m_val;}
> >        void SetValue(T val);
> >     private:
> >        T m_val;
> >     };
> >     template <class T>
> >     Test<T>::Test()
> >     {
> >     }
> >     template <class T>
> >     Test<T>::~Test()
> >     {
> >     }
> >     template <class T>
> >     void Test<T>::SetValue(T val)
> >     {
> >        m_val = val;
> >     }
> >     template <class T>
> >     T real_fct(T val)
> >     {
> >        Test<T> f;
> >        f.SetValue(val);
> >        return f.GetValue();
> >     }
> >     template<> int real_fct<int>(int);
> >     template<> class Test<double>;

Solution Description:

> Fixed in r33 and verified by test 69.

> 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.

> This implies that all template method documentation must be done in the declaration.

Title: | Make it easier to update the revision number in the source files.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/17
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0150
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> Fixed in r34.

> Added the release.pl script to update various source files with the new revision number.

Title: | Ignore duplicate macros names.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/17
Resolved By: | Joe Linoff
Resolved On: | 2003/02/26

Id: 0152
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> Originally fixed in r34 (2003/02/18) and verified by test 71.

> 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.

Title: | Add a heuristic to ignore include guards and DLLIMPORT macros.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/17
Resolved By: | Joe Linoff
Resolved On: | 2003/02/18

Id: 0153
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Add a heuristic that ignores certain macros under switch control. Documentation for include guards and windows DLLIMPORT/DLLEXPORT macros do not help large systems.

> This heuristic would ignore macros named with the following rules:

> 1. Macros with a _h or _H suffix (include guards).
> 2. Macros with a _hh or _HH suffix (include guards).
> 3. Macros with a include_ or INCLUDE_ prefix (include guards).
> 4. Macros with a _include or _INCLUDE suffix (include guards).
> 5. Macros with a _dll or _DLL suffix (DLL import/export).
> 6. Macros with a dll_ or DLL_ prefix (DLL import/export).

> In the following example only the DBG macro would be documented:

> >     #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 << "DEBUG:" << __FILE__ << ":" << __LINE__ << " "

> >     #endif

> I propose that the switch be called -rptmac1 (report macros heuristically) in phase 1.

Solution Description:

> Fixed in r34 and verified by test 72.

> 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.

Title: | Eliminate the requirement that the -rptmac and -rptmac1 switches appear in phase 1.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/18
Resolved By: | Joe Linoff
Resolved On: | 2003/02/19

Id: 0154
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

Solution Description:

> Fixed in r35.

Title: | Incorrect documentation when there is only one ccdoc namespace comment for namespace declarations in multiple files.
Status: | FIXED
Reported By: | Sakari Forsberg
Reported On: | 2003/02/18
Resolved By: | Joe Linoff
Resolved On: | 2003/02/19

Id: 0155
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> >     -----------------------
> >     // 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();
> >     }

Solution Description:

> Fixed in r35, verified by test 75.

Title: | More namespace problems in r35.
Status: | FIXED
Reported By: | Sakari Forsberg
Reported On: | 2003/02/19
Resolved By: | Joe Linoff
Resolved On: | 2003/02/19

Id: 0156
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Namespace processing gets confused in certain cases.

> #### Case #1: Lost N1::Class1, N2::Class2 is reported as N1::Class2

> In the case below, the N1::Class1 is completely lost during processing.

> >     namespace N1 {
> >        class Class1
> >        {
> >        public:
> >           Class1();
> >           ~Class1();
> >        };
> >     }
> >     namespace N2 {
> >        class Class2 : public N1::Class1
> >        {
> >        public:
> >           Class2();
> >           ~Class2();
> >        };
> >     }

> #### Case #2: N1::Class1 is reported correctly but N2::Class2 is reported as N1::Class2

> The only difference between this case and the one above is the presence of ccdoc comments.

> >     /**
> >      * 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();
> >        };
> >     }

Solution Description:

> Fixed in r36, verified by test 76.

> This was a critical bug that warrants a new release.

Title: | In some cases operator code is being processed incorrectly.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/19
Resolved By: | Joe Linoff
Resolved On: | 2003/02/19

Id: 0157
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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.

> This has been fixed and will be released in r37 later this week.

Solution Description:

> Fixed in r37, verified by test 69.

Title: | Class method implementations are reported as global functions.
Status: | FIXED
Reported By: | Richard Durwin
Reported On: | 2003/02/19
Resolved By: | Joe Linoff
Resolved On: | 2003/02/19

Id: 0158
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> In the following code example ccdoc reports the class method implementations as global functions.

> >     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_FIXED.html,v 1.35 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;
> >     }

Solution Description:

> Fixed in r37, verified by test 77.

> Modified the parser to ignore these.

Title: | Very long names make the contents table very hard to read.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/20
Resolved By: | Joe Linoff
Resolved On: | 2003/02/20

Id: 0159
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> When ids are very long it makes the contents table very difficult to read.

Solution Description:

> Fixed in r37, verified by tests 78,79,80.

> Added a switch called -rptmlcei <num> (maximum length of the contents entity id) that limits the size of the entity id. When the string exceeds that length, only the first <num> 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.

> Also added a switch called -rptmlcifi <num> (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 <num> characters are printed followed by .. to indicate that it has been truncated. The default length is 32.

Title: | Empty function names appear under certain conditions.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/20
Resolved By: | Joe Linoff
Resolved On: | 2003/02/20

Id: 0160
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Empty function names appear when the following syntax is encountered:

> >     #ifdef FOO
> >     int Fct(int arg)
> >     #else
> >     long Fct(long arg)
> >     #endif
> >     {
> >       return arg;
> >     }

Solution Description:

> Fixed in r37, verified by test 81.

> 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.

Title: | Strange function names like "max)" appear sometimes.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/20
Resolved By: | Joe Linoff
Resolved On: | 2003/02/20

Id: 0161
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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".

> >     class Test {
> >     public:
> >       static double (_STLP_CALL max)() _STLP_NOTHROW { _STLP_USING_VENDOR_CSTD return DBL_MAX; }
> >     };

Solution Description:

> Fixed in r37, verified by test 81.

> This was occurring because the get_fct_name method in phase 1 parsing was getting confused under certain conditions.

Title: | Doxygen compatibility - support single line comments using doxygen syntax.
Status: | FIXED
Reported By: | Richard Durwim
Reported On: | 2003/02/21
Resolved By: | Joe Linoff
Resolved On: | 2003/02/21

Id: 0162
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Single line comments use a different flag. That's a lot of edits to make!

> 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.

> Here are the flavors that ccdoc will support:

> >     int var; /*!< Detailed description after the member */
> >     int var; /**< Detailed description after the member */
> >     int var; //!< Brief description after the member
> >     int var; ///< Brief description after the member

Solution Description:

> Fixed in r37, verified by test 82.

Title: | Doxygen compatibility - ignore the @endlink directive.
Status: | FIXED
Reported By: | Richard Durwim
Reported On: | 2003/02/21
Resolved By: | Joe Linoff
Resolved On: | 2003/02/21

Id: 0163
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> @link uses @endlink to delimit it, rather than the end-of-line. The @endlink appears in the ccdoc output.

> 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.

Solution Description:

> Fixed in r37, verified by test 82.

> Modified ccdoc to ignore the @endlink directive.

> In r38 updated ccdoc to officially recognize the @endlink directive as part of normal processing.

Title: | Doxygen compatibility - ignore @file comment blocks.
Status: | FIXED
Reported By: | Richard Durwim
Reported On: | 2003/02/21
Resolved By: | Joe Linoff
Resolved On: | 2003/02/21

Id: 0164
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Doxygen uses @file to document files. You could just ignore this flag. At the moment it appears in ccdoc documentation.

> 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.

Solution Description:

> Fixed in r37, verified by test 82.

> Modified ccdoc to ignore the @file comment blocks.

Title: | Variable values are not reported properly when braces occur in the value.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/23
Resolved By: | Joe Linoff
Resolved On: | 2003/02/23

Id: 0166
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The variable value is not reported properly in the following case:

> >     static const char* s_rcsid = {"value"};

> The resulting variable declaration strips out the {"value"} so it looks like this:

> >     static const char* s_rcs_id =

> The good news is that the variable is correctly identified and the comments are correctly associated. The value is the only thing missing.

Solution Description:

> Fixed in r38, verified by tests 2 and 83.

> Ccdoc was discarding what it thought was the function body for this special case.

Title: | Slow g++ 3.2 compile of help.cc because of the large help string.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/25
Resolved By: | Joe Linoff
Resolved On: | 2003/02/25

Id: 0168
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Very slow compilation of help.cc using g++ 3.2 because it tries to verify the format for the very large help string.

Solution Description:

> Fixed in r39.

> 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.

Title: | Man page has formatting problems.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/25
Resolved By: | Joe Linoff
Resolved On: | 2003/02/25

Id: 0169
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> The automatically generated man page has formatting problems.

Solution Description:

> Fixed in r39.

> Modified the script that generates the man page to recognize the constructs that were missed in the previous version.

Title: | Bug on NT platforms parsing command line with spaces and wildcards.
Status: | FIXED
Reported By: | Gonzalo Matamala Torres
Reported On: | 2003/02/26
Resolved By: | Joe Linoff
Resolved On: | 2003/02/26

Id: 0170
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Hello (and sorry by my poor english)!

> I have found a bug over NT platforms parsing command line with spaces and wildcards:

> 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:

> >     smartcard components\scot

> when I try, for example:

> >     ccdoc -db example.db "smartcard components\scot\*.h"

> ccdoc try resolve wildcard with (switches.cc, line 411):

> >     cmd = "DIR /B /O:N " + file + " > " + tmp + "\n";

> that result (in my example):

> >     DIR /B /O:N smartcard components\scot\*.h

> and dir command try list "smartcard" directory first and "components\scot\*.h" after Then, fail because these paths aren't found.

> A solution is using -files switch of course. But I think the above line can be modified to:

> >     cmd = "DIR /B /O:N \"" + file + "\" > " + tmp + "\n";

> that result:

> >     DIR /B /O:N "smartcard components\scot\*.h"

> (double quotes are added to path) and then it's a success.

> 2003/02/26 jdl
> Your English is excellent and so is your solution.

> 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.

Solution Description:

> Fixed in r39.

> Manually tested.

Title: | Constructors with constructed default arguments are reported with the wrong method name.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/02/26
Resolved By: | Joe Linoff
Resolved On: | 2003/02/26

Id: 0171
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> Constructors with constructed default arguments are reported with the wrong method name as shown in the example below:

> >     class Test
> >     {
> >     public:
> >        typedef Allocator<Property*> allocator_type;
> >        typedef Allocator<Association*> allocator_type1;
> >        Test( const allocator_type& x = Allocator<Property*>() ) : m_val(0) {}
> >        Test( const allocator_type1& x = allocator_type1() ) : m_val(0) {}
> >     private:
> >        int m_val;
> >     };

Solution Description:

> Fixed in r39, verified by test 85.

> Modified ccdoc::phase1::parser::get_fct_id to correctly recognize the constructor situation.

Title: | Template friend declarations are not resolved properly when packages are used.
Status: | FIXED
Reported By: | Joe Linoff
Reported On: | 2003/03/11
Resolved By: | Joe Linoff
Resolved On: | 2003/03/11

Id: 0172
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> 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:

> >     template <class T>
> >     class A {
> >        friend class B<T>;
> >        T m_val;
> >     };

> >     template <class T>
> >     class B {
> >        T m_val1;
> >        A<T> m_val2;
> >     };

> Here is the ccdoc command that triggers the problem:

> >     % ccdoc -db foo.db *.h -pkg test -index -html html/

> If the -pkg switch is removed, the reference is found correctly.

Solution Description:

> Fixed in r40, verified by test87.

> The phase1 parser was not correctly stripping the names to eliminate template arguments.

Title: | The md5hash macro is being improperly ignored by the rptmac1 heuristic.
Status: | FIXED
Reported By: | Alexander Filonov
Reported On: | 2003/04/09
Resolved By: | Joe Linoff
Resolved On: | 2003/05/15

Id: 0173
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

> I've encountered a problem with ccdoc using -rtpmac1 heuristics:

> Macro called "md5hash" will not appear in final html code.

> I see two solutions for this:

> 1. fix heuristics algorithm
> 2. 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)

Solution Description:

> Fixed in r40, verified by test72.

> 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:

> >     #ifndef _include_guard
> >     #  ifndef __ccdoc__
> >     #    define _include_guard
> >     #  endif
> >     #endif

Title: | Bug#195282: ccdoc: FTBFS with g++-3.3
Status: | FIXED
Reported By: | Magnus Ekdahl
Reported On: | 2003/05/30
Resolved By: | Joe Linoff
Resolved On: | 2003/06/05

Id: 0174
[Top]
[Summary]
[Next]
[Previous]

Problem Description:

>     Package: ccdoc
>     Version: 0.8.38-1
>     Severity: serious
>     >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

Solution Description:

> Fixed in r41.

> The array initialization was incorrect (in r40), g++ 3.3 was correct in reporting it.

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.
Status: | FIXED
Reported By: | Xilinx
Reported On: | 2004/09/16
Resolved By: | Joe Linoff
Resolved On: | 2004/09/29

Id: 0183
[Top]
[Summary]
[Previous]

Problem Description:

> 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.

> This is a critical bug.

Solution Description:

> Fixed in r41, verified by test88.

> 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.

[Top]
This page is maintained by Joe Linoff.
Last updated: $Date: 2004/09/30 16:09:26 $
This page was automatically generated by issues.pl.