The function returning_from_include_file is called whenever an included file is about to be closed after it's processing is complete.
-template <typename ContextT, typename ContainerT> bool interpret_pragma(ContextT const &ctx, ContainerT &pending, diff --git a/doc/class_reference_context.html b/doc/class_reference_context.html index 2190560..28d6e1b 100644 --- a/doc/class_reference_context.html +++ b/doc/class_reference_context.html @@ -118,7 +118,7 @@Public - typedef's defined by the boost::wave::context class + typedefs defined by the boost::wave::context class@@ -185,7 +185,7 @@ iterator_typeInitializes and returns the starting iterator for the preprocessed token stream. The iterator pair given by the parameters [first, last) specifies the input sequence to preprocess. The first version of this - function uses the iinput stream as specified by the constructor.
+ function uses the input stream as specified by the constructor.iterator_type end() const;@@ -249,7 +249,7 @@size_t get_iteration_depth() const;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.
Maintain defined macros
@@ -392,7 +392,7 @@If the support_option_insert_whitespace flag is set, the Wave library 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. If the support_option_preserve_comments flag is set, the Wave library preserves almost @@ -406,7 +406,7 @@ If the support_option_convert_trigraphs flag is set, the Wave library replaces all occurrences of trigraph characters with their non-trigraph character sequence (i.e. '??=' is replaced by '#' etc.) . By default no replacement is performed. -If the support_option_single_line flag is set, the Wave library will now reprot an + If the support_option_single_line flag is set, the Wave 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. @@ -417,7 +417,7 @@ internal purposes and will be rarely reset by a user of the library.If the support_option_emit_line_directives flag is set, the Wave library will emit #line directives in the generated token stream, if appropriate. This flag is set by default, to - prevent the library from generating #line directives it must be reset explicitely. + prevent the library from generating #line directives it must be reset explicitly.If the support_option_include_guard_detection flag is set, the Wave 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 #endif for the include guard to be recognized. 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.
+ library to automatically recognize include guards you will need to reset + this explicitly.
- If the support_option_emit_pragma_directives flag is set, the Wave library will emit all - unknown #pragma directives to the output. This suport option will be recognized only if + unknown #pragma directives to the output. This support option will be recognized only if the BOOST_WAVE_EMIT_PRAGMA_DIRECTIVES is defined during compilation to a value not equal to zero (see here for more information).
diff --git a/doc/class_reference_ctxpolicy.html b/doc/class_reference_ctxpolicy.html index 76346d3..a07005f 100644 --- a/doc/class_reference_ctxpolicy.html +++ b/doc/class_reference_ctxpolicy.html @@ -47,7 +47,7 @@
- a preprocessor directive has been recognized,
- a token is about to be returned from the preprocessor,
-- a macro get's defined or undefined,
+- a macro gets defined or undefined,
- a macro has been expanded or rescanned,
- an include file has been opened or closed,
- a conditional expression was evaluated,
@@ -74,7 +74,7 @@ template <typename ContextT, typename TokenT>
void detected_pragma_once(ContextT const &ctx, TokenT const& pragma_token, std::string const& filename);
- // interpretation of #pragma's of the form + // interpretation of #pragmas of the form // 'wave option[(value)]' template <typename ContextT, typename ContainerT>
bool interpret_pragma(ContextT const &ctx, ContainerT &pending,
typename ContextT::token_type const &option,
ContainerT const &values,
typename ContextT::token_type const &pragma_token);
// macro definition hooks @@ -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). -Interpretation of #pragma's
+Interpretation of #pragmas
template <typename ContextT, typename ContextT, typename ContainerT>@@ -378,7 +378,7 @@
bool interpret_pragma(ContextT const &ctx, ContainerT &pending,
typename ContextT::token_type const &option,
ContainerT const &values,
typename ContextT::token_type const &pragma_token);
The parameter name holds the token of the macro which definition was removed.
- +
template <typename ContextT, typename ContainerT>
bool found_warning_directive(ContextT const& ctx,
ContainerT const &message);
@@ -390,7 +390,7 @@- +If the return value is false, the library throws a preprocessor exception of the type
warning_directive(normal execution continues), if the return value is true the execution continues as if no #warning directive has been found and the overall directive is replaced by a single newline.template <typename ContextT, typename ContainerT>
bool found_error_directive(ContextT const& ctx,
ContainerT const &message);
@@ -400,8 +400,8 @@- -If the return value is false, the library throws a preprocessor exception of the type
error_directive(normal execution continues), if the return value is true the execution continues as if no #error directive has been found and the overall directive is replaced by a single newline.template <typename ContextT, typename ContainerT>
void found_line_drective(ContextT const& ctx,
ContainerT const &arguments, unsigned int line,
std::string const& filename); + +template <typename ContextT, typename ContainerT>
void found_line_directive(ContextT const& ctx,
ContainerT const &arguments, unsigned int line,
std::string const& filename);The function found_line_directive is called whenever a #line directive has been encountered. Note, this function was added for the Boost V1.35.0 release.
diff --git a/doc/class_reference_inptpolcy.html b/doc/class_reference_inptpolcy.html index 7722828..df98b62 100644 --- a/doc/class_reference_inptpolcy.html +++ b/doc/class_reference_inptpolcy.html @@ -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 iter_ctx.first and iter_ctx.last) has to initialized from - an abritrary iterator type, representing the actual input stream. + an arbitrary iterator type, representing the actual input stream.Member Functions
template <typename Position> diff --git a/doc/class_reference_lexer.html b/doc/class_reference_lexer.html index 19437ed..16e29f1 100644 --- a/doc/class_reference_lexer.html +++ b/doc/class_reference_lexer.html @@ -59,7 +59,7 @@Besides the typedefs mandated for a forward_iterator by the C++ standard every lexer to be used with the Wave library should define the following typedefs:
- Public typedef's defined by the boost::wave::context class +Public typedefs defined by the boost::wave::context class @@ -82,7 +82,7 @@ token_typeThe second constructor should construct a lexer iterator, which may be used as a iterator traversing over the token sequence, generated by the lexer class.
The pair of iterators first and last should represent the input stream to be tokenized by the given lexer class.
The parameter pos contains the initial position information to be used for token generation.
-The parameter language controls the reuqired mode with which the lexer should be initialised.
+The parameter language controls the required mode with which the lexer should be initialised.
diff --git a/doc/class_reference_tokentype.html b/doc/class_reference_tokentype.html index eb50696..4f604f4 100644 --- a/doc/class_reference_tokentype.html +++ b/doc/class_reference_tokentype.html @@ -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 ("An entity that lexically transforms the subject of parsing to a sequence of objects (called tokens) more suitable for subsequent parsing."). - 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 Wave diff --git a/doc/compiletime_config.html b/doc/compiletime_config.html index 74cf7db..6165326 100644 --- a/doc/compiletime_config.html +++ b/doc/compiletime_config.html @@ -119,7 +119,7 @@ - BOOST_WAVE_PRAGMA_KEYWORDIf 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 "wave", i.e. the library recognizes all #pragma wave option [(argument)] directives and dispatches the handling to the interpret_pragma() preprocessing hook function (see: Preprocessing Hooks). The arguments part of the pragma is optional.
+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 "wave", i.e. the library recognizes all #pragma wave option [(argument)] directives and dispatches the handling to the interpret_pragma() preprocessing hook function (see: Preprocessing Hooks). The arguments part of the pragma is optional.
@@ -147,7 +147,7 @@ even if these do not have the 'll' suffix. 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.
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 'll' suffix.
Using a different token type or lexer type in conjunction with Wave
-It is possible to use the Wave 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 boost::wave::context<> object. The token type used by the library is derived from the token_type typedef to be provided by the lexer type. If you want to provide your own token type only, you may use the boost::wave::lex_iterator<> type contained with the library. This type needs to be parametrized with the token type to use.
+It is possible to use the Wave 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 boost::wave::context<> object. The token type used by the library is derived from the token_type typedef to be provided by the lexer type. If you want to provide your own token type only, you may use the boost::wave::lex_iterator<> type contained with the library. This type needs to be parameterized with the token type to use.
The Wave library contains several samples illustrating these possibilities. The cpp_tokens sample shows the usage of a custom lexer and a custom token types. The lexer type used is functionally fully compatible to the re2c [3] based lexer used by default. It is implemented based on the SLex [5] lexer example written by Dan Nuffer. The token type used therein is functionally equivalent to the default token type except for an additional operator<< used for dumping the information carried by the token.
Separation and inclusion compilation models
@@ -179,7 +179,7 @@ even if these do not have the 'll' suffix. 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.
@@ -237,7 +237,7 @@ even if these do not have the 'll' suffix. included as an acompanion sample to the C++ preprocessor iterator library. The corresponding files are named obviously "instantiate_...something.cpp", where the '...somthing' 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 Wave example are dropped by up to 90%.
diff --git a/doc/preface.html b/doc/preface.html index a6bfe95..170950f 100644 --- a/doc/preface.html +++ b/doc/preface.html @@ -139,7 +139,7 @@ implementation, for instance for testing of other preprocessor oriented libraries as the Boost Preprocessor library [7] 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. diff --git a/doc/quickstart.html b/doc/quickstart.html index 3bcd4dc..fe4b936 100644 --- a/doc/quickstart.html +++ b/doc/quickstart.html @@ -61,7 +61,7 @@ The following code snippet is taken from the quick_start sample, which // from the iterators. // The template boost::wave::cpplexer::lex_iterator<> 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. typedef boost::wave::cpplexer::lex_iterator< boost::wave::cpplexer::lex_token<> > diff --git a/doc/samples.html b/doc/samples.html index 380f568..3f7d65a 100644 --- a/doc/samples.html +++ b/doc/samples.html @@ -30,7 +30,7 @@ The lexed_tokens sample
The lexed_tokens 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.
The cpp_tokens sample
-The cpp_tokens sample dumps out the information contained within the tokens returned from the iterator supplied by the Wave library. It shows, how to use the Wave library in conjunction with custom lexer and custom token types. The lexer used within this sample is SLex [5] based, i.e. it 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 wave_slex_lexer.dfa.
+The cpp_tokens sample dumps out the information contained within the tokens returned from the iterator supplied by the Wave library. It shows, how to use the Wave library in conjunction with custom lexer and custom token types. The lexer used within this sample is SLex [5] based, i.e. it 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 wave_slex_lexer.dfa.
The main advantage of this SLex based lexer if compared to the default Re2C [3] 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 SLex based lexer is functionally fully compatible to the Re2C 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.
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:
cpp_tokens input_filediff --git a/doc/supported_pragmas.html b/doc/supported_pragmas.html index ce44faa..e6aff1b 100644 --- a/doc/supported_pragmas.html +++ b/doc/supported_pragmas.html @@ -42,14 +42,14 @@#pragma wave trace(enable)and
_Pragma("wave trace(enable)")-All Wave specific pragma's must have the general form 'wave option[(value)]', +
All Wave specific pragmas must have the general form 'wave option[(value)]', where 'wave' is the specific keyword (which may be configured through the BOOST_WAVE_PRAGMA_KEYWORD compile time constant, see here for more information), 'option' is the concrete pragma functionality to trigger and 'value' is an optional value to be supplied to the 'option' functionality. The following table lists - all possible pragma functions supported by the Wave library. For all recognised pragmas of this general form the interpret_pragma hook function from inside the preprocessing_hooks policy are called, so that the user of the library is responsible for the correct interpretation of these pragma's.
+ all possible pragma functions supported by the Wave library. For all recognised pragmas of this general form the interpret_pragma hook function from inside the preprocessing_hooks policy are called, so that the user of the library is responsible for the correct interpretation of these pragmas.-
- + Supported pragma's
Supported pragmas
@@ -110,8 +110,8 @@ pragma option
The pragma values push and pop may be used for all of the options (line, preserve and output) to store and restore the current value of the corresponding option.
All pragma's not listed here but flagged as 'wave' are currently reported as - errors. The handling of all remaining pragma's depends on the compilation constant +
All pragmas not listed here but flagged as 'wave' are currently reported as + errors. The handling of all remaining pragmas depends on the compilation constant
-BOOST_WAVE_RETURN_PRAGMA_DIRECTIVES, 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 theBOOST_WAVE_PREPROCESS_PRAGMA_BODYcompilation constant was specified during compilation. For more information about the possible compilation constants look here.It is fairly easy to implement your own #pragma wave ... directives. All you have to do is to implement your own interpret_pragma preprocessing hook function (see here) 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 interpret_pragma function (for instance the #pragma wave timer() directive).
+It is fairly easy to implement your own #pragma wave ... directives. All you have to do is to implement your own interpret_pragma preprocessing hook function (see here) 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 interpret_pragma function (for instance the #pragma wave timer() directive).
diff --git a/doc/tracing_facility.html b/doc/tracing_facility.html index c6dbbbe..cdcb6b9 100644 --- a/doc/tracing_facility.html +++ b/doc/tracing_facility.html @@ -29,7 +29,7 @@ the Wave library has a tracing facility, which allows to get selectively some information about the expansion of a certain macro or several macros. 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, Wave specific #pragma:
#pragma wave trace(enable) // enable the tracing @@ -120,7 +120,7 @@ the corresponding formal and actual parameters are listed.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]: "A parameter