Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Fix typos. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
e693ab734e39f2e153de3555a95843ea |
User & Date: | ashepilko 2020-01-09 20:03:31.121 |
Context
2020-01-09
| ||
20:57 | Merge the latest SQLite 3.31.0 alpha sources for testing. ... (check-in: 5c48142d user: drh tags: trunk) | |
20:03 | Fix typos. ... (check-in: e693ab73 user: ashepilko tags: trunk) | |
15:29 | Modify the /doc webpage so that if the first term of the argument is "latest" it chooses the most recent check-in for the document regardless of what branch that check-in occurred on. ... (check-in: d08bc9e6 user: drh tags: trunk) | |
Changes
Changes to src/makeheaders.html.
︙ | ︙ | |||
341 342 343 344 345 346 347 | Finally, makeheaders also includes a “<code>-doc</code>” option. This command line option prevents makeheaders from generating any headers at all. Instead, makeheaders will write to standard output information about every definition and declaration that it encounters in its scan of source files. The information output includes the type of the definition or | | | 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 | Finally, makeheaders also includes a “<code>-doc</code>” option. This command line option prevents makeheaders from generating any headers at all. Instead, makeheaders will write to standard output information about every definition and declaration that it encounters in its scan of source files. The information output includes the type of the definition or declaration and any comment that precedes the definition or declaration. The output is in a format that can be easily parsed, and is intended to be read by another program that will generate documentation about the program. We'll talk more about this feature later. </p> |
︙ | ︙ | |||
397 398 399 400 401 402 403 | named “<code>alpha.h</code>”. For that reason, you don't want to use that name for any of the .h files you write since that will prevent makeheaders from generating the .h file automatically. </p> <p> | | | 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 | named “<code>alpha.h</code>”. For that reason, you don't want to use that name for any of the .h files you write since that will prevent makeheaders from generating the .h file automatically. </p> <p> The structure of a .c file intended for use with makeheaders is very simple. All you have to do is add a single “<code>#include</code>” to the top of the file that sources the header file that makeheaders will generate. Hence, the beginning of a source file named “<code>alpha.c</code>” might look something like this: </p> |
︙ | ︙ | |||
589 590 591 592 593 594 595 | <a name="H0009"></a> <h3>3.3 How To Avoid Having To Write Any Header Files</h3> <p> In my experience, large projects work better if all of the manually written code is placed in .c files and all .h files are generated automatically. | | | | 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 | <a name="H0009"></a> <h3>3.3 How To Avoid Having To Write Any Header Files</h3> <p> In my experience, large projects work better if all of the manually written code is placed in .c files and all .h files are generated automatically. This is slightly different from the traditional C method of placing the interface in .h files and the implementation in .c files, but it is a refreshing change that brings a noticeable improvement to the coding experience. Others, I believe, share this view since I've noticed recent languages (ex: java, tcl, perl, awk) tend to support the one-file approach to coding as the only option. </p> <p> |
︙ | ︙ | |||
617 618 619 620 621 622 623 | it were a .h file by enclosing that part of the .c file within: <pre> #if INTERFACE #endif </pre> Thus any structure definitions that appear after the “<code>#if INTERFACE</code>” but before the corresponding | | | 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 | it were a .h file by enclosing that part of the .c file within: <pre> #if INTERFACE #endif </pre> Thus any structure definitions that appear after the “<code>#if INTERFACE</code>” but before the corresponding “<code>#endif</code>” are eligible to be copied into the automatically generated .h files of other .c files. </p> <p> If you use the “<code>#if INTERFACE</code>” mechanism in a .c file, then the generated header for that .c file will contain a line |
︙ | ︙ | |||
682 683 684 685 686 687 688 | </p> <p> That isn't the complete truth, actually. The semantics of C are such that once an object becomes visible outside of a single source file, it is also visible to any user of the library that is made from the source file. | | | 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 | </p> <p> That isn't the complete truth, actually. The semantics of C are such that once an object becomes visible outside of a single source file, it is also visible to any user of the library that is made from the source file. Makeheaders can not prevent outsiders from using non-exported resources, but it can discourage the practice by refusing to provide prototypes and declarations for the services it does not want to export. Thus the only real effect of the making an object exportable is to include it in the output makeheaders generates when it is run using the -H command line option. This is not a perfect solution, but it works well in practice. </p> |
︙ | ︙ | |||
866 867 868 869 870 871 872 | v1 = 0; } </pre></blockquote> <p> The first form is preferred because only a single declaration of the constructor is required. The second form requires two declarations, | | | 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 | v1 = 0; } </pre></blockquote> <p> The first form is preferred because only a single declaration of the constructor is required. The second form requires two declarations, one in the class definition and one on the definition of the constructor. </p> <h4>3.6.1 C++ Limitations</h4> <p> Makeheaders does not understand more recent C++ syntax such as templates and namespaces. |
︙ | ︙ | |||
1071 1072 1073 1074 1075 1076 1077 | <ul> <li> The name of the object. <li> The type of the object. (Structure, typedef, macro, etc.) <li> Flags to indicate if the declaration is exported (contained within an EXPORT_INTERFACE block) or local (contained with LOCAL_INTERFACE). <li> A flag to indicate if the object is declared in a C++ file. <li> The name of the file in which the object was declared. | | | 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 | <ul> <li> The name of the object. <li> The type of the object. (Structure, typedef, macro, etc.) <li> Flags to indicate if the declaration is exported (contained within an EXPORT_INTERFACE block) or local (contained with LOCAL_INTERFACE). <li> A flag to indicate if the object is declared in a C++ file. <li> The name of the file in which the object was declared. <li> The complete text of any block comment that precedes the declarations. <li> If the declaration occurred inside a preprocessor conditional (“<code>#if</code>”) then the text of that conditional is provided. <li> The complete text of a declaration for the object. </ul> The exact output format will not be described here. It is simple to understand and parse and should be obvious to |
︙ | ︙ |