doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Using Doxygen also for HDL ?

[<fpg...@ar...>]

Dear all, in a german newsgroup, the idea came up recently to use doxy also=
 for HDL sources.
Would you consider this reasonable / easily possible to make real?

What in case would be the required steps to do so?

thanks in advance



Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: g=FCnsti=
g
und schnell mit DSL - das All-Inclusive-Paket f=FCr clevere Doppel-Sparer,
nur  44,85 =80  inkl. DSL- und ISDN-Grundgeb=FChr!
http://www.arcor.de/rd/emf-dsl-2

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Chris C. <do...@ke...>]

On Wed, Nov 29, 2006 at 09:21:31AM -0800, Jason McKesson wrote:

> The old XML format would still be there; I didn't want to break anyone
> who might be using it, and it made a good template to match my results
> against.

[Summary of new format snipped]

That sounds like something in which I would very much be interested.  I
started making a system to generate InfoTeX (as used by most GNU
software) from the XML, but ran into the problems you describe (and my
XSLT knowledge isn't good enough to work round them -- if XSLT has only
'limited' ability to parse strings, I didn't know that it had any!).

Chris C

Re: [Doxygen-develop] Interest in new XML format for Doxygen export

[Jason M. <ko...@gm...>]

The old XML format would still be there; I didn't want to break anyone
who might be using it, and it made a good template to match my results
against.

There are several problems with the old XML format that made it
difficult to use. Or, rather, difficult to use when attempting to
generate non-Doxygen-like documentation.

First, there are repeats of information. For example, if you mark a
function as virtual, there will be an attribute named virtual, but the
return type will also include the word "virtual". This makes it
difficult to not include that word if you wish to, in the final form
of the docs, move that word elsewhere.

Second, the general structure of the documentation mirrors Doxygen
rather than a more presentation-neutral format. As an example, public,
private, etc members are all added to member groups in DoxygenXML.
Having an XSLT processor to automatically generate these member groups
would be trivially easy, but it now become harder to "ungenerate" them
if you wish to order the members in some other way.

Third, there are certain... issues with regard to the ownership of
various members. Does the file own them (and therefore have the
documentation for them)? Does the namespace? Does a Module? Where a
documented member (that has no class) lives is not easily determined.
This means that an XSLT that need to, for example, generate a list of
all members, or all global members, or all members of some scope,
needs to do a lot of work. It has to look in files, namespaces, and
Modules before it can be sure it hasn't missed something. Of course,
if your output documentation looks Doxygen-like (with output pages for
each), this isn't a problem. But if it doesn't...

Lastly, a lot of the naming makes it difficult to present the name of
an object in the way you want rather than the way Doxygen wants. For
example, the name of a class is its fully-scoped name. This is
needless, because an XSLT can easily generate a fully-scoped name from
just the containment hierarchy and the short-name of an object.
However, an XSLT cannot easily generate a short-name (text parsing is
not XSLT's strong suit) from the fully-qualified name.

So, I rewrote the format entirely.

Under the new format, all documented language elements (classes,
namespaces, members) live in their own section. This section
structurally mirrors the containment defined by the organization of
the source code. There is an explicit global scope, for example. This
global scope holds all global classes, namespaces, and members.
Namespaces can hold namespaces, classes, and members, while Classes
can only have other classes and members.

Modules and files are merely documented elements with a list of
references to the other documented language elements. And Pages are
just blobs of documentation without any references whatsoever (well,
no list of them rather. They can still have textual references in the
documentation).

On 11/29/06, Dimitri van Heesch <do...@gm...> wrote:
> Hi Jason,
>
> Please let me know. I'm interesting in what it looks like and why you need it.
>
> Regards,
>   Dimitri
>
>
> On 11/28/06, Jason McKesson  <ko...@gm...> wrote:
> > I am currently working on exporting a new XML format from Doxygen. I was  wondering if there would be some interest in integrating this into the  main line when it is finished.
> >
> > If you want more details about how this format differs from the current  Doxygen XML format, please let me know.
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > Doxygen-develop mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> >
> >
> >
>
>

[Doxygen-develop] Interest in new XML format for Doxygen export

[Jason M. <ko...@gm...>]

I am currently working on exporting a new XML format from Doxygen. I was
wondering if there would be some interest in integrating this into the main
line when it is finished.

If you want more details about how this format differs from the current
Doxygen XML format, please let me know.

Re: [Doxygen-develop] feature request: utf encoding

[<pm...@fr...>]

On Sat, 25 Nov 2006, Jens Seidel wrote:

> Using UTF-8 per default would also allow to drop the stupid Use Windows
> encoding option in the config file.

Or even better: instead of
USE_WINDOWS_ENCODING = yes/no
something like
USE_ENCODING = utf-8/iso-8859-1/iso-8859-15/etc. (default = utf-8)

>      /*! return the language charset. This will be used for the HTML output */
>      virtual QCString idLanguageCharset()
>      {
> -      return "iso-8859-1";
> +      return "UTF-8";
>      }

Thanks! For the time being, I'll use this part of your patch.
Cheers, Peter

-- 
http://pmrb.free.fr/contact/

Re: [Doxygen-develop] feature request: utf encoding

[Jens S. <jen...@us...>]

Hi Peter,

On Fri, Nov 24, 2006 at 06:43:30PM +0100, Peter M=FCnster wrote:
> since the encoding of my source files is utf-8 since some time, would i=
t be
> possible to add utf support to doxygen?

of course. It should be not very difficult.

> For HTML, this means
> <meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3Dutf-8"=
>
> instead of
> <meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3Diso-88=
59-1">

I tried it once for German documents but did not complete it.
Nevertheless the attached patch give should you sufficient ideas what
needs to be changed. (translator_de.h needs to be recoded to UTF-8 as
well, this is missing in the patch to keep it small.)

HTML is trivial, but do not forget other output formats. LaTeX could
cause trouble. I noticed failures for a special Doxygen configuration.
I think it was the PDF output created via LaTeX which failed because of a
missing escaping of "_" but I forgot about it.

After manual fixing two or three escaping errors I was able to process a
large document containing German and Russian texts.

Manual pages should also not depend on the encoding (the manual page
encoding is hardcoded into man. It may be necessary to recode these from
UTF-8 via an external script on systems which expect classical
encodings).

I don't know the RTF format.

Using UTF-8 per default would also allow to drop the stupid Use Windows
encoding option in the config file.
It's also still possible to use INPUT_FILTER =3D "iconv -f iso-8859-1 -t =
UTF-8 -c"
for latin1 encoded source to keep these workings.

Jens

[Doxygen-develop] feature request: utf encoding

[<pm...@fr...>]

Hello,

since the encoding of my source files is utf-8 since some time, would it be
possible to add utf support to doxygen?

For HTML, this means
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
instead of
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">

Greetings and thanks a lot for this great tool, I use it more and more!
Peter

-- 
http://pmrb.free.fr/contact/

Re: [Doxygen-develop] One more time for Ada...

[Jeffrey C. <je...@th...>]

Arnold.Steve wrote:

>Howdy:
>
>I've been through the archives, and seen the few posts like this in past
>(ie, asking about and Ada95 support), and I'm curious about the current
>state of affairs.  The most recent post was a little over a year ago,
>with one reply:
>
>http://sourceforge.net/mailarchive/message.php?msg_id=12464688
>
>Does anyone know the status of the above attempt?  Is there anything I
>can leverage, or would I be essentially starting from scratch?  Since
>there are some similarities with Pascal, has anyone tried modifying the
>Pascal helper tool?
>  
>

I've not heard anything recently (might be worth a post on 
comp.lang.ada). If you start and it is too raw for inclusion in the main 
doxygen tree during the early development (not sure what the policies 
are) you may want to consider doing the work as a side project under 
gnuada.sf.net.

The SWIG bindings generator Ada work is being done in SVN there prior to 
being in good enough shape to be accepted into the SWIG tree.

That way, if you only get half way and stop, someone can actually pick 
up from where you left off.

[Doxygen-develop] Matthew Duggan is out of the office.

[Matthew D. <du...@us...>]

I will be out of the office starting  11/20/2006 and will not return until
11/27/2006.

Happy Thanksgiving!!! I will respond to your message when I return.

[Doxygen-develop] One more time for Ada...

[Arnold.Steve <arn...@en...>]

Howdy:

I've been through the archives, and seen the few posts like this in past
(ie, asking about and Ada95 support), and I'm curious about the current
state of affairs.  The most recent post was a little over a year ago,
with one reply:

http://sourceforge.net/mailarchive/message.php?msg_id=3D12464688

Does anyone know the status of the above attempt?  Is there anything I
can leverage, or would I be essentially starting from scratch?  Since
there are some similarities with Pascal, has anyone tried modifying the
Pascal helper tool?

Any pointers would be great, as I'm seriously considering trying to fill
this hole myself (no promises :), but it seems a lot simpler to write a
pre-processor of some kind than a brand new parser module...

Thanks in advance, Steve Arnold


The information contained in this email message is intended only for the us=
e of the individuals to whom it is addressed and may contain information th=
at is privileged and sensitive. If the reader of this message is not the in=
tended recipient, you are hereby notified that any dissemination, distribut=
ion or copying of this communication is strictly prohibited. If you have re=
ceived this communication in error, please notify the sender immediately by=
 email at the above referenced address. Thank you.

[Doxygen-develop] how to store meta information about parsed files

[w.goesgens <roo...@ou...>]

<html><body>

<p>hy, I want to implement something, that is parametrized with lines or=20=
line ranges,<br />and stores something like an xpath to the points matchi=
ng those lines for later use.</p><p>It should make one to&nbsp; know, in=20=
which function or object range these lines are...<br /></p><p>Is there an=
 easy way to add this in doxygen? where should i start reading?<br /></p>=
<p>My plans are to create something like function based blame anotation t=
o my </p><p>doxygen generated documentation, so i can easily figure out,=20=
who changed </p><p>a specific function in for example svn, and have a sho=
rt step to something viewing me the </p><p>diff of that action.&nbsp;</p>=
<p>&nbsp;</p><p>Tia, Wilfried Goesgens&nbsp;</p>
</body></html>

[Doxygen-develop] Better handling of typedef's

[Matthew W. <mwo...@ti...>]

I have a project with a bunch of typedef's of the nature 'typedef struct 
foo_struct foo_struct, *foo'. What I would like is for Doxygen to a: not 
generate 'not documented' warnings for 'foo' if 'foo_struct' is 
documented, and b: to ALWAYS cause '::foo' to resolve to a link to 
'foo_struct' (right now this works in parameter lists, but not in most 
other places).

Any suggestions? Anyone know about where to go looking if I wanted to 
try to fix this myself?

-- 
Matthew
$ kill bill - kill: can't find process "bill"

Re: [Doxygen-develop] request for bugfix release

[Dimitri v. H. <di...@st...>]

Hi Jason,

I was indeed thinking about a new release but first want to solve the
most pressing issues found so far. So a new release should appear
within the next week(s).

Regards,
  Dimitri

On Fri, Oct 20, 2006 at 11:38:42PM -0400, Jason Ferrara wrote:
> What are the chances of getting a quick 1.5.1 (or 1.5.0.1) release  
> with fixes from
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=363067
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=363227
> 
> and
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=363828
> 
> 
> I think they're pretty much required in order to use doxygen on  
> python sources.
> 
> I'm asking because I'd like to be able to use an official release,  
> rather than a custom patched version.
> 
> Thanks
> 
> - J
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] request for bugfix release

[Jason F. <jas...@ja...>]

What are the chances of getting a quick 1.5.1 (or 1.5.0.1) release  
with fixes from

http://bugzilla.gnome.org/show_bug.cgi?id=363067

http://bugzilla.gnome.org/show_bug.cgi?id=363227

and

http://bugzilla.gnome.org/show_bug.cgi?id=363828


I think they're pretty much required in order to use doxygen on  
python sources.

I'm asking because I'd like to be able to use an official release,  
rather than a custom patched version.

Thanks

- J

[Doxygen-develop] undocumented return type warning

[Robbie G. <ro...@m8...>]

Hi All,

Thanks for a very useful tool!

I was a little confused about why i didn't seem to be getting warnings
about failing to give @return directives. I took a look at the code,
and unless i'm mistaken the tests around line 449 in docparser.cpp
have the wrong sense - i.e. they ignore missing @return for
nonconstructors and nondestructors rather than constructors and
destructors. Reversing the sense seems to give warnings as expected.
Unfortunately, one also gets warnings for non function members. This
can be fixed by checking memberType() before issuing the warning near
line 2285 in src/memberdef.cpp, but maybe there is a more appropriate
fix ?

I'm using doxygen-1.5.0 compiled from source on win32.

 - robbie

src/docparser.cpp
@@ -449,8 +449,8 @@
         g_memberDef->hasDocumentedReturnType() ||
         returnType.isEmpty() ||          // empty return type
         returnType.find("void")!=-1  ||  // void return type
-        !g_memberDef->isConstructor() || // a constructor
-        !g_memberDef->isDestructor()     // or destructor
+        g_memberDef->isConstructor() || // a constructor
+        g_memberDef->isDestructor()     // or destructor
        )
     {
       g_memberDef->setHasDocumentedReturnType(TRUE);

src/memberdef.cpp
@@ -2285,7 +2285,7 @@
           "Warning: parameters of member %s are not (all) documented",
           qualifiedName().data());
     }
-    if (!hasDocumentedReturnType())
+    if (!hasDocumentedReturnType() && (MemberDef::Function == memberType()))
     {
       warn_doc_error(docFile(),docLine(),
           "Warning: return type of member %s is not documented",

[Doxygen-develop] Extracting Comments using doxygen

[Seema K. <see...@gm...>]

Hi

 I would like to know whether Doxygen can be used to extract comments from a
C/C++ code?

 For example , consider the file Abc.c

Abc.c

# include <stdio.h>

/*
        Func           : Sum()
        Arg             : int x, int y
        Return Type : int
        Desc           : Function which returns the sum of values passed
*/

int Sum(int x, int y)
{
        return x + y;
}

/*
        Func            : main()
        Arg              : None
        Return Type :  void
        Desc           : Main Function
*/

main()
{
        int sum;
        sum =   Sum();
        printf("Sum : %d\n, sum");
}


My question is whether I can get the output as given below

/*
        Func           : Sum()
        Arg             : int x, int y
        Return Type : int
        Desc           : Function which returns the sum of values passed
*/

/*
        Func            : main()
        Arg              : None
        Return Type :  void
        Desc           : Main Function
*/

Making myself more clear, can I get the commented lines as output if I give
a C/C++ code as input ?
Thanks in advance.


Regards,
Seema Kadavan

Re: [Doxygen-develop] 1.5.0 crash

[Kevin M. <ke...@pl...>]

I have imported this bug into the bugzilla.  The link is:

http://bugzilla.gnome.org/show_bug.cgi?id=363067


To help us out with the bug statistics, we would appreciate it if you
file bugs within the bugzilla.  :)

- KJM


Jason Ferrara wrote:
> I just upgraded from 1.4.7 to 1.5.0, and 1.5.0 is crashing on a set
>  of sources (python) for which 1.4.7 worked.
> 
> It's failing at line 758 of pycode.l (the full call stack is below).
> 
> if (g_currentDefinition) { DefinitionIntf *di =
> Doxygen::symbolMap->find(symName); -->   if
> (di->definitionType()==DefinitionIntf::TypeSymbolList) // multiple
> symbols
> 
> di = 0x0000000, which is causing the crash.
> 
> I don't know if this matters, but symName = "SuspendLayout", which is
>  a method my code calls, but the definition of that method doesn't 
> exist in any of the source that doxygen is parsing.
> 
> Call stack:
>> doxygen.exe!findMemberLink(CodeOutputInterface & ol={...}, char *
>> 
> symName=0x01eecf22)  Line 758 + 0x3 bytes	C++ 
> doxygen.exe!pycodeYYlex()  Line 963 + 0x15 bytes	C++ 
> doxygen.exe!parsePythonCode(CodeOutputInterface & od={...}, const 
> char * className=0x009aac56, const QCString & s={...}, bool 
> exBlock=false, const char * exName=0x009aac56, FileDef * 
> fd=0x0174cd38, int startLine=-1, int endLine=-1, bool 
> inlineFragment=true, MemberDef * __formal=0x00000000)  Line 1427	C++ 
> doxygen.exe!PythonLanguageScanner::parseCode(CodeOutputInterface & 
> codeOutIntf={...}, const char * scopeName=0x00000000, const QCString
>  & input={...}, bool isExampleBlock=false, const char * 
> exampleName=0x00000000, FileDef * fileDef=0x0174cd38, int 
> startLine=-1, int endLine=-1, bool inlineFragment=false, MemberDef *
>  memberDef=0x00000000)  Line 1592 + 0x2d bytes	C++ 
> doxygen.exe!FileDef::writeSource(OutputList & ol={...})  Line 664 +
>  0x89 bytes	C++ doxygen.exe!generateFileSources()  Line 6748 + 0xe
> bytes	C++ doxygen.exe!generateOutput()  Line 9636	C++ 
> doxygen.exe!main(int argc=2, char * * argv=0x015f2de0)  Line 39	C++ 
> doxygen.exe!__tmainCRTStartup()  Line 318 + 0x19 bytes	C 
> doxygen.exe!mainCRTStartup()  Line 187	C kernel32.dll!7c816fd7() 
> [Frames below may be incorrect and/or missing, no symbols loaded for
>  kernel32.dll] ntdll.dll!7c911414() 
> doxygen.exe!ManGenerator::enable()  Line 35 + 0x43 bytes	C++ 
> doxygen.exe!FTVHelp::generateIndent(QTextStream & t={...}, FTVNode *
>  n=0x0075006c, int level=115)  Line 468	C++ 
> doxygen.exe!Config::check()  Line 1217 + 0x1d bytes	C++ 
> doxygen.exe!commentScanYYlex()  Line 1420 + 0xb bytes	C++ 8b00a155()
> 
> 
> 
> Let me know if I can supply any other information that would help, or
>  if there are any suggestions on what to look at. This is my first 
> look at the doxygen source, so I'm still finding my way around.
> 
> Thanks
> 
> - J 
> -------------------------------------------------------------------------
>  Using Tomcat but need to do more? Need to support web services,
> security? Get stuff done quickly with pre-integrated technology to
> make your job easier Download IBM WebSphere Application Server
> v.1.0.1 based on Apache Geronimo 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  _______________________________________________ Doxygen-develop
> mailing list Dox...@li... 
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
> 


-- 
This message has been digitally signed with a GlobalSign-issued certificate.
For more information, please visit GlobalSign's web site at:
http://www.globalsign.net/

Re: [Doxygen-develop] 1.5.0 crash

[Jason F. <jas...@ja...>]

Attached is a small test case that reproduces the problem. I get the  
crash under Windows and MacOS. I haven't tried other platforms.

[Doxygen-develop] 1.5.0 crash

[Jason F. <jas...@ja...>]

I just upgraded from 1.4.7 to 1.5.0, and 1.5.0 is crashing on a set =20
of sources (python) for which 1.4.7 worked.

It's failing at line 758 of pycode.l (the full call stack is below).

     if (g_currentDefinition)
     {
       DefinitionIntf *di =3D Doxygen::symbolMap->find(symName);
-->   if (di->definitionType()=3D=3DDefinitionIntf::TypeSymbolList) // =20=

multiple symbols=00

di =3D 0x0000000, which is causing the crash.

I don't know if this matters, but symName =3D "SuspendLayout", which is =20=

a method my code calls, but the definition of that method doesn't =20
exist in any of the source that doxygen is parsing.

Call stack:
 >	doxygen.exe!findMemberLink(CodeOutputInterface & ol=3D{...}, =
char * =20
symName=3D0x01eecf22)  Line 758 + 0x3 bytes	C++
	doxygen.exe!pycodeYYlex()  Line 963 + 0x15 bytes	C++
	doxygen.exe!parsePythonCode(CodeOutputInterface & od=3D{...}, =
const =20
char * className=3D0x009aac56, const QCString & s=3D{...}, bool =20
exBlock=3Dfalse, const char * exName=3D0x009aac56, FileDef * =20
fd=3D0x0174cd38, int startLine=3D-1, int endLine=3D-1, bool =20
inlineFragment=3Dtrue, MemberDef * __formal=3D0x00000000)  Line 1427	=
C++
	doxygen.exe!PythonLanguageScanner::parseCode(CodeOutputInterface =
& =20
codeOutIntf=3D{...}, const char * scopeName=3D0x00000000, const QCString =
=20
& input=3D{...}, bool isExampleBlock=3Dfalse, const char * =20
exampleName=3D0x00000000, FileDef * fileDef=3D0x0174cd38, int =20
startLine=3D-1, int endLine=3D-1, bool inlineFragment=3Dfalse, MemberDef =
* =20
memberDef=3D0x00000000)  Line 1592 + 0x2d bytes	C++
	doxygen.exe!FileDef::writeSource(OutputList & ol=3D{...})  Line =
664 + =20
0x89 bytes	C++
	doxygen.exe!generateFileSources()  Line 6748 + 0xe bytes	=
C++
	doxygen.exe!generateOutput()  Line 9636	C++
	doxygen.exe!main(int argc=3D2, char * * argv=3D0x015f2de0)  Line =
39	C++
	doxygen.exe!__tmainCRTStartup()  Line 318 + 0x19 bytes	C
	doxygen.exe!mainCRTStartup()  Line 187	C
	kernel32.dll!7c816fd7() =09
	[Frames below may be incorrect and/or missing, no symbols loaded =
for =20
kernel32.dll]=09
	ntdll.dll!7c911414() =09
	doxygen.exe!ManGenerator::enable()  Line 35 + 0x43 bytes	=
C++
	doxygen.exe!FTVHelp::generateIndent(QTextStream & t=3D{...}, =
FTVNode * =20
n=3D0x0075006c, int level=3D115)  Line 468	C++
	doxygen.exe!Config::check()  Line 1217 + 0x1d bytes	C++
	doxygen.exe!commentScanYYlex()  Line 1420 + 0xb bytes	C++
	8b00a155()=09
=00

Let me know if I can supply any other information that would help, or =20=

if there are any suggestions on what to look at. This is my first =20
look at the doxygen source, so I'm still finding my way around.

Thanks

- J=

[Doxygen-develop] Importing External Documentation

[Brendon C. <bc...@av...>]

Hi all,

I have for a while now been working on a tool that documents exception
propagation through C++ code. It is basically a GCC extension that
generates files with information about the call graph and also
information about exceptions originated from any particular function.

After gcc has generated this information i use a post processing tool
that calculates based on the call graph what exceptions may propagate
through a function.

It does its best to take into account virtual functions, function
pointers and other forms of runtime function calling.


Anyhow it is now starting to work and want to integrate this
information into the output of running doxygen. I.e. have doxygen read
a file that my post processing tool generates and use that to
automatically populate the exception information for all functions (As
though the user provided doxygen with a \throw command)

I could not find a way of achieving this with doxygen as it currently
stands.

As an example of what i would do, for the following code:
----------------------------
class Exception
{

};

void Function(int blah, float f)
{
	int i = 0;
	throw i;
}

static void Func2()
{

}

int main()
{
	Function(0, 0.0f);
	throw Exception;
	return 0;
}

----------------------------
I would generate an output file that looks something like:


F ::int ::main()
O ::Exception
P ::int

F ::void ::Function(::int, ::float)
O ::int

F ::void ::Func2() : ./src/main.cpp


----------------------------
In this file if the line starts with

F then it defines the name of a function
O it defines an exception that that function originates
P it defines an exception that can propagate through that function

Note that the name of the function for static functions includes the
name of the file in which the static function belongs.


Now this format is just what i have been using for my testing
purposes. I can change it however to better suite importing into doxygen.

Could doxygen be easily modified to gather information from a single
file in order to add additional documentation to various functions?

Does it already support some sort of functionality like this that i
could leverage?

What would be the best "format" for me to present this information in
for doxygen?

Just thinking aloud, would it would if I created a file like below and
included that to be processed with the rest of the source files?

Will this overwrite the existing documentation for those functions etc
or just add to it?


/*! \fn main()
 *
 * \throws Exception
 * \throws int
 */


/*! \fn Function(int, float)
 *
 * \throws int
 */

/*! \fn Func2()
 *
 */



Thanks for any help.
Brendon.

[Doxygen-develop] PATCH: Add tags for tabular lists, take 2

[mwoehlke <mwo...@ti...>]

This is an improved version of my previous patch to add '\li2' and 
'\li3' tags to Doxygen.

This adds \li2 and \li3 tags to Doxygen (diff'd against 1.4.7). \li2 is 
identical to \param except that it does not cause a section to be 
created, and so can be used with custom sections (\par) or in the 
detailed description. \li3 uses the first (typically unused, except for 
\param with [in], [out], [in,out]) column to make three-column lists 
(\li2 does 2-column lists, obviously); it treats '-' as an empty cell.

This second version attempts to support the other formats (man, rtf, 
latex) as well, although the latex support is a WAG (because I don't 
know latex and don't have latex to play around with it); man however I 
do know and should be OK. This also contains a file with suggested doc, 
although I didn't patch it because my cursory glance at the existing doc 
did not reveal any obvious logic for where in the existing doc this 
should be placed (the order is not simply alphabetical).

This could still benefit from allowing \li2 and \li3 to be mixed, 
although that would either violate some coding principles (assign both 
the same internal type, but parse differently) or make the code a good 
deal more complicated than the existing hack of treating '-' as an empty 
word.

-- 
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)

[Doxygen-develop] new release of moritz the nassi-shneiderman generator for doxygen is available

[<Eck...@t-...>]

Hello Everybody.

Since yesterday a new release of moritz the nassi-shneiderman generator 
for doxygen is available under https://sourceforge.net/projects/moritz/.
Moritz can generate links to the other parts of the doxygen-output now. 
It is also possible to insert links to other html-files manually.

Please try it out and use the forum on the sourceforge-side of moritz to 
ask question or to post comments.

I'm still a linux new-be so I hope all linux-users are able to use the 
linux-distribution. I call it suse because I was only able to test it on 
a suse 9.0 sytstem. But it should work also on other systems. I also 
hope that it is no great problem that I used zip to build the 
archive-files for the distributions and documentations.

I think the next steps are:

1. debugging
2. creating a configuration to generate the diagrams as dot-files the 
user may use with dotinclude for other file-formats the html.
3. writing a tutorial.
4. programming a gui-wizard

If you have questions or suggestions please don't hesitate to post them 
in the forum under: https://sourceforge.net/projects/moritz/

Kind Regards,
                         Eckard Klotz

Re: [Doxygen-develop] Compile problem on x86_64

[Braden M. <br...@en...>]

On Fri, 2006-09-29 at 17:00 -0500, Dirk Reiners wrote:
>     Hi All,
> 
> I had a little compile problem on x86_64, concerning pointer casts. I 
> have a tiny patch that makes it work for me.

Generally when casting between pointers and integers, you want to use
ptrdiff_t.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[Doxygen-develop] Patch: Aliases with Arguments (TODO #28)

[Dirk R. <re...@ca...>]

    Hi Y'all (I've been living in Louisiana too long ;),

I wrote a little patch to support arguments in aliases. It's very simple 
and not very elegant, but it works fine.

Usage is trivial. In the aliases arguments need to be marked with 
^<number>^, like this:
 
ALIASES      = "al1=*AL1*" \
               "al2=*AL2:^1^*" \
               "al3=*AL3:^1^ -> ^2^*"

When using the alias the arguments are passed in parentheses after the 
alias (like C macros) and separated by ',' (which can be escaped if 
necessary):

Alias with one arg: \al2(ARG) will be "*AL2:ARG*"
Alias with one arg and escaped ',': \al2(ARG\,BLARG) will be 
"*AL2:ARG,BLARG*"
Alias with two args: \al3(FOO,BAR) will be "*AL3:FOO -> BAR*"

If an alias is called without () no argument substitution is done, so 
all existing documentation should work just fine.

Currently the maximum number of arguments is fixed at 20, which 
hopefully is enough.

The path is against current CVS.

Hope you find it useful
  
    Dirk

[Doxygen-develop] Compile problem on x86_64

[Dirk R. <re...@ca...>]

    Hi All,

I had a little compile problem on x86_64, concerning pointer casts. I 
have a tiny patch that makes it work for me.

Hope it's useful

    Dirk

Index: objcache.cpp
===================================================================
RCS file: /cvsroot/doxygen/src/objcache.cpp,v
retrieving revision 1.1
diff -u -3 -p -r1.1 objcache.cpp
--- objcache.cpp    10 Sep 2006 20:46:22 -0000    1.1
+++ objcache.cpp    29 Sep 2006 21:45:49 -0000
@@ -179,7 +179,7 @@ unsigned int ObjCache::hash(void *addr)
   // Thomas Wang's 32 bit Mix Function
 
-  // TODO: what if sizeof(void*)!=4 ?
-  unsigned int key = (unsigned int)addr;
+  unsigned int key = (unsigned int) (unsigned long) (addr);
   key += ~(key << 15);
   key ^=  (key >> 10);
   key +=  (key << 3);