Fossil SCM
Fix typos.
Commit
e693ab734e39f2e153de3555a95843ea8606d1b25fe48312c0b30f6792a3bc39
Parent
d08bc9e61f3abf2…
1 file changed
+8
-8
+8
-8
| --- src/makeheaders.html | ||
| +++ src/makeheaders.html | ||
| @@ -343,11 +343,11 @@ | ||
| 343 | 343 | headers at all. |
| 344 | 344 | Instead, makeheaders will write to standard output |
| 345 | 345 | information about every definition and declaration that it encounters |
| 346 | 346 | in its scan of source files. |
| 347 | 347 | The information output includes the type of the definition or |
| 348 | -declaration and any comment that preceeds the definition or | |
| 348 | +declaration and any comment that precedes the definition or | |
| 349 | 349 | declaration. |
| 350 | 350 | The output is in a format that can be easily parsed, and is |
| 351 | 351 | intended to be read by another program that will generate |
| 352 | 352 | documentation about the program. |
| 353 | 353 | We'll talk more about this feature later. |
| @@ -399,11 +399,11 @@ | ||
| 399 | 399 | any of the .h files you write since that will prevent makeheaders |
| 400 | 400 | from generating the .h file automatically. |
| 401 | 401 | </p> |
| 402 | 402 | |
| 403 | 403 | <p> |
| 404 | -The structure of a .c file intented for use with makeheaders is very | |
| 404 | +The structure of a .c file intended for use with makeheaders is very | |
| 405 | 405 | simple. |
| 406 | 406 | All you have to do is add a single “<code>#include</code>” to the |
| 407 | 407 | top of the file that sources the header file that makeheaders will generate. |
| 408 | 408 | Hence, the beginning of a source file named “<code>alpha.c</code>” |
| 409 | 409 | might look something like this: |
| @@ -591,13 +591,13 @@ | ||
| 591 | 591 | |
| 592 | 592 | <p> |
| 593 | 593 | In my experience, large projects work better if all of the manually |
| 594 | 594 | written code is placed in .c files and all .h files are generated |
| 595 | 595 | automatically. |
| 596 | -This is slightly different for the traditional C method of placing | |
| 596 | +This is slightly different from the traditional C method of placing | |
| 597 | 597 | the interface in .h files and the implementation in .c files, but |
| 598 | -it is a refreshing change that brings a noticable improvement to the | |
| 598 | +it is a refreshing change that brings a noticeable improvement to the | |
| 599 | 599 | coding experience. |
| 600 | 600 | Others, I believe, share this view since I've |
| 601 | 601 | noticed recent languages (ex: java, tcl, perl, awk) tend to |
| 602 | 602 | support the one-file approach to coding as the only option. |
| 603 | 603 | </p> |
| @@ -619,11 +619,11 @@ | ||
| 619 | 619 | #if INTERFACE |
| 620 | 620 | #endif |
| 621 | 621 | </pre> |
| 622 | 622 | Thus any structure definitions that appear after the |
| 623 | 623 | “<code>#if INTERFACE</code>” but before the corresponding |
| 624 | -“<code>#endif</code>” are eligable to be copied into the | |
| 624 | +“<code>#endif</code>” are eligible to be copied into the | |
| 625 | 625 | automatically generated |
| 626 | 626 | .h files of other .c files. |
| 627 | 627 | </p> |
| 628 | 628 | |
| 629 | 629 | <p> |
| @@ -684,11 +684,11 @@ | ||
| 684 | 684 | <p> |
| 685 | 685 | That isn't the complete truth, actually. |
| 686 | 686 | The semantics of C are such that once an object becomes visible |
| 687 | 687 | outside of a single source file, it is also visible to any user |
| 688 | 688 | of the library that is made from the source file. |
| 689 | -Makeheaders can not prevent outsiders for using non-exported resources, | |
| 689 | +Makeheaders can not prevent outsiders from using non-exported resources, | |
| 690 | 690 | but it can discourage the practice by refusing to provide prototypes |
| 691 | 691 | and declarations for the services it does not want to export. |
| 692 | 692 | Thus the only real effect of the making an object exportable is |
| 693 | 693 | to include it in the output makeheaders generates when it is run |
| 694 | 694 | using the -H command line option. |
| @@ -868,11 +868,11 @@ | ||
| 868 | 868 | </pre></blockquote> |
| 869 | 869 | |
| 870 | 870 | <p> |
| 871 | 871 | The first form is preferred because only a single declaration of |
| 872 | 872 | the constructor is required. The second form requires two declarations, |
| 873 | -one in the class definition and one on the defintion of the constructor. | |
| 873 | +one in the class definition and one on the definition of the constructor. | |
| 874 | 874 | </p> |
| 875 | 875 | |
| 876 | 876 | <h4>3.6.1 C++ Limitations</h4> |
| 877 | 877 | |
| 878 | 878 | <p> |
| @@ -1073,11 +1073,11 @@ | ||
| 1073 | 1073 | <li> The type of the object. (Structure, typedef, macro, etc.) |
| 1074 | 1074 | <li> Flags to indicate if the declaration is exported (contained within |
| 1075 | 1075 | an EXPORT_INTERFACE block) or local (contained with LOCAL_INTERFACE). |
| 1076 | 1076 | <li> A flag to indicate if the object is declared in a C++ file. |
| 1077 | 1077 | <li> The name of the file in which the object was declared. |
| 1078 | -<li> The complete text of any block comment that preceeds the declarations. | |
| 1078 | +<li> The complete text of any block comment that precedes the declarations. | |
| 1079 | 1079 | <li> If the declaration occurred inside a preprocessor conditional |
| 1080 | 1080 | (“<code>#if</code>”) then the text of that conditional is |
| 1081 | 1081 | provided. |
| 1082 | 1082 | <li> The complete text of a declaration for the object. |
| 1083 | 1083 | </ul> |
| 1084 | 1084 |
| --- src/makeheaders.html | |
| +++ src/makeheaders.html | |
| @@ -343,11 +343,11 @@ | |
| 343 | headers at all. |
| 344 | Instead, makeheaders will write to standard output |
| 345 | information about every definition and declaration that it encounters |
| 346 | in its scan of source files. |
| 347 | The information output includes the type of the definition or |
| 348 | declaration and any comment that preceeds the definition or |
| 349 | declaration. |
| 350 | The output is in a format that can be easily parsed, and is |
| 351 | intended to be read by another program that will generate |
| 352 | documentation about the program. |
| 353 | We'll talk more about this feature later. |
| @@ -399,11 +399,11 @@ | |
| 399 | any of the .h files you write since that will prevent makeheaders |
| 400 | from generating the .h file automatically. |
| 401 | </p> |
| 402 | |
| 403 | <p> |
| 404 | The structure of a .c file intented for use with makeheaders is very |
| 405 | simple. |
| 406 | All you have to do is add a single “<code>#include</code>” to the |
| 407 | top of the file that sources the header file that makeheaders will generate. |
| 408 | Hence, the beginning of a source file named “<code>alpha.c</code>” |
| 409 | might look something like this: |
| @@ -591,13 +591,13 @@ | |
| 591 | |
| 592 | <p> |
| 593 | In my experience, large projects work better if all of the manually |
| 594 | written code is placed in .c files and all .h files are generated |
| 595 | automatically. |
| 596 | This is slightly different for the traditional C method of placing |
| 597 | the interface in .h files and the implementation in .c files, but |
| 598 | it is a refreshing change that brings a noticable improvement to the |
| 599 | coding experience. |
| 600 | Others, I believe, share this view since I've |
| 601 | noticed recent languages (ex: java, tcl, perl, awk) tend to |
| 602 | support the one-file approach to coding as the only option. |
| 603 | </p> |
| @@ -619,11 +619,11 @@ | |
| 619 | #if INTERFACE |
| 620 | #endif |
| 621 | </pre> |
| 622 | Thus any structure definitions that appear after the |
| 623 | “<code>#if INTERFACE</code>” but before the corresponding |
| 624 | “<code>#endif</code>” are eligable to be copied into the |
| 625 | automatically generated |
| 626 | .h files of other .c files. |
| 627 | </p> |
| 628 | |
| 629 | <p> |
| @@ -684,11 +684,11 @@ | |
| 684 | <p> |
| 685 | That isn't the complete truth, actually. |
| 686 | The semantics of C are such that once an object becomes visible |
| 687 | outside of a single source file, it is also visible to any user |
| 688 | of the library that is made from the source file. |
| 689 | Makeheaders can not prevent outsiders for using non-exported resources, |
| 690 | but it can discourage the practice by refusing to provide prototypes |
| 691 | and declarations for the services it does not want to export. |
| 692 | Thus the only real effect of the making an object exportable is |
| 693 | to include it in the output makeheaders generates when it is run |
| 694 | using the -H command line option. |
| @@ -868,11 +868,11 @@ | |
| 868 | </pre></blockquote> |
| 869 | |
| 870 | <p> |
| 871 | The first form is preferred because only a single declaration of |
| 872 | the constructor is required. The second form requires two declarations, |
| 873 | one in the class definition and one on the defintion of the constructor. |
| 874 | </p> |
| 875 | |
| 876 | <h4>3.6.1 C++ Limitations</h4> |
| 877 | |
| 878 | <p> |
| @@ -1073,11 +1073,11 @@ | |
| 1073 | <li> The type of the object. (Structure, typedef, macro, etc.) |
| 1074 | <li> Flags to indicate if the declaration is exported (contained within |
| 1075 | an EXPORT_INTERFACE block) or local (contained with LOCAL_INTERFACE). |
| 1076 | <li> A flag to indicate if the object is declared in a C++ file. |
| 1077 | <li> The name of the file in which the object was declared. |
| 1078 | <li> The complete text of any block comment that preceeds the declarations. |
| 1079 | <li> If the declaration occurred inside a preprocessor conditional |
| 1080 | (“<code>#if</code>”) then the text of that conditional is |
| 1081 | provided. |
| 1082 | <li> The complete text of a declaration for the object. |
| 1083 | </ul> |
| 1084 |
| --- src/makeheaders.html | |
| +++ src/makeheaders.html | |
| @@ -343,11 +343,11 @@ | |
| 343 | headers at all. |
| 344 | Instead, makeheaders will write to standard output |
| 345 | information about every definition and declaration that it encounters |
| 346 | in its scan of source files. |
| 347 | The information output includes the type of the definition or |
| 348 | declaration and any comment that precedes the definition or |
| 349 | declaration. |
| 350 | The output is in a format that can be easily parsed, and is |
| 351 | intended to be read by another program that will generate |
| 352 | documentation about the program. |
| 353 | We'll talk more about this feature later. |
| @@ -399,11 +399,11 @@ | |
| 399 | any of the .h files you write since that will prevent makeheaders |
| 400 | from generating the .h file automatically. |
| 401 | </p> |
| 402 | |
| 403 | <p> |
| 404 | The structure of a .c file intended for use with makeheaders is very |
| 405 | simple. |
| 406 | All you have to do is add a single “<code>#include</code>” to the |
| 407 | top of the file that sources the header file that makeheaders will generate. |
| 408 | Hence, the beginning of a source file named “<code>alpha.c</code>” |
| 409 | might look something like this: |
| @@ -591,13 +591,13 @@ | |
| 591 | |
| 592 | <p> |
| 593 | In my experience, large projects work better if all of the manually |
| 594 | written code is placed in .c files and all .h files are generated |
| 595 | automatically. |
| 596 | This is slightly different from the traditional C method of placing |
| 597 | the interface in .h files and the implementation in .c files, but |
| 598 | it is a refreshing change that brings a noticeable improvement to the |
| 599 | coding experience. |
| 600 | Others, I believe, share this view since I've |
| 601 | noticed recent languages (ex: java, tcl, perl, awk) tend to |
| 602 | support the one-file approach to coding as the only option. |
| 603 | </p> |
| @@ -619,11 +619,11 @@ | |
| 619 | #if INTERFACE |
| 620 | #endif |
| 621 | </pre> |
| 622 | Thus any structure definitions that appear after the |
| 623 | “<code>#if INTERFACE</code>” but before the corresponding |
| 624 | “<code>#endif</code>” are eligible to be copied into the |
| 625 | automatically generated |
| 626 | .h files of other .c files. |
| 627 | </p> |
| 628 | |
| 629 | <p> |
| @@ -684,11 +684,11 @@ | |
| 684 | <p> |
| 685 | That isn't the complete truth, actually. |
| 686 | The semantics of C are such that once an object becomes visible |
| 687 | outside of a single source file, it is also visible to any user |
| 688 | of the library that is made from the source file. |
| 689 | Makeheaders can not prevent outsiders from using non-exported resources, |
| 690 | but it can discourage the practice by refusing to provide prototypes |
| 691 | and declarations for the services it does not want to export. |
| 692 | Thus the only real effect of the making an object exportable is |
| 693 | to include it in the output makeheaders generates when it is run |
| 694 | using the -H command line option. |
| @@ -868,11 +868,11 @@ | |
| 868 | </pre></blockquote> |
| 869 | |
| 870 | <p> |
| 871 | The first form is preferred because only a single declaration of |
| 872 | the constructor is required. The second form requires two declarations, |
| 873 | one in the class definition and one on the definition of the constructor. |
| 874 | </p> |
| 875 | |
| 876 | <h4>3.6.1 C++ Limitations</h4> |
| 877 | |
| 878 | <p> |
| @@ -1073,11 +1073,11 @@ | |
| 1073 | <li> The type of the object. (Structure, typedef, macro, etc.) |
| 1074 | <li> Flags to indicate if the declaration is exported (contained within |
| 1075 | an EXPORT_INTERFACE block) or local (contained with LOCAL_INTERFACE). |
| 1076 | <li> A flag to indicate if the object is declared in a C++ file. |
| 1077 | <li> The name of the file in which the object was declared. |
| 1078 | <li> The complete text of any block comment that precedes the declarations. |
| 1079 | <li> If the declaration occurred inside a preprocessor conditional |
| 1080 | (“<code>#if</code>”) then the text of that conditional is |
| 1081 | provided. |
| 1082 | <li> The complete text of a declaration for the object. |
| 1083 | </ul> |
| 1084 |