Doxygen might only save the names of functions where each variable and
function are referenced, but not the line numbers.
The html documentation has the line numbers, as does the rtf file, so
obviously it is tracking at some level.
I see that the call graphs are interspersed through the rtf file, but they
are not really grouped into a coherent structure.
And I never found them at all in the html generated stuff.
::#define CONTROL_TABLE 1
Definition at line 388 of file medbest_310_o_split.c.
::void adc_window_complete ()
Definition at line 5983 of file medbest_310_o_split.c.
5984 {
5985 }
::void adc_window_interrupt ()
Definition at line 5970 of file medbest_310_o_split.c.
5971 {
5972 }
::data char beep_count
Definition at line 1052 of file medbest_310_o_split.c.
::data int beep_duration
Definition at line 1053 of file medbest_310_o_split.c.
And the .rtf file lists the code for each function.
The HTML source listings Doxygen can generate contain algorithmically
generated anchors to serve as target for links from the generated
documentation, so line numbers are not needed.
Certainly would be good if it could produce a cross-reference with line
numbers.
Well, consider the issue raised :D . It just seems obvious.
I'm just a user of Doxygen.Â
I wonder if Dimitri monitors this list....
Even after comments blocks are automatically inserted, I would think you
will still have to do extensive editing to include descriptive prose.
You might, but they would just be padding on existing lines more or
less. So yes, but it is a lot easier and quicker to go into the code and
add the comments or descriptive prose to an
existing comment block.  1. You don't have to remember how to create
the block.  2. with the blocks in place, documentation would certainly
be easier.
My team and I have templates defined in the source code editors we use.
When reviewing/studying legacy code, we can insert the relevant temple and
fill in the descriptive prose. Or, more often, since what Doxygen needs is
so minimal, just type. for example:
/** One line description.
* More detail....
* @return Description of what's returned.
*/
or:
/**< One line description after a parameter or variable definition. More
detail.... */
There is the @brief and a ton more.
One of the things coming down in the medical device world, is compliance
with IEC 62304. One part of this requires detailed
architectural descriptions and diagrams. Current code will ultimately
have to be brought up to that standard, and all over the medical world,
people are having to back document programs.
I don't know what requirements IEC 62304 imposes, particularly on "in
line" code documentation.
It is a very long discussion :( But essentially it means for class A and
B, you have to document each software item, and create architectural
documents, etc.
For class C (stuff that can kill you) it gets really detailed, with having
to document all boundry conditions code flow and on and on...
part of the checklist B and C are classes.
[B, C] The manufacturer transformed the requirements for the medical device
software into a documented architecture that describes the softwares
structure and identifies the software items
[B, C] The manufacturer developed and documented an architecture for the
interfaces between the software items and the components external to the
software items (both software and hardware), and between the software items
[B, C] If a software item is identified as soup, the manufacturer specified
functional and performance requirements for the soup item that are
necessary for its intended use
[B, C] If a software item is identified as soup, the manufacturer specified
the system hardware and software necessary to support the proper operation
of the soup item
[C] The manufacturer identified the segregation between software items that
is essential to risk control, and state how to ensure that the segregation
is effective
[B, C] The manufacturer verified and document that:
a) the architecture of the software implements system and software
requirements including those relating to risk control
b) the software architecture is able to support interfaces between software
items and between software items and hardware
c) the medical device architecture supports proper operation of any soup items
[B, C] The manufacturer refined the software architecture until it is
represented by software units
[C] The manufacturer developed and documented a detailed design for each
software unit of the software item
Feeding the output of Doxygen back in to the source files is possible.
Most probably something to be done using a post processor.
Â
I have attached a file, and hope it comes through.
current_intensity is the variable. This shows that build_array uses it,
as do a bunch of the routines that build array calls.
There are many other places in the code where this variable are referenced.
Right now, Doxygen can produce a call graph similar to what your charts
shows in relation to "build_array" and what it calls.
Enhancing Doxygen to product a (textural) cross-reference should not be
hard. However, I can't speak to the internals of Doxygen.
The chart you produced with Source Insight is a hybrid of a call graph and
a graphical cross-reference. That is most likely best implemented as a
post processor.
Probably. You can turn off the cross reference, in which case it is a call
graph.
Â
Doxygen has the info to do this, or would with an extension. I was
hoping that graphvis would be able to take Doxygen's data
and produce this kind of diagram automatically for each function,
variable, and data structure.
With a cross-reference and the output Doxygen currently produces, post
processing should be able to produce most kinds of (code) relationship
diagrams.
Flow diagrams would require help from additional analysis tools.
Unfortunately, all such tools I know of that provide the kind of
sophisticated analysis that Source Insight does are expensive, proprietary
tools that work much like you describe Source Insight, unless you add
expensive, optional reporting extensions.
Well source insight isn't exactly cheap, around 239.00 or so. But it isn't
a flow analysis tool per se.
http://www.sourceinsight.com/eval.html you can download a 30 day trial,
and there are keys on the net.
I was one of Ray Grahms early beta testers.
It is one of the coolest editors ever, with full syntax coloring and
parsing for literally dozens of languages, and a fully documented api that
you can extend.
an more nifty features than you can shake a stick at.
Graphvis is just a tool for interpreting description in DOT notation in to
graphical charts. It has no analysis capability. Doxygen uses it because
it was much easier to use it than to attempt to produce such diagrams directly.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Doxygen-users mailing list
Doxygen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-users
