From 4e6c4fbd2e942267b2bcd1053d768fe802f597e1 Mon Sep 17 00:00:00 2001 From: Jeff Trull Date: Wed, 17 Jun 2020 22:36:46 -0700 Subject: [PATCH] Correct various minor typos (#99) --- doc/class_ref_ctxpolicy_depr.html | 4 ++-- doc/class_reference_context.html | 18 +++++++++--------- doc/class_reference_ctxpolicy.html | 14 +++++++------- doc/class_reference_inptpolcy.html | 2 +- doc/class_reference_lexer.html | 4 ++-- doc/class_reference_tokentype.html | 2 +- doc/compiletime_config.html | 10 +++++----- doc/preface.html | 2 +- doc/quickstart.html | 2 +- doc/samples.html | 2 +- doc/supported_pragmas.html | 12 ++++++------ doc/tracing_facility.html | 4 ++-- 12 files changed, 38 insertions(+), 38 deletions(-) diff --git a/doc/class_ref_ctxpolicy_depr.html b/doc/class_ref_ctxpolicy_depr.html index 0c9a5ac..e8df187 100644 --- a/doc/class_ref_ctxpolicy_depr.html +++ b/doc/class_ref_ctxpolicy_depr.html @@ -92,7 +92,7 @@ Time Configuration section. By default the new interface is used starting Bo void returning_from_include_file(); - // 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, @@ -264,7 +264,7 @@ Time Configuration section. By default the new interface is used starting Bo

The function returning_from_include_file is called whenever an included file is about to be closed after it's processing is complete.

-

Interpretation of #pragma's

+

Interpretation of #pragmas

interpret_pragma

    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 
     
     
       iterator_type
@@ -185,7 +185,7 @@
 

   
Initializes 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. 

 

 
end

 
    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
        
 
        interpret_pragma
        
 
            template <typename ContextT, 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);
        
 
        
@@ -378,7 +378,7 @@
   
        The parameter name holds the token of the macro which definition was removed.
        
   
        
 
-
        found_warning_drective
        
+
        found_warning_directive
        
 
            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. 
        
 
        
-
        found_error_drective
        
+
        found_error_directive
        
 
            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. 
        
 
        
-
        found_line_drective
        
-
            template <typename ContextT, typename ContainerT>
            void found_line_drective(ContextT const& ctx, 
                ContainerT const &arguments, unsigned int line,
                std::string const& filename);
+
        found_line_directive
        
+
            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
        
 
        init_iterators
        
 
            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: 
        
 
-    
+    
@@ -82,7 +82,7 @@
   
        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.
        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. 
        
   
        Public typedef's defined by the boost::wave::context class Public typedefs defined by the boost::wave::context class 
   
        
   
        
     token_type
   
   
 
 
         
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 @@
   
-    
@@ -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.
        
   
        
   
        
     BOOST_WAVE_PRAGMA_KEYWORD
        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 "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.
        
       
                    		
   
        
   
        
             
             
     
        
 
        
 
        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.typedefboost::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_file
        
diff --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. 
        
   
        
      
             
  
  
 
 
 
 
 
 
         
-    
+    
@@ -110,8 +110,8 @@
     
        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. 
        
   
         
        Supported pragma's
        		 
        Supported pragmas
        		
   
        
   
         
      
        pragma 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 the BOOST_WAVE_PREPROCESS_PRAGMA_BODY compilation 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 

        •