|24| const std::string &purpose, const std::string &description) /*final*/ |23| SgAsmBlock* frontend(int argc, char *argv, |20| * markup language where characters have special meaning. |19| * The description is a full, multi-line description written in the () |17| * specify the purpose as "disassembles a binary specimen". |16| * with an upper-case letter, a hyphen, white space, or the name of the command. |15| * The purpose should be a single line string that will be shown in the title of the man page and should not start |13| * generating output much like a Unix man(1) page. |12| * The command-line supoprts a "-help" or ("-h") switch to describe all other switches and arguments, essentially | 9| * latter case, the vector should not include argv or argv (which is always a | 8| * The command-line can be provided as a typical argc and argv pair, or as a vector of arguments. | 6| * AST will lead eventually to an SgProject node. If the specimen consisted of an ELF or PE container then the parent nodes of the returned
The return value is a SgAsmBlock node that contains all | 4| * successful, then an abstract syntax tree is returned. | 3| * This method does everything from parsing the command-line to generating an abstract syntax tree. | 1| /** Most basic use of the partitioner. You can easily insert HTTP links into documentation.Use and to give the same documentation to both member functions.Use when referring to another class and when mentioning a parameter.First line (up to punctuation) is a summary – the autobrief string that shows up in tables of contents.Use C-style block comments for documentation.Here's an example that documents a couple of closely-related class member functions. An example is this page itself, which might change over time as ROSE evolves and which must go through ROSE's continuous integration testing and/or release testing. For documenting non-API things that are nonetheless tied to a particular version of ROSE.Doxygen is able to generate the structure of the documentation, and authors fill in the descriptions. ROSE uses Doxygen for two broad categories of documentation: Each item is also presented along with our motivation for doing it this way. The style enumerated here does not necessarily need to be used for projects, tests, the tutorial, user-code, etc. It specifies how we would like to have the ROSE library source code documented.
DOXYGEN FILE HEADER EXAMPLE SOFTWARE
This chapter is mainly for developers working on the ROSE library as opposed to users developing software that uses the library.
DOXYGEN FILE HEADER EXAMPLE HOW TO
How to write good API and non-API documentation in ROSE.
0 kommentar(er)
