boost/wave
2
0
Fork 0
mirror of https://github.com/boostorg/wave.git synced 2026-01-19 04:42:16 +00:00
Code Issues Projects Releases Wiki Activity

Correct various minor typos (#99)

Browse Source
This commit is contained in:
Jeff Trull
2020-06-17 22:36:46 -07:00
committed by GitHub
parent 8504d24bf8
commit 4e6c4fbd2e
12 changed files with 38 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/class_ref_ctxpolicy_depr.html
View File

@@ -92,7 +92,7 @@ Time Configuration</a> section. By default the new interface is used starting Bo
<span class="keyword">void</span> <a href="class_reference_ctxpolicy.html#returning_from_include_file">returning_from_include_file</a>();
<span class="comment">// interpretation of #pragma's of the form </span>
<span class="comment">// interpretation of #pragmas of the form </span>
<span class="comment">// 'wave option[(value)]'</span>
<span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;
bool <a href="class_reference_ctxpolicy.html#interpret_pragma">interpret_pragma</a>(ContextT <span class="keyword">const</span> &amp;ctx, ContainerT &amp;pending,
@@ -264,7 +264,7 @@ Time Configuration</a> section. By default the new interface is used starting Bo
<p>The function <tt>returning_from_include_file</tt> is called whenever an
included file is about to be closed after it's processing is complete.</p>
</blockquote>
<h3>Interpretation of #pragma's</h3>
<h3>Interpretation of #pragmas</h3>
<p><strong><a name="interpret_pragma"></a>interpret_pragma</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;
bool <a href="class_reference_ctxpolicy.html#interpret_pragma">interpret_pragma</a>(ContextT <span class="keyword">const</span> &amp;ctx, ContainerT &amp;pending,

18
doc/class_reference_context.html
View File

@@ -118,7 +118,7 @@
<tbody>
<tr>
<td colspan="2" class="table_title"><b>Public
typedef's defined by the <tt>boost::wave::context</tt> class </b></td>
typedefs defined by the <tt>boost::wave::context</tt> class </b></td>
</tr>
<tr>
<td class="table_cells"><code>iterator_type</code></td>
@@ -185,7 +185,7 @@
<blockquote>
<p>Initializes and returns the starting iterator for the
preprocessed token stream. The iterator pair given by the parameters&nbsp; <tt>[first,&nbsp;last)</tt> specifies the input sequence to preprocess. The first version of this
function uses the iinput stream as specified by the constructor.&nbsp;</p>
function uses the input stream as specified by the constructor.&nbsp;</p>
</blockquote>
<p><b><a name="iterator_interface_end" id="iterator_interface_end"></a></b><b>end</b></p>
<pre> iterator_type end() <span class="keyword">const</span>;</pre>
@@ -249,7 +249,7 @@
<pre> size_t get_iteration_depth() <span class="keyword">const</span>;</pre>
<blockquote>
<p>Returns the actual include iteration depth, i.e. the current
number of include levels to be poped from the include iteration
number of include levels to be popped from the include iteration
context, before the main (topmost) iteration context is reached.</p>
</blockquote>
<h3>Maintain defined macros</h3>
@@ -392,7 +392,7 @@
<li>If the <tt>support_option_insert_whitespace</tt> flag is set,&nbsp;the <tt>Wave</tt> library &nbsp;inserts
additional whitespace between tokens where the concatenated string
representation of the two tokens would form another valid C++ token.
This is very importatnt to avoid mis-interpretations of the generated
This is very important to avoid mis-interpretations of the generated
output if it is going to be processed by a C++ compiler afterwards.
&nbsp; </li>
<li>If the <tt>support_option_preserve_comments</tt> flag is set, the <tt>Wave</tt> library preserves almost
@@ -406,7 +406,7 @@
<li>If the <tt>support_option_convert_trigraphs</tt> flag is set, the <tt>Wave</tt> library replaces all
occurrences of trigraph characters with their non-trigraph character
sequence (i.e. <tt>'??='</tt> is replaced by <tt>'#'</tt> etc.) . By default no replacement is performed. </li>
<li>If the <tt>support_option_single_line</tt> flag is set, the <tt>Wave</tt> library will now reprot an
<li>If the <tt>support_option_single_line</tt> flag is set, the <tt>Wave</tt> library will now report an
error if the last line of the processed input is not terminated by a
new line. This flag is merely used for internal purposes by the testing
framework and will be rarely used by a user of the library.</li>
@@ -417,7 +417,7 @@
internal purposes and will be rarely reset by a user of the library. </li>
<li>If the <span class="keyword">support_option_emit_line_directives</span> flag is set, the <tt>Wave</tt> library will emit <span class="preprocessor">#line</span> directives in the
generated token stream, if appropriate. This flag is set by default, to
prevent the library from generating <span class="preprocessor">#line</span> directives it must be reset explicitely. </li>
prevent the library from generating <span class="preprocessor">#line</span> directives it must be reset explicitly. </li>
<li>If the <span class="keyword">support_option_include_guard_detection</span> flag is set, the <tt>Wave</tt> library will try to
automatically identify include guards during the processing of a
included file. Files which contained include guards are handled as if
@@ -435,12 +435,12 @@
final <span class="preprocessor">#endif</span> for
the include guard to be recognized.</p>
<p>This flag is on by default, so if you do not want the
library to automatically reconize include guards you will need to reset
this explicitely. </p>
library to automatically recognize include guards you will need to reset
this explicitly. </p>
</blockquote>
<ul>
<li>If the <tt>support_option_emit_pragma_directives</tt> flag is set, the <tt>Wave</tt> library will emit all
unknown <span class="preprocessor">#pragma</span> directives to the output. This suport option will be recognized only if
unknown <span class="preprocessor">#pragma</span> directives to the output. This support option will be recognized only if
the <tt>BOOST_WAVE_EMIT_PRAGMA_DIRECTIVES</tt> is defined
during compilation to a value not equal to zero (see <a href="compiletime_config.html">here</a> for more
information). </li>

14
doc/class_reference_ctxpolicy.html
View File

@@ -47,7 +47,7 @@
<ul>
<li>a preprocessor directive has been recognized, </li>
<li>a token is about to be returned from the preprocessor, </li>
<li>a macro get's defined or undefined, </li>
<li>a macro gets defined or undefined, </li>
<li>a macro has been expanded or rescanned,</li>
<li>an include file has been opened or closed, </li>
<li>a conditional expression was evaluated,</li>
@@ -74,7 +74,7 @@
<span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> TokenT&gt;<br> <span class="keyword">void</span> <a href="#detected_pragma_once">detected_pragma_once</a>(ContextT <span class="keyword">const</span> &amp;ctx,
TokenT <span class="keyword">const</span>&amp; pragma_token,
std::string <span class="keyword">const</span>&amp; filename);<br><br>
<span class="comment">// interpretation of #pragma's of the form </span>
<span class="comment">// interpretation of #pragmas of the form </span>
<span class="comment">// 'wave option[(value)]'</span>
<span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> <span class="keyword">bool</span> <a href="class_reference_ctxpolicy.html#interpret_pragma">interpret_pragma</a>(ContextT <span class="keyword">const</span> &amp;ctx, ContainerT &amp;pending, <br> <span class="keyword">typename</span> ContextT::token_type <span class="keyword">const</span> &amp;option, <br> ContainerT <span class="keyword">const</span> &amp;values, <br> <span class="keyword">typename</span> ContextT::token_type <span class="keyword">const</span> &amp;pragma_token);<br><br>
<span class="comment">// macro definition hooks</span>
@@ -326,7 +326,7 @@
(this is relative to the directory of the currently processed file or a
absolute path depending on the paths given as the include search paths).</p>
</blockquote>
<h3>Interpretation of #pragma's</h3>
<h3>Interpretation of #pragmas</h3>
<p><strong><a name="interpret_pragma"></a>interpret_pragma</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> bool <a href="class_reference_ctxpolicy.html#interpret_pragma">interpret_pragma</a>(ContextT <span class="keyword">const</span> &amp;ctx, ContainerT &amp;pending, <br> <span class="keyword">typename</span> ContextT::token_type <span class="keyword">const</span> &amp;option, <br> ContainerT <span class="keyword">const</span> &amp;values, <br> <span class="keyword">typename</span> ContextT::token_type<span class="keyword"> const</span> &amp;pragma_token);<br>
</pre>
@@ -378,7 +378,7 @@
<p>The parameter <tt>name</tt> holds the token of the macro which definition was removed.<br>
</p>
</blockquote>
<p><strong><a name="found_warning_directive" id="found_warning_directive"></a>found_warning_drective</strong></p>
<p><strong><a name="found_warning_directive" id="found_warning_directive"></a>found_warning_directive</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> <span class="keyword">bool</span> <a href="class_reference_ctxpolicy.html#found_warning_directive">found_warning_directive</a>(ContextT <span class="keyword">const</span>&amp; ctx, <br> ContainerT <span class="keyword">const</span> &amp;message);<br>
</pre>
<blockquote>
@@ -390,7 +390,7 @@
<p>If the return value is <tt>false</tt>, the library throws a preprocessor
exception of the type <code>warning_directive</code> (normal execution continues), if the return value is <tt>true</tt> the execution continues as if no <span class="preprocessor">#warning</span> directive has been found and the overall directive is replaced by a single newline. </p>
</blockquote>
<p><strong><a name="found_error_directive" id="found_error_directive"></a>found_error_drective</strong></p>
<p><strong><a name="found_error_directive" id="found_error_directive"></a>found_error_directive</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> <span class="keyword">bool</span> <a href="class_reference_ctxpolicy.html#found_error_directive">found_error_directive</a>(ContextT <span class="keyword">const</span>&amp; ctx, <br> ContainerT <span class="keyword">const</span> &amp;message);<br>
</pre>
<blockquote>
@@ -400,8 +400,8 @@
<p>If the return value is <tt>false</tt>, the library throws a preprocessor
exception of the type <code>error_directive</code> (normal execution continues), if the return value is <tt>true</tt> the execution continues as if no <span class="preprocessor">#error</span> directive has been found and the overall directive is replaced by a single newline. </p>
</blockquote>
<p><strong><a name="found_line_directive" id="found_line_directive"></a>found_line_drective</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> <span class="keyword">void</span> <a href="class_reference_ctxpolicy.html#found_error_directive"><strong>found_line_drective</strong></a>(ContextT <span class="keyword">const</span>&amp; ctx, <br> ContainerT <span class="keyword">const</span> &amp;arguments, <span class="keyword">unsigned int</span> line,<br> std::string <span class="keyword">const</span>&amp; filename);
<p><strong><a name="found_line_directive" id="found_line_directive"></a>found_line_directive</strong></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> ContextT, <span class="keyword">typename</span> ContainerT&gt;<br> <span class="keyword">void</span> <a href="class_reference_ctxpolicy.html#found_error_directive"><strong>found_line_directive</strong></a>(ContextT <span class="keyword">const</span>&amp; ctx, <br> ContainerT <span class="keyword">const</span> &amp;arguments, <span class="keyword">unsigned int</span> line,<br> std::string <span class="keyword">const</span>&amp; filename);
</pre>
<blockquote>
<p>The function <tt>found_line_directive </tt> is called whenever a <span class="preprocessor">#line </span>directive has been encountered. Note, this function was added for the Boost V1.35.0 release. </p>

2
doc/class_reference_inptpolcy.html
View File

@@ -99,7 +99,7 @@
which is used to access the underlying input stream has to be derived through
a typedef as shown. The iterator pair to initialize (which is accessible as
<tt>iter_ctx.first</tt> and <tt>iter_ctx.last</tt>) has to initialized from
an abritrary iterator type, representing the actual input stream.</p>
an arbitrary iterator type, representing the actual input stream.</p>
<h3><a name="member_functions"></a>Member Functions</h3>
<p><a name="init_iterators"></a><b>init_iterators</b></p>
<pre> <span class="keyword">template</span> &lt;<span class="keyword">typename</span> Position&gt;

4
doc/class_reference_lexer.html
View File

@@ -59,7 +59,7 @@
<p>Besides the typedefs mandated for a <tt>forward_iterator</tt> by the C++ standard every lexer to be used with the <tt>Wave</tt> library should define the following typedefs: </p>
<table width="90%" border="0" align="center">
<tr>
<td colspan="2" class="table_title"><b>Public typedef's defined by the <tt>boost::wave::context</tt> class </b></td>
<td colspan="2" class="table_title"><b>Public typedefs defined by the <tt>boost::wave::context</tt> class </b></td>
</tr>
<tr>
<td width="32%" class="table_cells"><code>token_type</code></td>
@@ -82,7 +82,7 @@
<p>The second constructor should construct a lexer iterator, which may be used as a iterator traversing over the token sequence, generated by the lexer class.</p>
<p>The pair of iterators <tt>first</tt> and <tt>last</tt> should represent the input stream to be tokenized by the given lexer class. </p>
<p>The parameter <tt>pos</tt> contains the initial position information to be used for token generation.</p>
<p>The parameter <tt>language</tt> controls the reuqired mode with which the lexer should be initialised. </p>
<p>The parameter <tt>language</tt> controls the required mode with which the lexer should be initialised. </p>
</blockquote>
<table border="0">
<tr>

2
doc/class_reference_tokentype.html
View File

@@ -36,7 +36,7 @@
by dereferencing the iterators exposed by the lexing component and the iterator exposed by the preprocessor component. The tokens are originally generated by the
lexer (&quot;An entity that lexically transforms the subject of parsing to a
sequence of objects (called tokens) more suitable for subsequent parsing.&quot;).
The Wave library contains two different, interchangable C++ lexers, which may
The Wave library contains two different, interchangeable C++ lexers, which may
be used as a starting point during developing your own application. The lexer
generated tokens are transformed by the preprocessing engine (macro expansion,
include file processing etc.) and after this returned to the user of the <tt>Wave</tt>

10
doc/compiletime_config.html
View File

@@ -119,7 +119,7 @@
</tr>
<tr>
<td class="table_cells"><code>BOOST_WAVE_PRAGMA_KEYWORD</code></td>
<td class="table_cells"><p>If this is defined to a string literal it will be used as the pragma keyword recogniyed by the library as specific Wave pragma's. This constant defaults to <span class="literal">&quot;wave&quot;</span>, i.e. the library recognizes all <span class="preprocessor">#pragma wave option [(argument)]</span> directives and dispatches the handling to the interpret_pragma() preprocessing hook function (see: <a href="class_reference_ctxpolicy.html">Preprocessing Hooks</a>). The arguments part of the pragma is optional.<br>
<td class="table_cells"><p>If this is defined to a string literal it will be used as the pragma keyword recogniyed by the library as specific Wave pragmas. This constant defaults to <span class="literal">&quot;wave&quot;</span>, i.e. the library recognizes all <span class="preprocessor">#pragma wave option [(argument)]</span> directives and dispatches the handling to the interpret_pragma() preprocessing hook function (see: <a href="class_reference_ctxpolicy.html">Preprocessing Hooks</a>). The arguments part of the pragma is optional.<br>
</p> </td>
</tr>
<tr>
@@ -147,7 +147,7 @@ even if these do not have the <span class="literal">'ll'</span> suffix.</p>
<p>This preprocessor constant allows to configer whether the Wave library will be built
with threading support enabled or not. This value (if defined) should be set to
zero ('0') if threading needs to be disabled and to a numerical value not equal
to zero, if threading should be enabled explicitely.
to zero, if threading should be enabled explicitly.
</p>
<p>
If this constant is not defined, the Wave library will be built using the threading
@@ -157,7 +157,7 @@ even if these do not have the <span class="literal">'ll'</span> suffix.</p>
</tr>
</table>
<P dir="ltr"><b><a name="using_custom_lexer"></a>Using a different token type or lexer type in conjunction with Wave </b></P>
<P dir="ltr">It is possible to use the <tt>Wave</tt> library while using your own token and/or lexer types. This may be achieved by providing your lexer type as the second template parameter while instantiating the <tt>boost::wave::context&lt;&gt;</tt> object. The token type used by the library is derived from the <tt>token_type</tt> typedef to be provided by the lexer type. If you want to provide your own token type only, you may use the <tt>boost::wave::lex_iterator&lt;&gt;</tt> type contained with the library. This type needs to be parametrized with the token type to use. </P>
<P dir="ltr">It is possible to use the <tt>Wave</tt> library while using your own token and/or lexer types. This may be achieved by providing your lexer type as the second template parameter while instantiating the <tt>boost::wave::context&lt;&gt;</tt> object. The token type used by the library is derived from the <tt>token_type</tt> typedef to be provided by the lexer type. If you want to provide your own token type only, you may use the <tt>boost::wave::lex_iterator&lt;&gt;</tt> type contained with the library. This type needs to be parameterized with the token type to use. </P>
<P dir="ltr">The <tt>Wave</tt> library contains several samples illustrating these possibilities. The <tt>cpp_tokens</tt> sample shows the usage of a custom lexer and a custom token types. The lexer type used is functionally fully compatible to the <tt>re2c</tt> <a href="references.html#re2c">[3]</a> based lexer used by default. It is implemented based on the <tt>SLex</tt> <a href="references.html#slex">[5]</a> lexer example written by Dan Nuffer. The token type used therein is functionally equivalent to the default token type except for an additional <tt>operator&lt;&lt;</tt> used for dumping the information carried by the token.</P>
<P dir="ltr"><b><a name="compilation_models"></a>Separation and inclusion compilation
models</b></P>
@@ -179,7 +179,7 @@ even if these do not have the <span class="literal">'ll'</span> suffix.</p>
the compilation of the C++ lexer and the separation of the compilation of the
different Spirit grammars used. To use these separations you will have to define
two preprocessor constants while compiling the whole application and you will
have to explicitely instantiate some helper templates. The following tables
have to explicitly instantiate some helper templates. The following tables
shows these constants in detail.</P>
<table width="90%" border="0" align="center">
<tr>
@@ -237,7 +237,7 @@ even if these do not have the <span class="literal">'ll'</span> suffix.</p>
included as an acompanion sample to the C++ preprocessor iterator library. The
corresponding files are named obviously <span class="string">&quot;instantiate_...something.cpp&quot;</span>,
where the <span class="string">'...somthing'</span> is a hint, which grammars
are explicitely instantiated inside. By using the separation model the compilation
are explicitly instantiated inside. By using the separation model the compilation
times required to build the <tt>Wave</tt> example are dropped by up to 90%.</p>
<table border="0">
<tr>

2
doc/preface.html
View File

@@ -139,7 +139,7 @@ implementation, for instance for testing of other preprocessor oriented
libraries as the Boost Preprocessor library <a href="references.html#pp_lib">[7]</a> et.al. Nevertheless recent work has lead to surprising performance enhancements (if compared
with earlier versions). Wave is still somewhat slower as for instance EDG
based preprocessors (Intel, Comeau) on simple input files, however, as
complexity increases, time dilates expontentially on EDG. Preprocessing time
complexity increases, time dilates exponentially on EDG. Preprocessing time
dilates linearly under Wave, which causes it to easily outperform EDG based
preprocessors when complexity increases.</p>

2
doc/quickstart.html
View File

@@ -61,7 +61,7 @@ The following code snippet is taken from the <tt>quick_start</tt> sample, which
// from the iterators.
// The template boost::wave::cpplexer::lex_iterator&lt;&gt; is
// the lexer iterator to use as the token source for the
// preprocessing engine. In this case this is parametrized
// preprocessing engine. In this case this is parameterized
// with the token type.</span>
<span class="keyword">typedef</span> <span class="identifier">boost::wave::cpplexer::lex_iterator</span><span class="special">&lt;</span>
<span class="identifier">boost::wave::cpplexer::lex_token</span><span class="special">&lt;&gt; &gt;</span>

2
doc/samples.html
View File

@@ -30,7 +30,7 @@
<h2>The lexed_tokens sample</h2>
<p>The <tt>lexed_tokens</tt> sample shows a minimal way to use the C++ lexing component of Wave without using the preprocessor. It opens the file specified as the first command line argument and prints out the contents of the tokens returned from the lexer. </p>
<h2>The <strong>cpp_tokens sample </strong></h2>
<p dir="ltr">The <tt>cpp_tokens</tt> sample dumps out the information contained within the tokens returned from the iterator supplied by the <tt>Wave</tt> library. It shows, how to use the <tt>Wave</tt> library in conjunction with custom lexer and custom token types. The lexer used within this sample is <tt>SLex</tt> <a href="references.html#slex">[5]</a> based, i.e. it <tt></tt> is feeded during runtime (at startup) with the token definitions (regular expressions) and generates a resulting DFA table. This table is used for token identification and is saved to disc afterwards to avoid the table generation process at the next program startup. The name of the file to which the DFA table is saved is <tt>wave_slex_lexer.dfa</tt>. </p>
<p dir="ltr">The <tt>cpp_tokens</tt> sample dumps out the information contained within the tokens returned from the iterator supplied by the <tt>Wave</tt> library. It shows, how to use the <tt>Wave</tt> library in conjunction with custom lexer and custom token types. The lexer used within this sample is <tt>SLex</tt> <a href="references.html#slex">[5]</a> based, i.e. it <tt></tt> is fed during runtime (at startup) with the token definitions (regular expressions) and generates a resulting DFA table. This table is used for token identification and is saved to disc afterwards to avoid the table generation process at the next program startup. The name of the file to which the DFA table is saved is <tt>wave_slex_lexer.dfa</tt>. </p>
<p dir="ltr">The main advantage of this <tt>SLex</tt> based lexer if compared to the default <tt>Re2C</tt> <a href="references.html#re2c">[3]</a> generated lexer is, that it provides not only the line information, where a particular token was recognized, but also the related column position. Otherwise the <tt>SLex</tt> based lexer is functionally fully compatible to the <tt>Re2C</tt> based one, i.e. you always may switch your application to use it, if you additionally need to get the column information back from the preprocessing. </p>
<p dir="ltr">Since no additional command line parameters are supported by this sample, it won't work well with include files, which aren't located in the same directory as the inspected input file. The command line syntax is straight forward:</p>
<pre> cpp_tokens input_file</pre>

12
doc/supported_pragmas.html
View File

@@ -42,14 +42,14 @@
<pre> #pragma wave trace(enable) </pre>
<p>and </p>
<pre> _Pragma(&quot;wave trace(enable)&quot;)</pre>
<p>All <tt>Wave</tt> specific pragma's must have the general form <tt>'wave option[(value)]'</tt>,
<p>All <tt>Wave</tt> specific pragmas must have the general form <tt>'wave option[(value)]'</tt>,
where <tt>'wave'</tt> is the specific keyword (which may be configured through the <tt>BOOST_WAVE_PRAGMA_KEYWORD</tt> compile time constant, see <a href="compiletime_config.html">here</a> for more information), <tt>'option'</tt> is the concrete
pragma functionality to trigger and <tt>'value'</tt> is an optional value to
be supplied to the <tt>'option'</tt> functionality. The following table lists
all possible pragma functions supported by the <tt>Wave</tt> library. For all recognised pragmas of this general form the interpret_pragma hook function from inside the <a href="class_reference_ctxpolicy.html">preprocessing_hooks</a> policy are called, so that the user of the library is responsible for the correct interpretation of these pragma's. </p>
all possible pragma functions supported by the <tt>Wave</tt> library. For all recognised pragmas of this general form the interpret_pragma hook function from inside the <a href="class_reference_ctxpolicy.html">preprocessing_hooks</a> policy are called, so that the user of the library is responsible for the correct interpretation of these pragmas. </p>
<table width="77%" border="0" align="center">
<tr>
<td colspan="3"> <p class="table_title">Supported pragma's</p></td>
<td colspan="3"> <p class="table_title">Supported pragmas</p></td>
</tr>
<tr>
<td> <p class="toc_title" width="36%">pragma option</p></td>
@@ -110,8 +110,8 @@
<p>The pragma values <tt>push</tt> and <tt>pop</tt> may be used for all of the options (<tt>line</tt>, <tt>preserve</tt> and <tt>output</tt>) to store and restore the current value of the corresponding option. </p></td>
</tr>
</table>
<p>All pragma's not listed here but flagged as <tt>'wave'</tt> are currently reported as
errors. The handling of all remaining pragma's depends on the compilation constant
<p>All pragmas not listed here but flagged as <tt>'wave'</tt> are currently reported as
errors. The handling of all remaining pragmas depends on the compilation constant
<code><tt>BOOST_WAVE_RETURN_PRAGMA_DIRECTIVES</tt></code>, which allows to specify,
if those pragmas are left unchanged in the output stream or not. Please note,
that the operator _Pragma variant is always subject to full preprocessing, before
@@ -119,7 +119,7 @@
only, if the <code><tt>BOOST_WAVE_PREPROCESS_PRAGMA_BODY</tt></code> compilation constant
was specified during compilation. For more information about the possible compilation
constants look <a href="compiletime_config.html">here</a>.</p>
<p>It is fairly easy to implement your own <span class="preprocessor">#pragma&nbsp;wave&nbsp;...</span> directives. All you have to do is to implement your own <tt>interpret_pragma</tt> preprocessing hook function (see <a href="class_reference_ctxpolicy.html#interpret_pragma">here</a>) which should handle the additional directives. For an example of how to do it, you may have a look at the Wave driver application, which implements all of the pragma's listed above with the help of a supplied <tt>interpret_pragma</tt> function (for instance the <span class="preprocessor">#pragma wave timer()</span> directive). </p>
<p>It is fairly easy to implement your own <span class="preprocessor">#pragma&nbsp;wave&nbsp;...</span> directives. All you have to do is to implement your own <tt>interpret_pragma</tt> preprocessing hook function (see <a href="class_reference_ctxpolicy.html#interpret_pragma">here</a>) which should handle the additional directives. For an example of how to do it, you may have a look at the Wave driver application, which implements all of the pragmas listed above with the help of a supplied <tt>interpret_pragma</tt> function (for instance the <span class="preprocessor">#pragma wave timer()</span> directive). </p>
<table border="0">
<tr>
<td width="10"></td>

4
doc/tracing_facility.html
View File

@@ -29,7 +29,7 @@
the <i>Wave</i> library has a tracing facility, which allows to get selectively
some information about the expansion of a certain macro or several macros. </p>
<p>The tracing of macro expansions generates a possibly huge amount of information,
so it is recommended, that you explicitely enable/disable the tracing for the
so it is recommended, that you explicitly enable/disable the tracing for the
macro in question only. This may be done with the help of a special, <tt>Wave</tt>
specific #pragma:</p>
<pre><span class="preprocessor"> #pragma</span> wave trace(enable) <span class="comment">// enable the tracing</span>
@@ -120,7 +120,7 @@
the corresponding formal and actual parameters are listed.</li>
<li>The expansion of the given arguments (if any and if these are defined as
macros). This repeats the full tracing information for the argument macro
expansion, only indended by one level. Note though, that the macro expansion
expansion, only indented by one level. Note though, that the macro expansion
of the actual arguments is traced, regardless of the fact, whether this argument
is really to be inserted into the replacement list after its expansion
or as it was initially supplied (see C++ Standard [16.3.1.1]: &quot;A parameter