diff --git a/ChangeLog b/ChangeLog
deleted file mode 100644
index 573f513..0000000
--- a/ChangeLog
+++ /dev/null
@@ -1,1314 +0,0 @@
-Boost.Wave: A Standard compliant C++ preprocessor library
-http://www.boost.org/
-
-Copyright (c) 2001-2005 Hartmut Kaiser. Distributed under the Boost
-Software License, Version 1.0. (See accompanying file
-LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
--------------------------------------------------------------------------------
-
-TODO (known issues):
-- Fix expansion of macros, which replacement-list terminates in a partial
- macro expansion.
-- Fix the re2c lexer for iterators others then string::iterator (or more
- generally for iterators, which aren't random access iterators)
-- Try to remove the second parameter from the pp_iterator<>::force_include
- function.
-- Fix the trigraph backslash problem in the re2c (C/C++ and IDL) scanners, if
- there is the end of the (internal) buffer just in between a '??/' and a '\n'.
-
-- Do a sourceforge release.
-
--------------------------------------------------------------------------------
-
-CHANGELOG
-
-Boost V1.33.1
-- Version 1.2.1
-- Fixed bug reported as Sourceforge bug 1274584.
-- Switched to Re2C V0.9.9.
-- Fixed a bug where the 'parameters' and 'definition' parameters to the
- defined_macro callback of the preprocessing hooks were always empty (thanks
- to Stefan Seefeld for reporting).
-- Fixed missing namespace specifiers in token definition macros (thanks to
- Jozsef Mihalicza for reporting).
-- Enabled --preserved and --long_long modes by default for the cpp_tokens
- sample.
-- Newline tokens reported a wrong line number (offset by one) when using the
- Re2C generated lexer (thanks to Jozsef Mihalicza for pointing this out).
-- Changed file positions to carry 'unsigned int' line and column numbers.
-- Fixed tokens of a generated #line directive to carry the correct column
- numbers.
-- Tokens now contain the correct filename, line and column numbers even if
- a #line directive was encountered.
-- Fixed wrong line numbering in reference comments of the tests t_5_002.cpp and
- t_5_035.cpp.
-
-Boost V1.33.0
-Version 1.2
-- Fixed name clash wrt T_DIVIDE on FreeBSD.
-- Fixed documentation of the different language_support flags.
-- The support for long long suffixes is no longer bound to the variadics mode,
- it has to be enabled by the new long_long mode (default in C99).
-- Fixed compilation if BOOST_WAVE_DUMP_PARSE_TREE is defined.
-- Fixed lexer error message wrt long_long mode.
-- Stefan Seefeld fixed a bug in the lexer, where include_next was assumed for
- includeed files containg a "include_" in their name.
-- Fixed some trigraph token id's in the lexers.
-- Added column information to the re2c generated lexer.
-- Added tests for the different lexers.
-- Fixed the found_include_directive preprocessing hook to carry the information
- about #include_next directives as well.
-- Separated the different lexer tests.
-- Fixed a bug in the whitespace eater.
-- Fixed a bug where Wave emitted the found C++ comments in --preserve mode even
- if these were found inside of disabled #if/#endif blocks.
-- Removed the function local static grammars to avoid possible raise conditions
- and to make CW8.3 happy.
-- Unified lexer interface, adjusted namespaces.
-- Added lexer testcases to the regression tests.
-- Fixed test cases to scale to 64 bit platforms.
-- Disabled the MS specific extensions in the lexer tests in a platform related
- way.
-- Added special handling of the eof tokens inside the lexer iterator classes
- for Comeau.
-- Applied a workaround proposed by David Abrahams to make the slex lexer work
- on the CodeWarrior platforms.
-
-Sun May 8 17:22:59 WEDT 2005
-Version 1.1.17
-- Added ill_formed_character_literal and ill_formed_integer_literal errors.
-- Improved error handling and diagnostics for integer overflow in #if/#elif
- expressions.
-- Fixed a bug in the testwave application which prevented the correct
- recognition of expected errors under certain circumstances.
-- Fixed a portability problem (for gcc 3.3.x) in the testwave application.
-- Enforced that #if/#endif are balanced file wise.
-- Changed the command line arguments for the Wave testrun to use absolute
- directories.
-- Changed the test application to return a value != zero if one of the given
- config files were not found.
-- Fixed a command line parsing problem caused by a change in the parameter
- handling inside in the program_options library.
-- Switched to the most recent version of re2c (V0.9.7.dev).
-- Fixed a como compilation error and several como --a warnings.
-- The T_EOF token doesn't carry the value of the previous token anymore.
-- Added operator==() to the token classes to fix the ambiguity error reported
- by the True64 compiler.
-- Improved the error message, when empty arguments are used in pure C++ mode.
-- Added character literal out of range testing and an additional corresponding
- error message.
-- Fixed parsing of long character literals (such as '\x1234').
-- Fixed almost all problems diagnosed by the Boost inspection report.
-- Several fixes to make the True64 compiler happy.
-- Added the long long suffix handling to the C99 mode (LL/ll).
-- Fixed a bug in the slex regex specifications.
-
-Thu Apr 7 10:07:45 WEDT 2005
-Version 1.1.16
-- Fixed a bug in the white space eating component, which prevented a C++
- comment to be suppressed if it followed after another whitespace.
-- Fixed the inconsistencies between the documentation and the behaviour wrt the
- different include search paths. See the Wave driver docs for details of how
- the '-I', '-I-', and '-S' options work.
-- Allowed to specify more than one config file ('@' syntax) on the command line
- of the wave driver executable.
-- Changed copyrights in all files to reflect the acceptance of Wave into Boost.
-- Unknown preprocessing directives were not recognised as such anymore.
-- If comments shouldn't be preserved all C++ comments are replaced by newline
- tokens (instead of beeing igored completely).
-- Fixed a bug in the white space eater component.
-- Fixed a bug which reported wrong line numbers for error encountered during
- retokenisation (concatination).
-- Fixed a bug in the unescaping code.
-- Fixed a compilation error of the testwave executable (added a missing
- namespace specifier).
-- Added a missing header to make cpp.re.cpp compile on CW.
-- The predefined macro __BASE_FILE__ now returns a properly escaped file name
- string.
-- Fixed the function boost::wave::util::impl::unescape_lit().
-- Added the Wave unit test framework. For now it contains about 60 unit tests
- executed by a special test driver (testwave).
-- Added the '$F' replacement string to the testwave application. This allows
- to handle file paths sensitive comparison of the expected and real results.
-- Fixed a minor problem in the whitespace eating component.
-- Added optional trigraph conversion.
-- Changed all size_t, time_t etc. to std::size_t, std::time_t etc (for CW).
-- If the comments should not be preserved every C comment containing at minimum
- one newline is now converted to a newline token.
-- Added the lexed_tokens sample.
-- Fixed warnings and errors reported by the CodeWarrior compiler.
-- Added the '$V' replacement string to the testwave application. It expands to
- the current BOOST_LIB_VERSION.
-- Diagnosed the attempt to redefine the alternative operators as and, or etc.
-- Improved error handling.
-- Disabled the flex_string class for VC7, enabled to fallback to std::string
- for this compiler.
-- Renamed files to comply with the Boost rules.
-- Added the first part of the MCPP validation suite to the Wave unit tests.
-- Added even more missing "using namespace std;" staements for functions from
- the C runtime library. The Wave test suite now contains more than 100 unit
- tests.
-- Added the $P/$P(basename) replacement string to the testwave application
- which expands to the full path of the current file ($P) or to the current
- directory/basename ($P(basename)).
-- Fixed a bunch of portability problmes revealed by the regression tests on
- different platforms. Thanks to Stefan Slapeda for his support to make it work
- on the cw-9_4 toolset (win32).
-
-Tue Mar 22 14:52:45 WEST 2005
-Version 1.1.15
-- Fixed a bug where the complete set of C99 predefined macros were pre-defined
- when in C++ mode and variadics were enabled.
-- When in variadics or C99 mode the __BASE_FILE__ predefined macro expanded to
- .
-- Added the --listincludes option to the Wave driver executable which allows to
- log the file names of the include files opened.
-- Fixed a gcc warning in token_cache.hpp (unused variable end).
-- Changed the logic behind #include_next. It now starts searching with the
- next directory after the directory the current file (the file containing the
- #include_next directive) is located in.
-- Changed the signature of the undefined_macro preprocessing hook to take the
- token itself and not the macro name only. This is important to pass the full
- context information about the position of the #undef directive to the
- user provided hook (thanks to Stefan Seefeld for pointing that out).
-- Fixed several broken links in the Context Policy topic.
-- Fixed a bug in the handling of the #include_next directive inside of
- non-evaluated #if blocks.
-- Fixed a bug in the #include_next handling code (thanks to Stefan Seefeld).
-- Changed the signature of the opened_include_file() preprocessing hook which
- now receives not only the absolute file name of the openend include file but
- additionally gets passed the (possibly) relative path of the openend include
- file. This concrete format of the relative path depends on the format of the
- include search directory given to the library.
-- Added a new preprocessing hook 'found_include_directive()' which gets called
- for every #include directive (even for those where the file to include
- doesn't exist) and which gets passed the (expanded) token sequence found
- after the #include directive token.
-- The file names passed to the preprocessing hooks are now normalised.
-- Changed the opened_include_file() preprocessing hook to receive the correct
- relative path even if the included file was found in the current directory.
-- Fixed a bug which reported 'defined(or)' as invalid (similarly all the other
- alternative bit operation token types).
-- Fixed a bug which prevented to define variadic macros from the command line.
-- Added a 'preserve comments' mode to preserve the comments in the input stream
- not inserted into macro definitions.
-- Added a new --preserve (-p) command line switch to the wave driver
- application to allow comments to be preserved in the generated output stream.
-
-Mon Feb 21 09:30:04 WEST 2005
-Version 1.1.14 (Fixes in response to the Boost review)
-
-Wave was accepted into Boost!
-
-With special thanks to Tom Brinkman, who volunteered to be the review manager.
-
-With thanks to David Abrahams, Beman Dewes, Reece Dunn, Larry Evans,
-Doug Gregor, Joel de Guzman, Baptiste Lepilleur, Andy Little, Paul Mensonides,
-Dan Nuffer, Andreas Pokorny, Vladimir Prus, Gennadiy Rozental, Michiel Salters,
-Jonathan Turkanis, Chris Uzdavinis, Pavel Vozenilek, Michael Walter for bug
-reports, fixes and hints.
-
-- Added support for the MS extensions #region and #endregion, which simply get
- ignored by Wave. The support for these is enabled only, when the pp constant
- BOOST_WAVE_SUPPORT_MS_EXTENSIONS is defined. Otherwise these get flagged as
- an illegal preprocessor directive (as before).
-- Fixed a problem, where the replacement text for a #pragma directive got lost
- if this directive was on the last line of a processed (include-)file.
-- Changed the default value for BOOST_WAVE_SUPPORT_MS_EXTENSIONS for non-
- Windows systems to zero.
-- Updated outdated external links in the documentation.
-- Fixed certain grammatical and stylistic quirks in the documentation.
-- Fixed a problem in libs/wave/build/Jamfile.v2 (as reported by Larry Evans).
- Fixed the Jamfile.v2 in the samples directories accordingly.
-- Added the 'vc-7_1:off' to all Jamfile.v2 files to adjust for
- the internal buffer overflow bug in the VC7.1 compiler (reported by Joel de
- Guzman).
-- Changed the 'vc-7_1:off' to 'vc-7.1:off' as
- required by the Boost.Build.v2 library (suggested by Vladimir Prus).
-- Finally fixed the Jamfile.v2 file (after a suggestion from Reece Dunn)
-- Fixed the column number reported for tokens for Slex lexer based
- configurations (reported by Baptiste Lepilleur).
-- Added the __BASE_FILE__ predefined macro, which contains a string literal
- of the main file name to preprocess (the one the context<> template was
- created with). (suggested by Pavel Vozenilek)
-- Used the boost::reverse_iterator instead of the std::reverse_iterator
- for the flex_string class to allow compilation of Wave with VC7.0
- (as suggested by Reece Dunn).
-- Fixed a problem in the include_path template, which throwed a
- boost::filesystem exception whenever a character was used in a file name
- to include, which is marked as illegal by the default name checker of the
- boost::filesystem::path.
-
-Version 1.1.13 (Boost review candidate 2, bug fixed version)
-- Fixed a problem, where the context<> template referenced temporary iterator
- objects from the underlying stream (thanks to Michiel Salters for reporting
- this).
-- Fixed a bug in the re2c lexer, which allowed to dereference the end iterator
- of the underlying input stream (thanks to Doug Gregor for pointing this out).
-- Fixed several assertions fired by the iterator checking code of the VC8 stl.
-
-Version 1.1.12 (Boost review candidate)
-- A rough performance analysis showed, that 30% of the time is spent parsing
- the input for pp directives (cpp_grammar), 35% of the time is spent inside
- the flex_string code, mainly in the copy constructor and assignment
- operator, 15% of the time is spent inside the list and vector member
- functions, 10% is spent for memory allocation but only 1% of the time is
- spent in the re2c lexer.
-- Identified a performance problem, where the token_cache was instantiated
- for every created lexer object, but needed to be initialised only once.
-- Added #include to wave_config.hpp
-- Fixed problems reported by the gcc 3.4.1 compiler.
-- Adjusted Jamfiles for the new toolset names introduced in Boost V1.32.
-
-Version 1.1.11
-- Updated copyrights.
-- Fixed some bugs introduced by the latest refactoring.
-- Tried to fix the expansion of macros, which replacement-list terminates in a
- partial macro expansion. No success so far.
-
-Version 1.1.10
-- Refactored some of the macro map (macro namespace) code (added comments,
- splitted into separate files),
-- Fixed some typename errors in cpp_macromap.hpp (thanks to Vladimir Prus).
-- Fixed the BoostBuild V2 Jamfiles (thanks to Vladimir Prus).
-
-Version 1.1.9
-- Moved all of the #pragma wave option(value) operators out of the wavelib into
- the wave driver program. Removed enable_trace() and trace_flags() policy
- functions. Renamed trace_policy into context_policy.
-- Added the defined_macro() and undefined_macro() preprocessing hooks to allow
- easily to build macro cross referencers and such.
-
-Version 1.1.8
-- Replaced the usage of the string::erase() and string::insert() functions,
- which were the only non-const string member functions used.
-- Token pasting is now well defined in variadics mode (was in C++0x mode only).
-- Changed the timing code in the wave driver to include the parsing of
- files included by the --forceinclude command line switch.
-- Performance measurements (very informal) [sec], the files are some of the
- preprocessor specific test cases from Paul Mensonides chaos_pp library.
-
- std::string flex_string const_string const_string
- 12 Byte 28 Byte
- arithmetic.cpp 2.543 1.742 0.951 1.001
- array.cpp 2.453 1.762 0.951 1.011
- comparison.cpp 0.560 0.340 0.270 0.280
- control.cpp 0.590 0.340 0.290 0.300
- debug.cpp 0.370 0.310 0.190 0.190
- detection.cpp 0.050 0.060 0.030 0.030
- extended.cpp 0.370 0.260 0.190 0.190
- facilities.cpp 0.610 0.340 0.290 0.300
- iteration.cpp 1.081 0.550 0.410 0.450
- list.cpp 1.742 1.141 0.811 0.851
- logical.cpp 0.070 0.200 0.040 0.040
- punctuation.cpp 0.030 0.080 0.020 0.020
- repetition.cpp 1.392 0.851 0.650 0.690
- selection.cpp 0.440 0.270 0.210 0.220
- slot.cpp 0.680 0.350 0.240 0.270
- tuple.cpp 0.420 0.240 0.190 0.210
-
-
-Wed Aug 25 13:23:27 WEDT 2004
-Version 1.1.7
-- Branched for Boost Release.
-- Removed several features from the code base:
- . removed C++0x support
- . removed TST support
-- Fixed the program_option validator syntax, which has changed since the last
- update.
-- Removed misleading configuration options from the cpp_config.hpp file,
- because the application will have to use the same config options as were used
- during the compilation of the library.
-- Changed the naming convention of typedef'd types in the library. Removed the
- _t suffix, wherever possible.
-- Updated the documentation to reflect the removal of the C++0x features.
-
-- Changed the licensing scheme to:
-// Copyright 2004 Joe Coder. Distributed under the Boost
-// Software License, Version 1.0. (See accompanying file
-// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
-
-Mon May 24 10:02:47 WEDT 2004
-Version 1.1.6
-- Fixed a incompatibility with the new program_options version.
-
-Version 1.1.5
-Version 1.0.6
-- Fixed a bug, which reported an #include statement as ill formed, if it was
- followed by an empty C comment only. This was an error in the cpp.re regular
- expression for C comments. Additionally, since this change simplified the
- Re2C generated lexer a lot it was possible to remove the compiler workaround
- for the VC7.1 compiler which prevented the optimization of this lexer.
-
-Mon Mar 29 09:36:59 WEDT 2004
-- Corrected the signature of the main() functions (was main(int, char const*[])).
-
-Sun Mar 28 12:55:59 WEDT 2004
-Version 1.1.4
-- Fixed a problem, where the first returned token was lost, whenever a
- --forceinclude file was given.
-- Adjusted the Wave driver and the other samples to use the new program_options
- library syntax (V1.1.x only).
-
-Mon Mar 1 19:14:21 WEST 2004
-Version 1.1.2
-Version 1.0.4
-- Fixed a problem, which does not report an error, if in a #define statement in
- between a macro name and its replacement list were no whitespace given.
-- Fixed a bug, which generated an unexpected exception of the $ character in the
- input.
-- Macro definitions, which differ by whitespace only (one definition contains
- whitespace at a certain position, the other definition does not) are correctly
- reported as a warning now.
-- Fixed a problem, where different formal argument names during macro
- redefinition were not flagged as a warning.
-- A wide character string used in a #line directive wasn't flagged as an error.
-
-Sun Feb 29 19:10:14 WEST 2004
-Used the test suite distributed with the mcpp V2.4 preprocessor to fix a bunch
-of mostly minor issues:
-- Fixed trigraph backslash followed by a newline handling (??/ \n) in the
- re2c (C/C++ and IDL) scanners.
-- Fixed a digraph/trigraph token type handling problem during macro expansion.
-- Fixed a digraph/trigraph token type problem during handling of the null
- preprocessor directive.
-- Fixed several signed/unsigned conversion bugs in the expression evaluator.
-- Fixed the || and && operators in the expression evaluator to stop evaluation,
- as only the outcome of the overall expression is determined.
-- Fixed the expression evaluation engine to detect divide by zero errors.
-- Fixed a bug with operator || and && arithmetic (the deduced type was wrong).
-- Fixed a bug with the unary operators ! and - which IN conjunction with an
- arithmetic operation yielded A wrong result type.
-- Fixed a bug, which reported a macro definition as an invalid redefinition, if
- it was different from the original definition only by different whitespaces.
-- Fixed a bug, which reported the redefinition of one of the alternative tokens
- as 'and', 'bit_and' etc. as invalid.
-- Fixed a bug in the character literal parser, which prevented the recognition
- of multibyte character literals.
-
-- Moved the cpp_token_ids.hpp header into the main wave.hpp header, because the
- values defined therein aren't changeable by the user anyway.
-- Fixed some spelling errors in the documentation (thanks to Rob Stewart).
-
-Tue Feb 3 20:20:16 WEST 2004
-- Fixed the problem, that macro definitions in a config file were flagged as
- an error, if there was any whitespace in between the -D and the macro name
- (same problem existed for -P).
-
-Fri Jan 30 20:28:27 WEST 2004
-- Fixed a missing boostification in the trace support header.
-- Added a missing std:: namespace qualification to the list_includes.cpp sample
- file.
-- Fixed line ending problems with the cpp.re and idl.re files.
-- Added quick_start sample.
-
-Sun Jan 25 20:26:45 WEST 2004
-This version was submitted to Boost as the review candidate (V1.1.0)
-- Fixed invalid explicit instantiation syntax as reported by the Comeau
- compiler.
-- Added a missing header to flex_string.hpp.
-
-Sat Jan 24 19:47:44 WEST 2004
-- Completely decoupled the used lexer from the preprocessor.
-- Unfortunately had to change the template interface of the context class. It
- now instead of the token type takes the type of the lexer to use.
-- Reintroduced the cpp_tokens, list_includes and waveidl samples.
- . cpp_tokens is based on the SLex lexer
- . list_includes shows the usage of the include file tracing capability
- . waveidl uses the Re2C based IDL lexer in conjunction with the default token
- type
-
-Tue Jan 13 20:43:04 WEST 2004
-- Fixed several compilation issues under linux (gcc 3.2.3, gcc 3.3, gcc 3.3.2,
- gcc 3.4, Intel V7.1)
-- Fixed a compatibility problem with Spirit versions older than V1.7.
-
-Mon Jan 12 20:39:50 WEST 2004
-- Boostified the code base:
- . Moved code into namespace boost.
- . Prefixed all pp constants with "BOOST_".
- . Refactured the directory structure.
-- Removed IDL mode and SLex lexer from the code base. These will be re-added as
- samples.
-- Changed the Wave configuration system to be more flexible (all
- #if defined(BOOST_WAVE_...) changed to #if BOOST_WAVE_... != 0),
- which allows to configure the library without changing the code base itself
-
-Sat Jan 10 18:17:50 WEST 2004
-- Incorporated Andrei Alexandrescu's latest changes to the flex_string class,
- which resulted in an overall spedd gain of about 5-10%.
-
-Wed Jan 7 17:46:45 WEST 2004
-- Found a major performance hole! The achieved general speedup is about 50-70%.
-- Added missing old MS specific extensions to the re2c lexer (_based,
- _declspec, _cdecl, _fastcall, _stdcall, _inline and _asm).
-- Added support for #include_next (as implemented by gcc).
-- Fixed compilation problems with gcc 3.3.1
-- Avoid to look up in symbol table of a potential macro name twice.
-- Added the Spirit SLex lexer sample to the Wave source tree, because it was
- removed from the Spirit distribution.
-- Removed the configuration option, which allowed to reverse the names stored
- in the symbol tables.
-- Implemented experimental support for using a TST (ternary search tree) as the
- container for the symbol tables.
-
-Sun Jan 5 12:30:50 2004
-- Released V1.0.0
-
-Sun Jan 4 00:11:50 2004
-- Removed tabs from the flex_string.hpp file.
-- Modified the input_functor.hpp file to sqeeze out some milliseconds at
- runtime.
-- The --timer option now prints the overall elapsed time even if an error
- occured.
-- Added support for #pragma once.
-
-Fri Jan 2 22:58:54 2004
-- Fixed a bug in the code, which predefines the preprocessor constants.
-- Fixed a bug in intlit_grammar<> initialisation code.
-
-Thu Jan 1 21:15:03 2004
-- Fixed a bug while predefining a macro with a value through the commmand line.
-- Fixed a bug, which reported a macro definition as illegal, if the redefined
- macro was a function like macro with parameters.
-- Fixed a bug, if concatenation of two tokens resulted in a C++ comment start
- token.
-
-Thu Jan 1 15:01:54 2004
-- Finished license migration.
-
-Wed Dec 31 12:23:55 2003
-- Changed the copyright and licensing policiy to be Boost compatible.
-
-Wed Dec 31 12:01:14 2003
-- Fixed a problem while compiling certain headers from the Microsoft Windows
- SDK:
- #define CreateWindowA(lpClassName, lpWindowName, dwStyle, x, y,\
- nWidth, nHeight, hWndParent, hMenu, hInstance, lpParam)\
- CreateWindowExA(0L, lpClassName, lpWindowName, dwStyle, x, y,\
- nWidth, nHeight, hWndParent, hMenu, hInstance, lpParam)
- where essentially is no whitespace between the parameter list and the macro
- replacement list.
-- Fixed a problem with the MS extension __declspec, which now is recognized
- correctly.
-
-Sat Dec 27 14:48:29 2003
-- Fixed remaining problems with assign/assign_a.
-- Fixed some gcc warnings about signed/unsigned comparision mismatch.
-
-Tue Nov 11 20:51:41 WEST 2003
-- Changed the IDL mode to recognize identifiers only. All keywords (except
- 'true' and 'false') are returned as identifiers. This allows for easy
- extension of the IDL language. The drawback is, that after preprocessing
- there needs to be just another lexing stage, which recognizes the keywords.
-- Fixed a possible problem, when in between a #if/#elif directive and a
- subsequent opening parenthesis Wave finds no whitespace:
- #if(_WIN_VER >= 0x0500)
- is now recognized correctly.
- (This problem was pointed out by Porter Schermerhorn).
-
-Sun Nov 9 21:05:23 WEST 2003
-- Started to work on implementation of an IDL lexer for the TAO idl compiler.
- . Branched off the Re2C C++ lexer and related files as a starting point for
- the new IDL lexer. Added connfiguration means to allow compile time
- decision, in which mode to operatoe (C++ or IDL).
- . Implemented the Re2C based IDL lexing component.
- . Fixed all occurences of non-IDL tokens (as T_COLON_COLON and T_ELLIPSIS)
-
-Sat Nov 8 20:05:52 WEST 2003
-- Version 1.0.0
-- Munged the email addresses embedded within the source files.
-- Adjusted for the new actor names in Spirit (assign_a and append_a).
-
-Thu Aug 21 16:54:20 2003
-- Removed the internally used macro 'countof()' to avoid possible nameclashes
- with user code.
-- Fixed a bug, which prevented the execution of the concatination operator '##'
- while expanding object-like macros.
-
-Tue Aug 5 10:04:00 2003
-- Fixed a false assertion, if a #pragma directive started with some whitespace
- on the line.
-- Added the #pragma wave timer() directive to allow rough timings during
- processing. This is done on top of a new callback hook for unrecognized
- #pragma's, which allows to easily add new pragma commands without changing
- the Wave library.
-- Fixed a bug in the whitespace insertion engine, which prevented the insertion
- of a whitespace token in between two consecutive identifier tokens or a
- integer literal token followed by an identifier token.
-- Fixed a bug during macro concatenation, which allowed to concatenate
- unrelated tokens from the input stream:
- #define CAT(a, b) PRIMITIVE_CAT(a, b)
- #define PRIMITIVE_CAT(a, b) a ## b
- #define X() B
- #define ABC 1
- CAT(A, X() C) // AB C
- CAT(A, X()C) // correct: AB C, was 1
-- Fixed a 64 bit portability problem.
-- Added pragma wave timer(suspend) and wave timer(resume)
-- Fixed a ODR problem with static initialization data for predefined macros.
-- Ported the iterators to the new iterator_adaptors.
-- Updated the documentation to reflect the recent changes
-
-Sun Jun 29 12:35:00 2003
-- Fixed 64 bit compatibility warnings.
-- Fixed a bug, which prevented the correct recognition of a #line directive, if
- only the filename part of this directive was generated by a macro expansion.
-- Fixed a bug during macro expansion of conditional expressions, which
- prevented the correct expansion of certain scoped macros.
-
-Fri Jun 27 09:50:14 2003
-- Changed the output of the overall elapsed time (option --timer) to cerr.
-- Added a configuration constant WAVE_REVERSE_MACRONAMES_FOR_SYMBOLTABLE, which
- reverses the macro names while storing them into the symbol table, which
- allows to speed up name lookup especially, if the macro names are very long
- and if these share a common prefix.
-- Fixed a very subtle bug, which prevented the recognition of fully qualified
- macro names during the macro expansion of conditionals expressions (for
- #if/#elif).
-- Improved the error output for the illformed pp expression error.
-
-Thu Jun 26 08:20:30 2003
-- Done a complete spell check of the source code comments.
-
-Wed Jun 25 20:33:52 2003
-- Changed the conditional expression engine to work with integer numeric
- literals only. Distinguished signed and unsigned literals.
-- Importing a region twice is allowed now.
-- Fixed a bug, which does not removed all placeholder tokens from a expanded
- token sequence while evaluating conditional expressions (C++0x mode only).
-
-Wed Jun 25 15:01:51 2003
-- Changed the conditional expression engine to respect the type of numeric
- literals, now expressions like '#if 1 / 10 == 0' evaluate correctly (to true
- :-)
-- Fixed a bug, where macro names referring to global macros (as ::A::B) were
- not correctly recognized under certain circumstances.
-- Empty parameter lists for macros with ellipses only sometimes generated a
- placemarker token in the output:
- #define STR(...) #__VA_ARGS__
- STR() // resulted in "§" instead of "" .
-
-Wed Jun 25 08:35:06 2003
-- Fixed several gcc compilation errors (missing typename's etc.)
-- Fixed a compilation problem, if Wave is built on top of the SLEX scanner.
-- Reformatted the --timer output from pure seconds to a more reasonable format.
-
-Fri Jun 20 19:33:30 2003
-- Changed the enable_tracing function of the tracing_policies to take a
- trace_flags variable instead of a bool, to allow to control tracing with more
- granulation.
-- Added the tracing_enabled function to the tracing_policies, which returns the
- current tracing status.
-- Updated the documentation of the tracing policies.
-
-Thu Jun 19 21:45:39 2003
-- Reactivated the list_includes sample with the help of the new include file
- tracing facility.
-
-Thu Jun 19 17:55:35 2003
-- Eliminated the TraceT template parameter from the macromap<> template.
-- Added two hooks to the trace policy to allow to trace the opening and
- closing of include files.
-
-Thu Jun 19 14:08:10 2003
-- Added the command line option --timer, which enables the output to std::cout
- of the overall elapsed time during the preprocessing of the given file.
-
-Fri Jun 13 09:11:29 2003
-- Emitted an error message, if an ellipses was found as a formal macro
- parameter and variadics were disabled.
-- Fixed a false error message, that the last line was not terminated with a
- newline, which occured, if no output was generated by the last line of the
- source file.
-
-Thu Jun 12 15:20:22 2003
-- Fixed the recent change in argument expansion for the variadics/C99/C++0x
- mode.
-- Fixed a problem, where an additional whitespace between _Pragma and the
- opening parenthesis resulted in a false error message.
-- Used a pool allocator for the token sequence containers (std::list<>'s),
- which gives a speed gain of more than 60% (while profiling the Order
- library).
-
-Wed Jun 11 22:18:54 2003
-- Fixed a macro scoping/expansion problem, when a macro returned a full scope
- which is continued on the call site to form a full qualified name, the name
- wasn't recognized correctly:
- # region A
- # define MACRO 1
- # region B
- # define MACRO 2
- # endregion
- # endregion
- # define ID(x) x
- ID(A)::MACRO // 1
- ID(A::B)::MACRO // 2, was expanded to A::B::MACRO
-- Changed the expansion of macro arguments such, that these will be expanded
- only, if the result is to be used for substitution during the expansion
- of the replacement list.
-
-Wed Jun 11 14:40:29 2003
-- Included a whitespace eating finite state machine (FSM) for minimal
- whitespace in the generated output. This was suggested by Paul Mensonides.
-- Updated the acknowledgement section
-
-Wed Jun 4 08:03:04 2003
-- Fixed a bug reported by Faisal Vali, which prevented the correct evaluation
- of conditional expressions, if these referenced macro names, which expanded
- to a sequence containing non-expandable tokens.
-- Fixed the above bug for #elif directives too (in the first place this was
- fixed for #if directives only)
-
-Mon May 26 22:15:40 2003
-- Added missing copyrights in several files.
-- Fixed false output, if a unknown _Pragma were encountered.
-- Fixed a macro expansion problem with qualified names, were constructs like
- the following were not expanded correctly:
- #define ID(x) x
- #region SCOPE
- # define TEST 1
- #endregion
- ID(SCOPE::) TEST // should expand to 1
-- Changed #import semantics for macros from copy semantics to reference
- semantics, i.e. macros are now considered to be implicitly imported into the
- scope, where they are defined. If a macro is imported into another scope and
- the original macro is undefined, the imported macro still exists. Further,
- if the imported macro is expanded, then while rescanning the original macro
- is disabled too:
- #region A
- # define B(x) x
- #endregion
- #import A
- B (A::B) (*) // A::B(*)
- A::B (B) (*) // B(*)
- B (B) (*) // B(*)
- A::B (A::B) (*) // A::B(*)
-- Fixed a recently introduced problem, where placemarker tokens slipped through
- to the output under certain conditions (in variadics/C99/C++0x modes only).
-
-Mon May 19 16:30:49 2003
-- Fixed a bug, which prevented the recognition of the __lparen__, __rparen__ or
- __comma__ alternative tokens, if these were the first token after an emitted
- #line directive (reported by Vesa Karvonen).
-- Added an optimization, that only those tokens are considered for a macro
- expansion, which may result in an expansion.
-
-Tue May 13 18:16:26 2003
-- Fixed a newly introduced problem, where a omitted argument consisting out
- of whitespace only were failed to be replaced by a placemarker token. This
- lead to problems with constructs like the following:
- #define paste(a, b, c) a ## b ## c
- paste(1, , 3) // should expand to 13, but expanded to 1## 3
-- Fixed a problem with the tracing support, which throwed an unexpected
- exception if there were too few arguments given while expanding a macro.
-- Allowed to open and to import the global scope ('#region ::' and
- '#import ::').
-- Fixed a bug, if more than one file was given with a --forceinclude command
- line option.
-
-Sat May 10 21:30:29 2003
-- Added __STDC_FULL_REGION__ and __STDC_CURRENT_REGION__ to the list of not
- undefinable macros.
-- In normal C++ mode and C99 mode the #ifdef/#ifndef and the operator defined()
- should not support qualified names. This is fixed now.
-- Updated the documentation.
-- Fixed minor gcc -Wall compilation warnings.
-- Added better error support for qualified names used as arguments for #ifdef,
- #ifndef and operator defined().
-
-Sat May 10 09:51:18 2003
-- Removed the feature, that the comma before the ellipsis parameter in a macro
- definition may be omitted.
-- Resolved an issue with the expansion of qualified macros, when these
- qualified names were partially generated by a previous macro expansion
-- Allowed to specify fully qualified names as arguments to the #region directive
-
-Wed May 7 22:44:21 2003
-- Changed the names of __SCOPE__ and __FULL_SCOPE__ predefined macros to
- __STDC_CURRENT_REGION__ and __STDC_FULL_REGION__ resp. The names are subject
- to change if the #region keyword actually will be renamed to #scope/#module
- or whatever.
-- In C++0x mode it is now possible to omit the last comma before a variadics
- ellipsis in a macro definition:
- #define cat_i(a, b, c, d, e ...) a ## b ## c ## d ## e
-- Fixed a bug in the stringize code, where an ellipsis to stringize resulted in
- stringizing of the first ellipsis parameter only. Preserved the original
- whitespace delimiting in between the ellipsis arguments.
-- Introduced the wave::language_support enum for convenient switching of the
- supported language features throughout the library.
-- Fixed a bug, which prevented the definition of the predefined macro
- __WAVE_HAS_VARRIADICS__, if --variadics were given on the command line.
-
-Tue May 6 15:49:45 2003
-- Made predefined macros available at every macro scope without qualification.
-- Predefined a new macro in C++0x mode: __STDC_GLOBAL__, which is defined at
- global macro scope only and equals to '1' (integer literal).
-- In C++0x mode there are two new predefined macros:
- __SCOPE__: expands to the last part of the qualified name of the
- current macro scope
- __FULL_SCOPE__: expands to the full qualified name of the current macro
- scope
-
-Mon May 5 23:02:48 2003
-- Fixed a problem in the new well defined token pasting code, which occured for
- constructs like the following:
- #define is_empty(...) is_empty_ ## __VA_ARGS__ ## _other
- i.e. where two or more '##' operators were contained in the replacement text.
-- Implemented __comma__, __lparen__ and __rparen__ alternative pp-tokens, which
- may be used as the ',', '(' and ')' tokens during preprocessing. These are
- only converted to there respective string representation in a special
- translation phase after preprocessing. This was proposed by Vesa Karvonen.
-- Changed the macro scoping rules to: "If a qualified name does not find a
- nested name, it is not a qualified name to the preprocessor." This seems to
- be the simplest usable solution for the possible ambiguities.
-- Fixed a bug in the macro expansion engine in C++0x mode, where the skipping
- of whitespace inside of a qualified name wasn't consistent.
-
-Sun May 4 10:48:53 2003
-- Fixed a bug in the expression grammar, which prevented 'not' to be recognized
- as a valid operator.
-- Qualified names are now supported as parameters to #ifdef and #ifndef too.
-- Remove one specialization of the macro expansion engine. It gets instantiated
- only twice now (for the main input iterator and for list<>'s of tokens.
-- Simplified the required explicit specialization of the defined_grammar
- template. It has to be explicitely instantiated by providing the token type
- only (just as for the explicit instantiations of the other grammars).
-
-Fri May 2 22:44:27 2003
-- Qualified names are now allowed as parameters to the operator defined() in
- C++0x mode.
-- Separated the defined() functionality into a separate translation unit to
- work around a VC7.1 ICE.
-
-Fri May 2 15:38:26 2003
-- The C++0x mode now has a special set of predefined macros.
-- The predefined macro __WAVE_HAS_VARIADICS__ is now defined in C99 and C++0x
- modes too (--variadics is implied for these modes).
-- Updated the documentation to reflect the recent changes and additions.
-- In C++0x mode Wave now supports macro scopes:
- - new keywords #region/#endregion/#import
- - qualified macro names
-- In C++0x mode Wave now supports token pasting of unrelated tokens. These are
- concatenated, the result is re-tokenized and inserted into the output stream.
-- Fixed a minor bug in the macro expansion engine, if a qualified function-like
- macro was found in an object-like context.
-- Fixed an issue with well defined token pasting of unrelated tokens.
-
-Tue Apr 29 08:47:37 2003
-- Fixed a bug in the macro expansion engine, which prevented the expansion
- of a certain macro under specific conditions (if the left of two tokens to
- concatenate were a disabled one (T_NONREPLACABLE_IDENTIFIER), then the
- resulting token was disabled too).
-- Added additional diagnostics to the Wave driver to disambiguate the C99 and
- C++0x modes.
-- Implemented a new API function and a corresponding Wave driver command line
- option, which allows to specify one or more include files to be preprocessed
- before the regular file is preprocessed (the files are processed as normal
- input and all the resulting output is included, before processing the regular
- input file). The Wave driver command line option is --forceinclude (-F).
-- Wave now compiles the Order library from Vesa Karvonen.
-
-Mon Apr 28 07:57:10 2003
-- Fixed a bug in the macro expansion engine.
-- Removed a lot of (not needed) whitespace in the generated output (but still
- not optimal).
-
-Sat Apr 26 20:30:53 2003
-- Fixed a bug in the initialization code of the Slex lexer while working in
- C99 mode (reported by Reece Dunn).
-
-Fri Apr 18 08:37:35 2003
-- Fixed the handling of option_value's inside of pragma directives:
- _Pragma("wave option(option_value)")
- inside which all all whitespaces were deleted.
-- Started to implement experimental macro scoping.
-
-Thu Apr 10 10:20:07 2003
-- Fixed a problem with the #pragma wave stop(), where only the first token
- inside the stop directive was output, when the preprocessor stops in result
- of this pragma.
-- Implemented a new #pragma wave system(command), which spawns a new operation
- system command exactly as specified inside the system directive, intercepts
- the stdout output of this process, retokenizes this output and inserts the
- generated token sequence in place of the original #pragma or operator _Pragma.
- Please note that the generated output is _not_ subject to any macro expansion
- before its insertion as the replacement of the pragma itself. If you need to
- macro expand the replacement text, you always may force this by writing:
- #define SCAN(x) x
- SCAN(_Pragma("wave system(...)"))
- which re-scans the replacement once.
-- Replaced the Wave position_iterator with the boost::spirit::position_iterator
- (without any problems!).
-
-Mon Apr 7 10:45:30 2003
-- Fixed macro_trace_policies::expand_object_like_macro not to be called with
- the formal arguments as one of its parameters.
-- Updated the documentation to reflect the changes needed for the tracing
- stuff.
-
-Mon Mar 31 19:07:05 2003
-- Fixed variadics support in the trace output.
-- Fixed preprocessing of operator _Pragma() before it's execution.
-- Added _Pragma("wave stop(errmsg)") (#pragma wave stop(errmsg)) to allow
- diagnostics output from inside macro expansion.
-- Fixed operator _Pragma for unknown pragmas (these are simply put through to
- the output).
-- Implemented a maximal possible include nesting depth to avoid an out of
- memory error. The initial value for this is configurable through the compile
- time constant WAVE_MAX_INCLUDE_LEVEL_DEPTH, which defaults to 1024, if not
- given.
- Additionally this may be enlarged through a new command line option:
- -n/--nesting (Wave driver only).
-
-Sun Mar 30 20:40:17 2003
-- Implemented the predefined macro __INCLUDE_LEVEL__, which expands to a
- decimal integer constant that represents the depth of nesting in include
- files. The value of this macro is incremented on every '#include' directive
- and decremented at every end of file.
-- Implemented the operator _Pragma(). It is recognized in C99 mode and whenever
- variadics are enabled.
-
-Sun Mar 30 08:30:12 2003
-- Changed the tracing format to be more readable.
-- Changed the tracing #pragma's to
- enable tracing: #pragma wave trace(enable)
- disable tracing: #pragma wave trace(disable)
- or
- enable tracing: #pragma wave trace(1)
- disable tracing: #pragma wave trace(0)
-- Changed the semantics of the -t (--traceto) switch. Without any -t switch
- there isn't generated any trace output at all, even, if the corresponding
- #pragma directives are found. To output the trace info to a file, the
- '-t file' syntax may be used, to output to std::cerr, the '-t-' (or '-t -')
- syntax may be used.
-
-Fri Mar 28 17:27:25 2003
-- Added a new template parameter to the wave::context<> object, which allows
- to specify a policy for controlling the macro expansion tracing. The default
- macro_trace_policy does no tracing at all. This way one can add specific
- macro expansion tracing facilities to the library.
-- #pragma directives starting with a STDC identifier are no longer not macro
- expanded in C++ mode, in C++ mode these are now expanded as usual, in C99
- mode not.
-- The tracing can be enabled/disabled from inside the preprocessed stream by
- inserting a special #pragma directive:
- enable tracing: #pragma wave_option(trace: enable)
- disable tracing: #pragma wave_option(trace: disable)
-- The Wave driver now allows to specify a destination for the macro expansion
- tracing trough a new command line switch: '-t path' or '--traceto path'. If
- this option isn't given, the trace output goes to stderr.
-- The Wave driver now allows to specify the name of the file, where the
- preprocessed result stream is to be saved: '-o path' or '--output path'. If
- this option is not given, the output goes to stdout.
-
-Wed Mar 26 20:39:11 2003
-- Fixed a problem with alternative tokens (as 'and', 'or' etc.) and trigraph
- tokens, which were not correctly recognized inside #if/#elif expressions.
-- Alternative tokens ('and', 'or' etc.) are no longer subject to a possible
- macro redefinition.
-- Fixed the special handling of 'true' and 'false' during the macro expansion
- of #if/#elif expressions.
-
-Tue Mar 25 12:12:35 2003
-- Released Wave V0.9.1
-
-Mon Mar 24 13:34:27 2003
-- Implemented placemarkers, i.e. Wave now supports empty arguments during macro
- invocations. This must be enabled by means of a new pp constant:
- WAVE_SUPPORT_VARIADICS_PLACEMARKERS which must be defined to enable the
- placemarker and variadics code and by defining the command line option
- '--variadics' (Wave driver only).
-- Implemented variadics, i.e. Wave now supports macros with variable parameter
- counts. This must be enabled by means of the pp constant:
- WAVE_SUPPORT_VARIADICS_PLACEMARKERS which must be defined to enable the
- placemarker and variadics code and by defining the command line option
- '--variadics' (Wave driver only).
-- Implemented a C99 mode. This mode enables variadics and placemarkers by
- default and rejects some specific C++ tokens (as the alternate keywords and
- '::', '->*', '.*'). This mode must be enabled by the means of the pp constant
- WAVE_SUPPORT_VARIADICS_PLACEMARKERS (see above). The C99 mode is enabled by
- the command line switch '--c99' (Wave driver only).
- This involved some changes in the C99/C++ lexers.
-
-Fri Mar 21 16:02:10 2003
-- Fixed a bug in the macro expansion engine, which prevented the expansion of
- macros, which name was concatenated out of a identifier and a integer
- followed directly by another identifier:
- #define X() X_ ## 0R() // note: _zero_ followed by 'R'
- #define X_0R() ...
- X() // expanded to: X_0R(), but should expand to ...
- This is a problem resulting from the fact, that the Standard requires the
- preprocessor to act on so called pp-tokens, but Wave acts on C++ tokens.
-
-Thu Mar 20 21:39:21 2003
-- Fixed a problem with expression parsing (#if/#elif constant expressions),
- which failed to produce an error message for expressions like
- #if 1 2 3 4 5
- i.e. where the token sequence starts with a valid constant expression, but
- the remainder of the line contained other tokens than whitespace.
-- Integrated the flex_string class from Andrei Alexandrescu (published on the
- CUJ site) to get COW-string behaviour for the token values and position
- filename strings. This resulted in a major overall speedup (about 2-3 times
- faster in dependency of the complexity of pp usage in the input stream).
-- Fixed a bug, which reported ill formed #if/#else expressions as errors, even
- if the current if block status (conditional compilation status) is false.
-- Added a warning, if the last line of a file does not end with a newline.
-- Improved error recognition and handling for malformed preprocessor directives
-
-Mon Mar 17 19:53:29 2003
-- Fixed a concatenation problem: constructs like a##b##c where expanded
- incorrectly.
-- Optimized the recognition of pp directives:
- - the parser is used only, if the next non-whitespace token starts a pp
- directive
- - null directives now are recognized without calling the parser
- - the parser isn't called anymore, if the if_block_status is false and no
- conditional pp directive (#if etc.) is to be recognized.
- These optimizations give a speed improvement by upto 40%.
-- Removed adjacent whitespace during macro expansion (needs to be revised,
- since there is some whitespace left, which may be removed)
-
-Sun Mar 16 23:19:11 2003
-- Fixed a problem with include paths given on the command line, if the file
- to preprocess was not given as a full path (driver executable).
-- Fixed a problem with path names containing blanks (driver executable).
-- Cleaned command line and argument handling (driver executable).
-- Fixed a severe memory leak.
-- Fixed a bug, if a C++ keyword was used as a macro name or macro parameter
- name, which prevented the macro recognition and expansion to function
- properly.
-- Implemented the WAVE_SUPPORT_MS_EXTENSIONS compiler switch for the re2c
- generated lexer too.
-- Fixed a problem, which caused an internal T_PLACEHOLDER token to show up
- outside the macro replacement engine.
-- Fixed a problem with macro #include directives, which prevents to find the
- file to include, if after the macro expansion the token sequence representing
- the filename began or ended with at least one whitespace token.
-- Fixed a problem, which caused a false error message if the '#' character was
- to be concatenated with an arbitrary other token.
-- The concatenation of a whitespace token with an arbitrary other token was
- reported as illegal token pasting (but it is certainly not).
-
-Sat Mar 15 21:43:56 2003
-- Added a default constructor to the wave::util::file_position template.
-- Report the concatenation of unrelated tokens as an error.
-- Finished the documentation.
-
-Fri Mar 14 20:14:18 2003
-- More work on documentation
-- Changed file_position to expose accessor functions (the member variables are
- marked as private now). This opens up the possibility to provide another
- file_position implementation, which may be optimized in some way.
-- Fixed a problem with the token name table, the alternate and trigraph token
- names were printed incorrectly.
-- Fixed a bug, which prevented the correct recognition of 'defined X' (without
- parenthesises).
-- Fixed a bug, which allowed to redefine and undefine the predefined name
- 'defined'.
-- Fixed a bug, which prevents the correct recognition of a macro based #include
- directive, if it expands to something like #include <...>.
-- Fixed a bug, which prevented the recognition of duplicate macro parameter
- names.
-- Removed the insertion of additional whitespace inside of string literals
- (during stringizing).
-
-Wed Mar 12 19:16:40 2003
-- Fixed a bug, which prevented the instantiation of the wave::context object
- with auxiliary iterators. The token type isn't coupled anymore with the
- iterator type.
- This required some changes in the interface:
- - The wave::context object now has three template parameters (the iterator
- type, the token type and the input policy type)
- - The token type does not have the iterator type as it's template parameter
- anymore.
-- Implemented a new position_iterator template on top of the iterator_adaptor<>
- template to make it work even for input_iterator type iterators.
-- Fixed a bug in the regular expressions for the Slex lexer.
-- The function 'set_sys_include_delimiter()' was renamed to
- 'set_sysinclude_delimiter()' to better fit the naming scheme of the other
- functions.
-- Wrote more documentation
-- Unified the different token definitions of the lexers, so that there is only
- one token type left. This required some changes in the interface:
- - There is no need anymore to explicitly specify the namespace of the token
- type to use.
-- Added the command line option -P to the Wave driver program, which predefines
- a macro (i.e. defines it such, that is _not_ undefinable through an #undef
- directive from inside the preprocessed program).
-
-Sat Mar 8 07:46:43 2003
-- Released Wave 0.9.0
-
-Thu Mar 6 20:02:44 2003
-- Compiled Wave with IntelV7.0/DinkumwareSTL (from VC6sp5)
-- Fixed new compilation problems with gcc -Wall
-- Fixed the list_includes and cpp_tokens samples to compile and link correctly.
-- Fixed a bug, where a wrong filename was reported by the generated #line
- directive.
-- Fixed a bug, where the __FILE__ macro was expanded without '\"' around the
- filename.
-- The generated #line directives and the expanded __FILE__ macro now report
- the filename in a native (to the system) format. Additionally the generated
- string literals are now escaped correctly.
-
-Wed Mar 5 21:11:14 2003
-- Reorganized the directory structure to mirror the namespace structure of the
- library
-- Fixed a bug, where the complete input after the first found #include
- directive were eaten up.
-- Fixed a bug, where the __LINE__ macro expanded to a incorrect linenumber, if
- the __LINE__ macro was encountered on a line after a '\\' '\n' sequence.
-
-Tue Mar 4 11:50:24 2003
-- The new name of the project is 'Wave'.
-- Adjusted namespaces, comments etc. to reflect the new name.
-- Added the command line option -U [--undefine], which allows to remove one of
- the predefined macros (except __LINE__, __FILE__, __DATE__, __TIME__,
- __STDC__ and __cplusplus)
-
-Sun Mar 2 20:10:04 2003
-- Fixed a bug while expanding macros without any definition part (empty macros)
-- The pp-iterator will not emit a newline for every recognized preprocessing
- directive anymore. The generated output is much more condensed this way.
-- The pp-iterator now emits #line directives at appropriate places.
-- Added an additional parser to the library, which may be used to parse macros
- given in the command line syntax, i.e. something like 'MACRO(x)=definition'.
-- Added the possibility to the cpp driver sample, to add macros from the
- command line through the -D command line switch.
-- Martin Wille contributed a test script to allow automatic testing of the
- cpp driver sample by feeding all files contained in the test_files directory
- through the cpp driver and comparing the generated output with the
- corresponding expectations.
-- Added config file support to allow for predefined option sets (for instance
- for the emulation of other compilers)
-- Changed the way, how include paths are defined. It resembles now the
- behaviour of gcc.
- Any directories specified with '-I' options before an eventually given '-I-'
- option are searched only for the case of '#include "file"', they are not
- searched for '#include ' directives. If additional directories are
- specified with '-I' options after a '-I-' option was given, these directories
- are searched for all '#include' directives. In addition, the '-I-' option
- inhibits the use of the current directory as the first search directory for
- '#include "file"'. Therefore, the current directory is searched only if it is
- requested explicitly with '-I.'. Specifying both '-I-' and '-I.' allows to
- control precisely which directories are searched before the current one
- and which are searched after.
-- Added config file support to the cpp driver.
-- stored not only the current 'name' of a file (given eventually by a #line
- directive) but in parallel the actual full file system name of this file too.
-
-Tue Feb 25 21:44:19 2003
-- Fixed the warnings emitted by gcc -Wall.
-- Fixed a bug in the cpp grammar, which causes to failing the recognition of
- certain preprocessor directives if at the end of this directive were placed
- a C++ comment.
-- Simplified and extended the insertion of whitespace tokens at places, where
- otherwise two adjacent tokens would form a new different token, if
- retokenized.
-
-Mon Feb 24 19:13:46 2003
-- defined() functionality was broken
-- added missing typename keywords
-- added missing using namespace statements, where appropriate
-- added a warning, when a predefined macro is to be undefined (by an #undef
- directive)
-- removed the 'compile in C mode' hack for the re2c generated lexer (VC7.1
- (final beta) is not able to compile it with optimizations switched on
- anyway :( )
-- compiled with gcc 3.2 and Intel V7.0 (20030129Z)
-
-Sun Feb 23 23:39:33 2003
-- Fixed a couple of 'missing typename' bugs (thanks to Martin Wille)
-- Added code to insert whitespace at places, where otherwise two adjacent
- tokens would form a new different token, if retokenized.
-- Fixed a severe macro expansion bug.
-- Added the handling of invalid or not allowed universal character values
- inside of string literals and character literals.
-
-Sat Feb 22 20:52:06 2003
-- Bumped version to 0.9.0
-- Added test for invalid or not allowed universal character values (see
- C++ Standard 2.2.2 [lex.charset] and Annex E)
-- Fixed a bug with newlines between a macro name and the opening parenthesis
- during the macro expansion and a bug with newlines inside the parameter list
- during the macro expansion.
-- Added the following predefined macros:
- __SPIRIT_PP__
- expands to the version number of the pp-iterator lib (i.e. 0x0090 for
- V0.9.0)
- __SPIRIT_PP_VERSION__
- expands to the full version number of the pp-iterator lib (i.e.
- 0x00900436 for V0.9.0.436)
- __SPIRIT_PP_VERSION_STR__
- expands to the full version string of the pp-iterator lib (i.e.
- "0.9.0.436")
-
-Fri Feb 21 22:09:04 2003 (feature complete!)
-- Allowed to optionally compile the Re2c generated lexer in 'C' mode, because
- at least the VC7.1 (final beta) compiler has problems to compile it in 'C++'
- mode with optimizations switch on
-- Implemented #error and #warning (optional) directives (C++ standard 16.5).
- Additionally there are now allowed the following preprocessor configuration
- constants:
- CPP_PREPROCESS_ERROR_MESSAGE_BODY
- if defined, preprocesses the message body of #error and #warning
- directives to allow for better diagnostics.
- CPP_SUPPORT_WARNING_DIRECTIVE
- if defined, then the #warning directive will be recognized such, that
- a warning with the given message will be issued
-- Adjusted the error handling for the Re2c generated C++ lexer, so that any
- error inside the lexer is now propagated as an cpplexer_exception.
-- Implemented the #line directive (C++ standard 16.4)
-- Implemented #pragma directive (C++ standard 16.6)
- Additionally there are now allowed the following preprocessor configuration
- constants:
- CPP_RETURN_PRAGMA_DIRECTIVES
- if defined, then the whole pragma directive is returned as a token
- sequence to the caller, if not defined the whole pragma directive is
- skipped
- CPP_PREPROCESS_PRAGMA_BODY
- if defined, then the #pragma body will be preprocessed
-- Implemented #include directive with macro arguments (C++ standard 16.2.4)
-- Made the namespace structure finer granulated to leave only the main
- interface classes in the main namespace cpp. All other classes are moved into
- sub-namespaces to reflect the logical dependencies
-- Reorganized the public interface of the context<> template class, made all
- non relevant functions into the protected.
-- Implemented predefined macros (__LINE__ et.al.) (C++ standard 16.8)
-- Further documentation work
-
-Wed Feb 19 23:44:47 2003
-- Corrected a lot of bugs in the macro expansion engine, which now should be
- conformant to the C++ standard.
-- # (null) directive (C++ standard 16.7)
-
-Sun Feb 16 08:40:38 2003
-- Added a macro expansion engine which expands macros with arguments
- C++ standard 16.3 [cpp.replace]
-- Added a new sample: cpp_tokens. This sample preprocesses a given file and
- prints out the string representations of all tokens returned from the pp
- iterator
-- Added documentation (to be continued!)
-- Added a couple of small test files to test elementary functionality
- (the tests mainly were contributed by Paul Mensonides)
-- The main cpp sample is now a simple preprocessor driver program, which
- outputs the string representation of the preprocessed input stream. Use
- cpp --help to get a hint, how to use it.
-- Fixed a bug in the preprocessor grammar which failed to recognize a pp
- statement, if there was a C++ comment at the end of the line
-- Added '#' operator (C++ standard 16.3.2) [cpp.stringize]
-- Fixed a bug in the slex based C++ lexer to handle the concatenation
- characters correctly ('\\' followed by a '\n')
-
-Sun Feb 9 23:01:00 2003
-- Improved error handling for #if et.al.
-- Fixed a pair of lexer errors
-- Implemented the #if/#elif statements, the sample now contains a complete C++
- expression evaluation engine (for the calculation of the outcome of the
- #if/#elif statement conditions)
-- Implemented macro replacement (with parameters)
-- Implemented the '##' [cpp.concat] operator
-- Implemented the defined() [cpp.cond] operator
-
-Sun Feb 2 23:28:24 2003
-- Implemented the #define, #undef, #ifdef, #ifndef, #else and #endif
- statements
-- Added optional parse tree output as xml stream (controlled through the config
- pp constant CPP_DUMP_PARSE_TREE)
-
-Fri Jan 31 21:30:55 2003
-- Fixed different minor issues and a border case (#include statement at the
- last line of a included file)
-
-Wed Jan 29 21:13:32 2003
-- Fixed exception handling to report the correct error position
-- Fixed another bug in the stream position calculation scheme
-- Added a more elaborate sample 'list_includes' which lists the dependency
- information for a given source file (see test/list_includes/readme.txt).
-
-Sat Jan 18 22:01:03 2003
-- Fixed a bug in the stream position calculation scheme
-- Made cpp::exceptions more standard conformant (added 'throw()' at appropriate
- places)
-- Overall housekeeping :-)
-
-Wed Jan 15 21:54:20 2003
-Changes since project start (still 0.5.0)
-- Added #include <...> and #include "..." functionality
-- pp directives are now generally recognized
-- Decoupled the C++ lexers and the pp grammar to separate compilation
- units (optionally) to speed up compilation (a lot!)
-
-Thu Jan 2 12:39:30 2003
-A completely new version 0.5.0 of the C preprocessor was started. It's a
-complete rewrite of the existing code base. The main differences are:
-- The preprocessor is now implemented as an iterator, which returns the
- current preprocessed token from the input stream.
-- The preprocessing of include files isn't implemented through recursion
- anymore. This follows directly from the first change. As a result of this
- change the internal error handling is simplified.
-- The C preprocessor iterator itself is feeded by a new unified C++ lexer
- iterator. BTW, this C++ lexer iterator could be used standalone and is not
- tied to the C preprocessor. There are two different C++ lexers implemented
- now, which are functionally completely identical. These expose a similar
- interface, so the C preprocessor could be used with both of them.
-- The C++ lexers integrated into the C preprocessor by now are:
- Slex: A spirit based table driven regular expression lexer (the slex
- engine originally was written by Dan Nuffer and is available as a
- separate Spirit sample).
- Re2c: A C++ lexer generated with the help of the re2c tool. This C++
- lexer was written as a sample by Dan Nuffer too.
- It isn't hard to plug in additional different C++ lexers. There are plans to
- integrate a third one written by Juan Carlos Arevalo-Baeza, which is
- available as a Spirit sample.
-
--------------------------------------------------------------------------------
-Tue Feb 12 22:29:50 2002
-Changes from 0.2.3 to 0.2.4:
-- Moved XML dumping functions to the main Spirit directory
-- Fixed operator '##', it was not correctly implemented somehow :-(
-
-Sun Feb 10 21:07:19 2002
-Changes from 0.2.2 to 0.2.3:
-- Implemented concatenation operator '##' (cpp.concat)
-- Removed defined() functionality for Intel compiler (it ICE's) until this
- issue is resolved
-- Separated code for dumping a parse tree to XML for inclusion in the main
- Spirit headers
-
-Thu Jan 17 23:51:21 2002
-Changes from 0.2.1 to 0.2.2:
-- Fixes to compile with gcc 2.95.2 and gcc 3.0.2 (thanks Dan Nuffer)
-- Reformatted the grammars to conform to a single formatting guideline
-- Assigned explicit rule_id's to the rules of cpp_grammar, so that the
- access code to the embedded definition class is not needed anymore
-- Fixed a remaining const problem
-
-Tue Jan 15 23:40:40 2002
-Changes from 0.2.0 to 0.2.1:
-- Corrected handling of defined() operator
-- In preprocessing conditionals undefined identifiers now correctly
- replaced by '0'
-- Fixed several const problems
-- Added parse_node_iterator for traversing one node in a parse_tree
- without going deeper down the hierarchy than one level (this is useful,
- if all inspected tokens arranged along a single node in the parse tree.
- The main difference to the parse_tree_iterator is, that the underlying
- iterator generally can be adjusted correctly after advancing the attached
- parse_node_iterator
-- Fixed a problem with gcc 2.95.2, which doesn't have a header
-- Prepared usage of slex for lexer states
-
-Sun Jan 13 10:21:16 2002
-Changes from 0.1.0 to 0.2.0:
-- Added operator 'defined()'
-- Added directive '#warning'
-- Corrected error reporting
-- Added command line option -I- for finer control of the searched include
- directories (-I and -I- should now work as in gcc, see readme.html for
- more info)
-- Corrected conditional preprocessing (should be fully functional now)
-- Fixed existing code base for changes made in parse tree support
-- Moved parse tree utility functions to a separate header (prepared for
- inclusion to the Spirit main library)
diff --git a/build/Jamfile b/build/Jamfile
deleted file mode 100644
index 74d0d2d..0000000
--- a/build/Jamfile
+++ /dev/null
@@ -1,64 +0,0 @@
-# Boost.Wave: A Standard compliant C++ preprocessor library
-#
-# Boost Wave Library Build Jamfile
-#
-# http://www.boost.org/
-#
-# Copyright (c) 2001-2005 Hartmut Kaiser. Distributed under the Boost
-# Software License, Version 1.0. (See accompanying file
-# LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
-
-subproject libs/wave/build ;
-
-SOURCES = instantiate_cpp_exprgrammar
- instantiate_cpp_grammar
- instantiate_cpp_literalgrs
- instantiate_defined_grammar
- instantiate_predef_macros
- instantiate_re2c_lexer
- instantiate_re2c_lexer_str
- cpplexer/re2clex/aq
- cpplexer/re2clex/cpp_re
- ;
-
-lib boost_wave
- : ../src/$(SOURCES).cpp
- : # build requirements
- [ common-names ] # magic for install and auto-link features
- $(BOOST_ROOT)
- $(BOOST_ROOT)
- <*>off # workaround for compiler bug
- cpp_re.cpp
- : debug release # build variants
- ;
-
-#dll boost_wave
-# : ../src/$(SOURCES).cpp
-# : # build requirements
-# [ common-names ] # magic for install and auto-link features
-# BOOST_WAVE_DYN_LINK=1 # tell source we're building dll's
-# dynamic # build only for dynamic runtimes
-# $(BOOST_ROOT)
-# $(BOOST_ROOT)
-# : debug release # build variants
-# ;
-
-install wave lib
- : boost_wave
-# boost_wave
- ;
-
-stage stage/lib : boost_wave # boost_wave
- :
- # copy to a path rooted at BOOST_ROOT:
- $(BOOST_ROOT)
- # make sure the names of the libraries are correctly named:
- [ common-names ]
- # add this target to the "stage" and "all" pseudo-targets:
- stage
- all
- :
- debug release
- ;
-
-# end
diff --git a/build/Jamfile.v2 b/build/Jamfile.v2
deleted file mode 100644
index b42f9d5..0000000
--- a/build/Jamfile.v2
+++ /dev/null
@@ -1,46 +0,0 @@
-# Boost.Wave: A Standard compliant C++ preprocessor library
-#
-# Boost Wave Library Build Jamfile
-#
-# http://www.boost.org/
-#
-# Copyright (c) 2001-2005 Hartmut Kaiser. Distributed under the Boost
-# Software License, Version 1.0. (See accompanying file
-# LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
-
-project boost/wave
- :
- source-location ../src
- ;
-
-SOURCES =
- instantiate_cpp_exprgrammar
- instantiate_cpp_grammar
- instantiate_cpp_literalgrs
- instantiate_defined_grammar
- instantiate_predef_macros
- instantiate_re2c_lexer
- instantiate_re2c_lexer_str
- cpplexer/re2clex/aq
- cpplexer/re2clex/cpp_re
- ;
-
-lib boost_wave
- :
- $(SOURCES).cpp
- /boost/filesystem//boost_filesystem
- :
- msvc-7.1:off # workaround for compiler bug
- # Not supported by V2
- # cpp_re.cpp
- ;
-
-install dist-lib
- :
- boost_wave
- :
- LIB
- ../../../dist/lib
- ;
-
-explicit dist-lib ;
diff --git a/doc/acknowledgements.html b/doc/acknowledgements.html
deleted file mode 100644
index 466d6ac..0000000
--- a/doc/acknowledgements.html
+++ /dev/null
@@ -1,91 +0,0 @@
-
-
-
-Acknowledgements
-
-
-
-
-
-
-
-
Acknowledgements
-
-
-
-
-
-
-
-
-
-
-
-
-
Special thanks to:
-
-
Paul Mensonides for his invaluable help while developing the macro
- expansion engine and his insightful tips. He developed the recursive macro
- expansion algorithm implemented herein and also contributed most of the small
- testcases used for testing the correctness of the macro expansion.
-
Dan Nuffer, who wrote the initial Re2C based C++ lexer and the Slex
- (Spirit Lex) scanner generator sample.
-
Martin Wille for helping with the port to Linux, testing on Linux and for contributing
- the automated test scripts.
-
Vladimir Prus for helping with the command line and config file options
- analysis for the Wave driver executable.
-
Juan Carlos Arevalo-Baeza, who wrote the Spirit cpp_lexer sample,
- from which are taken some ideas.
-
Andrei Alexandrescu for allowing to use his flex_string class,
-a policy based std::basic_string<> compatible string implementation.
-
Reece Dunn, Vesa Karvonen, Faisal Vali, Porter Schermerhorn and Daniel Fontijne for
- reporting several problems and bugs.
-
Tarmo Pikaro for reporting several bug while compiling specific
- headers from the Microsoft Windows SDK.
-
Rob Stewart helped a lot with proof reading the documentation.
-
Stefan Seefeld for integrating Wave into his Synopsis library and finding a couple of bugs along the way.
-
-
and last but not least
-
-
Joel de Guzman for nudging me into this adventure and for his work
- on the Spirit parser framework, without which the Wave library
- wouldn't have been possible.
-
-
Special thanks also to people who gave feedback and valuable comments, particularly members of Boost and Spirit mailing lists. This includes all those who participated in the Boost review:
-
-
Tom Brinkman (who volunteered to be the review managaer), David Abrahams, Beman Dewes, Reece Dunn, Larry Evans, Doug Gregor, Joel de Guzman, Baptiste Lepilleur, Andy Little, Paul Mensonides, Dan Nuffer, Andreas Pokorny, Vladimir Prus, Gennadiy Rozental, Michiel Salters, Jonathan Turkanis, Chris Uzdavinis, Pavel Vozenilek, Michael Walter
-
-
The Wave library uses the following Boost[8]
- libraries:
-
-
Boost
- Spirit (LL parser framework that represents parsers directly as EBNF grammars
- in inlined C++)
- Boost
- Iterator Adaptor Library (Adapt a base type into a standard conforming iterator)
- Boost
- Filesystem Library (Portable paths, iteration over directories, and other
- useful filesystem operations)
- Boost Program
- options and arguments library
-
-
and other small parts of different Boost libraries.
The boost::wave::context<> object is the main user visible object of
- the Wave library. It exists to generate the pair of iterators, which
- while dereferenced return the preprocessed tokens. Additionally it is used
- to control other aspects of the preprocessing, such as
-
-
include
- search paths, which define, where to search for files to be included with
- #include <...> and #include "..." directives
- which
- macros to predefine and which of the predefined macros to undefine
- several
- other options as for instance to control, whether to enable several extensions
- to the C++ Standard (as for instance variadics and placemarkers) or not.
The boost::wave::context object has three template parameters to specify
- the concrete behaviour of its operation. The following table describes these
- with more detail.
-
-
-
Template parameters required for the
- boost::wave::context class
-
-
-
Iterator
-
The type of the underlying iterator,
- through which the input stream is accessed.
- This should be at least an forward_iterator type iterator.
-
-
-
LexIterator
-
The type of the lexer type to be used by the Wave
- library to identify tokens in the input stream.
-
-
-
InputPolicy
-
The type of the input policy class, which allows
- to customize the behaviour of the Wave library and the type of the iterators
- to use, when it comes to including and opening an included file.
-
-
-
TracePolicy
-
The type of the trace policy class, which allows
- to customize the trace output generated while expanding macros.
-
-
-
For further information about the lexer type to use, please refer to the The
- Lexer Interface .
-
If the template parameter InputPolicy is omitted, the template wave::iteration_context_policies::load_file_to_string
- is used. For further information about the input policy, please refer to the
- topic The Input Policy.
-
If the template parameter TracePolicyT is omitted, the wave::macro_trace_policies::no_tracing
- policy type is used, i.e. by default there is no tracing performed. For further
- information about the tracing policy, please refer to the topic The
- Tracing Policy.
-
Public Typedefs
-
The boost::wave::context template defines the following public typedefs, which may be useful while using this class:
-
-
-
Public typedef's defined by the boost::wave::context class
-
-
-
iterator_type
-
The Iterator template parameter provided, while the context class was instantiated.
-
-
-
lex_type
-
The LexIterator template parameter provided, while the context class was instantiated.
-
-
-
token_type
-
The token type, which is returned by the context generated iterators. This type is taken from the LexIterator template parameter provided, whicle the context class was instantiated.
-
-
-
input_policy_type
-
The InputPolicy template parameter provided, while the context class was instantiated.
-
-
-
trace_policy_type
-
The TracePolicy template parameter provided, while the context class was instantiated.
-
-
-
position_type
-
The type of the position information contained in every returned token, which describes the point, at which the given token was recognised.
Constructs a context object on top of the input stream given by the pair
- of auxilliary iterators [first, last). The iterators should
- be at least forward_iterator type iterators. The filename parameter
- is to be supplied for informational purposes only. This string is used for
- indicating the token positions inside the input stream, it is not validated
- against the file system. If the filename parameter is not given it defaults
- to "<Unknown>". If the trace
- parameter isn't supplied it defaults to a default constructed TracePolicy
- object.
-
Additionally the macro symbol table is filled with the predefined macros
- and the current reference directory is set to the path of the given filename.
- If this filename does not reference valid file system item, the current reference
- directory is set to the current system directory. (The current reference directory
- is the file system path, which is used as the target directory during the
- processing of #include "..." directives).
-
Iterator interface
-
The pair of iterators returned by the context::begin and context::end
- functions is the main interface for accessing the preprocessed tokens from the
- preprocessor engine. While iterating over the given iterator range [begin, end)
- there are returned the preprocessed C++ tokens, which are generated on the fly
- from the underlying input stream. The returned iterators are conceptually of
- forward_iterator type.
-
begin
-
iterator_type begin();
-
-
Initializes and returns the starting iterator for the preprocessed token
- stream.
-
-
-
end
-
iterator_type end() const;
-
-
Initializes and returns the end of stream iterator to compare with for detecting
- the end of the preprocessed token stream.
-
-
Maintain include paths
-
The Wave library maintains two separate search paths for include
- files. A search path for user include files and a search path for system include
- files. Any directories specified with the add_include_path()
- function before the function set_sysinclude_delimiter()
- is called are searched only for the case of #include "..."
- directives, they are not searched for #include <file> directives.
- I.e. these directories are added to the user include search path.
-
If additional directories are specified with the add_include_path()
- function after a call to the function set_sysinclude_delimiter(),
- these directories are searched for all #include directives. I.e. these
- directories are added to the system include search path.
-
In addition, a call to the function set_sysinclude_delimiter()
- inhibits the use of the current reference directory as the first search directory
- for #include "..." directives. Therefore, the current
- reference directory is searched only, if it is requested explicitly with a call
- to the function add_include_path(".").
-
-
Callig both functions, the set_sysinclude_delimiter()
- and add_include_path(".") allows you
- to control precisely, which directories are searched before the current one
- and which are searched after.
-
These functions are modelled after the command line behaviour implemented by
- the popular gcc compiler.
-
-
add_include_path
-
bool add_include_path(char const *path);
-
-
-
Adds the given file system path to the user include search paths. After a
- call to the set_sysinclude_delimiter()
- this function adds the given file system path to the system include search
- paths. Note though, that the given path is validated against the file system.
-
-
If the given path string does not form a name of a valid file system directory
- item, the function returns false. If the given path was successfully
- added to the include search paths in question, the function returns true.
-
-
add_sysinclude_path
-
bool add_sysinclude_path(char const *path);
-
-
Adds the given file system path to the system include search paths. This
- function operates on the system include search path regardless of the mode
- of operation of the add_include_path(). Note
- though, that the given path is validated against the file system.
-
If the given path string does not form a name of a valid file system directory
- item, the function returns false. If the given path was successfully
- added to the system include search paths, the function returns true.
-
-
set_sysinclude_delimiter
-
void set_sysinclude_delimiter();
-
-
Switches the mode, how the add_include_path()
- function operates. By default the given file system path is added to the user
- include search paths. After calling this function a subsequent call to the
- add_include_path() adds the given file system
- path to the system include search paths. Additionally it inhibits the the
- use of the current reference directory as the first search directory for #include "..."
- directives.
-
-
get_iteration_depth
-
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 context, before the main (topmost)
- iteration context is reached.
Adds a new macro definition to the macro symbol table. The parameter macrostring
- should contain the macro to define in the command line format, i.e. something
- like MACRO(x)=definition. The following table describes this format
- in more detail. The parameter is_predefined should be true while
- defining predefined macros, i.e. macros, which are not undefinable with an
- #undef directive from inside the preprocessed input stream. If this
- parameter is not given, it defaults to false.
-
-
-
Summary of possible formats for defining
- macros
-
-
-
MACRO
-
define MACRO as 1
-
-
-
MACRO=
-
define MACRO as nothing (empty)
-
-
-
MACRO=definition
-
define MACRO as definition
-
-
-
MACRO(x)
-
define MACRO(x) as 1
-
-
-
MACRO(x)=
-
define MACRO(x) as nothing (empty)
-
-
-
MACRO(x)=definition
-
define MACRO(x) as definition
-
-
-
The function returns false, if the macro to define already was defined
- and the new definition is equivalent to the existing one, it returns true,
- if the new macro was successfully added to the macro symbol table.
-
If the given macro definition resembles a redefinition and the new macro
- is not identical to the already defined macro (in the sense defined by the
- C++ Standard), the function throws a corresponding preprocess_exception.
Removes the definition of the macro with the given name from the
- macro symbol table. This operation is equivalent to an #undef directive
- with this name executed from within the input stream. If the parameter
- even_predefined is true, then the macro is removed from
- the macro symbol table even, if it is defined as a predefined macro.
-
Note though, that the following macros are not undefinable in any
- case: __FILE__, __LINE__, __DATE__, __TIME__,
- __cplusplus, __STDC__. If the parameter even_predefined
- is not given, it defaults to false.
-
The function returns false, if the macro to undefine was not defined
- and returns true otherwise.
-
If the macro to remove may not be undefined (it is a predefined macro and
- the parameter even_predefined is set to false or it is one
- of the mentioned not undefinable macros above) the function throws a preprocess_exception.
-
-
reset_macro_definitions
-
void reset_macro_definitions();
-
-
Resets the macro symbol table to it's initial state, i.e. undefines all user defined macros and inserts the internal predefined macros as described here.
-
-
Get Version information
-
get_version
-
static std::string get_version();
-
-
Returns a string containing the current Wave version formatted as 0xvvrsbbbb
- (this is a string representation of the equivalent hexadecimal number), where
- 'vv' is the version number, 'r'
- the release number, 's' the subrelease number
- and 'bbbb' the build number. A possible return
- value looks like 0x00910454. The returned value
- is the same as is inserted in the preprocessed token stream, when the predefined
- macro __WAVE_VERSION__ is expanded.
-
-
get_version_str
-
static std::string get_version_str();
-
-
Returns a string containing the current Wave version formatted as "v.rr.ss.bbbb",
- where 'v' is the version number, 'rr'
- the release number, 'ss' the subrelease number
- and 'bbbb' the build number. A possible return
- value looks like "0.9.1.454". The returned
- value is the same as is inserted in the preprocessed token stream, when the
- predefined macro __WAVE_VERSION_STR__ is expanded.
This functions allows to specify the language mode, in which the Wave
- library should work. The possible language modes are defined by the enumerated
- type language_support:
-
enum language_support {
- // support flags for C++98
- support_normal = 0x01,
- support_cpp = support_normal,
-
- // support flags for C99
- support_long_long = 0x02,
- support_variadics = 0x04,
- support_c99 = support_variadics |
- support_long_long | 0x08,
-
- // the mask for the main language settings
- support_option_mask = 0xFF00,
- // additional fine tuning of the general behaviour
- support_option_preserve_comments = 0x0100, support_option_no_character_validation = 0x0200, support_option_convert_trigraphs = 0x0400 };
-
When used with support_variadics the support for variadics, placemarkers
- and the operator _Pragma() is enabled in normal C++ mode. When used with the support_long_long the support for long long suffixes is enabled in C++ mode.
-
The support_c99 switches to the C99 language support, which enables variadics, placemarkers, the operator _Pragma and long long suffixes by default. Additionally it disables the C++ specific tokens such as '->*', '.*', '::' etc.
-
The support_option_... values are to be used in conjunction with the main language settings (support_normal and support_c99) .
-
-
If the support_option_preserve_comments flag is set, the Wave library preserves almost all comments in the source code. The only comments not preserved are those contained inside macro definitions. By default all comments are replaced by a single space.
-
If the support_option_no_character_validation flag is set , the Wave library doesn't validate universal character literals (given in the form of 'u1234' or 'U12345678') to be in the allowed value range. This flag is merely used for internal purposes by the testing framework and will be rarely used by a user of the library.
-
If the support_option_convert_trigraphs flag is set, the Wave library replaces all occurences of trigraph characters with their non-trigraph character sequence (i.e. '??=' is replaced by '#' etc.) . By default no replacement is performed.
-
-
-
Note: The set_language function internally resets the list of defined macros, so please be careful not to call it after you have defined your own macros already.
-
set_max_include_nesting_depth
- g et_max_include_nesting_depth
This functions allow to set or to get the maximal possible include file nesting
- depth supported by the Wave library. The initial value for this is
- determined by the preprocessing constant WAVE_MAX_INCLUDE_LEVEL_DEPTH
- (see here).
The function expanding_function_like_macro is called, whenever a
- function-like macro is to be expanded, i.e. before the actual expansion
- starts.
-
The macroname parameter marks the position where the macro to expand
- is defined. It contains the token which identifies the macro name used inside
- the corresponding macro definition.
-
The formal_args parameter holds the formal arguments used during
- the definition of the macro.
-
The definition parameter holds the macro definition for the macro
- to trace. This is a standard STL container which holds the token sequence
- identified during the macro definition as the macro replacement list.
-
The macrocall parameter marks the position where this macro is invoked.
- It contains the token, which identifies the macro call inside the preprocessed
- input stream.
-
The arguments parameter holds the macro arguments used during the
- invocation of the macro. This is a vector of standard STL containers which
- contain the token sequences identified at the position of the macro call as
- the arguments to be used during the macro expansion.
The function expanding_object_like_macro is called, whenever a object-like
- macro is to be expanded, i.e. before the actual expansion starts.
-
The macroname parameter marks the position where the macro to expand
- is defined. It contains the token which identifies the macro name used inside
- the corresponding macro definition.
-
The definition parameter holds the macro definition for the macro
- to trace. This is a standard STL container which holds the token sequence
- identified during the macro definition as the macro replacement list.
-
The macrocall parameter marks the position where this macro is invoked.
- It contains the token which identifies the macro call inside the preprocessed
- input stream.
The function expanded_macro is called whenever the expansion of
- a macro is finished, the replacement list is completely scanned and the identified
- macros herein are replaced by its corresponding expansion results, but before
- the rescanning process starts.
-
The parameter result contains the the result of the macro expansion
- so far. This is a standard STL container containing the generated token sequence.
The function rescanned_macro is called whenever the rescanning
- of a macro is finished, i.e. the macro expansion is complete.
-
The parameter result contains the the result of the whole macro
- expansion. This is a standard STL container containing the generated token
- sequence.
The function found_include_directive is called whenever whenever a #include directive was located..
-
The parameter filename contains the (expanded) file name found after
- the #include directive. This has the format <file>, "file" or
- file.
- The formats <file> or "file" are used for #include directives found
- in the preprocessed token stream, the format file is used for files
- specified through the --force_include command line argument.
-
The parameter include_next is set to true if the found directive was
- a #include_next directive and the BOOST_WAVE_SUPPORT_INCLUDE_NEXT preprocessing constant was defined to something != 0.
-
The function opened_include_file is called whenever a file referred
- by an #include directive was successfully located and opened.
-
The parameter rel_filename contains the (normalised) probably relative file system path of the opened file. The concrete format of this file name depends on the format of the include search path given to the library beforehand.
-
The parameter abs_filename contains the (normalised) full file system path of the
- opened file.
-
The include_depth parameter contains the current include file depth.
-
-
The is_system_include parameter denotes, if the given file was found
- as a result of a #include <...> directive.
-
-
returning_from_include_file
-
void returning_from_include_file();
-
-
-
The function returning_from_include_file is called whenever an
- included file is about to be closed after it's processing is complete.
The function interpret_pragma is called whenever an unrecognized
- #pragma wave ... or operator _Pragma("wave ...")
- is found in the input stream.
-
The ctx parameter provides a reference to the context_type used during instantiation of the preprocessing iterators by the user.
-
The pending parameter may be used to push tokens back into the input
- stream which are to be used as the replacement text for the whole #pragma wave()
- directive. If this sequence is left empty, no replacement takes place, i.e.
- the interpreted directive is removed from the generated token stream.
-
The option parameter contains the name of the interpreted pragma.
-
The values parameter holds the value of the parameter provided to
- the pragma operator.
-
The pragma_token parameter contains the actual #pragma token which
- may be used for extraction of the location information for some error output.
-
If the return value is 'false', the whole #pragma directive is interpreted
- as unknown and a corresponding error message is issued. A return value of
- 'true' signs a successful interpretation of the given #pragma.
-
The function defined_macro is called whenever a macro was defined successfully.
-
The parameter name is a reference to the token holding the macro name.
-
The parameter is_functionlike is set to true whenever the newly
- defined macro is defined as a function like macro.
-
The parameter parameters holds the parameter tokens for the macro
- definition. If the macro has no parameters or if it is a object like
- macro, then this container is empty.
-
The parameter definition contains the token sequence given as the
- replacement sequence (definition part) of the newly defined macro.
-
The parameter is_predefined is set to true for all macros predefined
- during the initialisation pahase of the library.
-
The file position template is used to represent a concrete token position inside
- the underlying input stream. This token position contains the corresponding
- filename, the line number and the column number, where the token was recognized.
The file_position template used by the default token type has to be instantiated with one template parameter,
- which gives the string type to use for storing the file name member of the file
- position. If this parameter isn't given, it defaults to a std::string.
- Please note, that the type given as the template parameter must be compatible
- with a std::string.
-
You may use your own position types if appropriate, but in any case these should implement the same interface as the file_position template described here.
The constructors initialize a new instance of a file_position in
- correspondence to the supplied parameters. The parameters default to an empty
- filename and the line number and column number set to one.
The get_... functions are used to access the current values of the
- file position members: the filename (get_file), the line number (get_line)
- and the column number (get_column).
The set_... functions are used to set new values to the file position
- members: the filename (set_file), the line number (set_line)
- and the column number (set_column).
The input policy type may be specified as a template parameter to the wave::context
- object and is used for customizing the way, how an included file is to be represented
- by a pair of iterators pointing to the beginning and the end of the resulting
- input sequence. If this template parameter is not given while instantiating
- the context object, it defaults to the iteration_context_policies::load_file_to_string
- type.
The following code listing does not show the required interface only, but for
- brevity reasons the whole implementation of an input policy, which loads the
- given file into a string variable and exposes the begin() and end() iterators
- of this string to the Wave library.
As you can see, an input_policy for the wave::context object
- should implement one function only, the init_iterators function. The policy
- shown is implemented with the help of an embedded class to avoid the need for
- template template parameters, which aren't implemented by all systems today.
- This embedded class should have the name inner.
-
Template Parameters
-
The inner class is instantiated with one template parameter, the iteration
- context type, from which the policy is a part of. The iterator type iterator_type
- 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.
directive was found in the input token stream. The main rationale for this
- function is to initialize the pair of iterators iter_ctx.first and
- iter_ctx.last, which are to be used to access the input stream corresponding
- to the include file to be inserted from inside the preprocessing engine.
Every lexer, which should be used in conjunction with the Wave library, has to return tokens formed from the input stream. These tokens should conform to the synopsis described in the topic The Token Type. The lexer type should expose an interface which conforms at least to a forward_iterator (in the sense defined by the the C++ Standard) returning the token type. The code sample below does not show the definition of this forward iterator interface because this is highly implementation defined.
Please note, that the lex_iterator defined in the library header wave/cpplexer/cpp_lexer_interface.hpp actually is a template class taking the token type to use as its template parameter. This is omitted in the synopsis above because it is an implementation detail of the Re2C lexer provided as part of the Wave library.
-
If you want to use Wave in conjunction with your own lexing component this will have to conform to the interface described above only.
-
Public Typedefs
-
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
-
-
-
token_type
-
The token type returned by the lexer. This is type is used as the return value of the main iterators provided by the boost::wave::context object too.
-
-
-
Member functions
-
Besides the functions, which should be provided for forward_iterators as mandated by the C++ Standard, every lexer must implement the following functions to be used with the Wave library:
-
constructor
-
lex_iterator();
-
-
The default constructor should construct a lexer iterator, which may be used as the end iterator of the provided iterator range.
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 token type in Wave is the main carrier of information. It is returned
- 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
- 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
- library.
-
You can use arbitrary token types in conjunction with your own lexer as long
- as these implement some required interface. The required token type interface
- is described below and is implemented by the wave::cpplexer::lex_token
- template, the required lexer interface is described here.
-
-
In the following is described the token type predefined inside the Wave
- library, which is used in conjunction with the two predefined C++ lexers contained
- in the Wave library too. If you need to use your own token type, it
- is required to implement the interafce described below.
The predefined token type uses a template parameter Position, which
- allows to specify the type to be used to carry the file position information
- contained inside the generated tokens. Your own token type do not need to take this Position template parameter, but please note, that the token type in any case needs to have an embedded type definition position_type (see below) .
-
Public Typedefs
-
The token type needs to define two embedded types: string_type and position_type. The string_type needs to be a type compatible to the std::basic_string<> class.
-
This type should contain at least the filename, the line number and the column number of the position, where the token was recognized. For the predefined token type it defaults to a simple file_position template class described here. Note, that your own position_type should follow the interface described for the file_position template as well.
The first (default) constructor is for generating an end of stream token,
- which is used for indicating the end of the underlying input stream.
-
The second constructor initializes the newly created token object with its
- token id (for a list of valid token id's please look here),
- the string representation of its value and the file position, describing the
- position inside the input stream , where this token was recognized.
-
-
Accessor functions
-
operator token_id
-
operator token_id() const;
-
-
Allows the access to the token id of the token. This access Sunday, May 15, 2005 12:23operation of Spirit
- parsers directly on top
-
-
- top of a token stream. The possible token id's are described
-
- here.
-
This function does not throw in any case.
-
-
get_value
-
string_type const &get_value() const;
-
-
Returns the value of the token, as it was recognized in the input stream.
- Even for constant tokens (as keywords or operators etc.) the returned value
- reflects the character sequence as found in the input stream.
-
This function does not throw in any case.
-
-
get_position
-
Position const &get_position() const;
-
-
Returns the position of the token in the input stream, where it was recognized.
- The position contains information about the filename, the line number and
- the column number of the token. By default the Wave library uses
- a file_position template for this purpose, which is described in more detail
- here.
-
This function does not throw in any case.
-
-
set_token_id
-
void set_token_id(token_id id);
-
-
Changes the token id of the token to the new value. The possible token id's
- are described here. Probably this function is
- of little value for the library user, but it is required under certain circumstances
- for correct operation of the preprocessing engine.
-
This function does not throw in any case.
-
-
set_value
-
void set_value(string_type const &newval);
-
-
Changes the value stored inside the token to the new value. Propably this
- function is of little value for the library user, but it is required under
- certain circumstances for correct operation of the preprocessing engine.
-
-
set_position
-
void set_position(Position const &newpos);
-
-
Changes the position stored inside the token to the new value. This is used
- for instance for implementing the functionality required for to implement
- the #line directive.
The C++ preprocessor iterator library may be configured at compile
- time by specifying different preprocessor constants to include different additional
- features. The possible preprocessor constants are described in the following
- table.
-
-
-
Summary of possible preprocessor constants
- for
- library configuration
-
-
-
BOOST_WAVE_SUPPORT_WARNING_DIRECTIVE
-
Support the #warning directive
-
-
-
BOOST_WAVE_SUPPORT_MS_EXTENSIONS
-
Support several MS specific language
- extensions (i.e. __int8 et.al.)
-
-
-
BOOST_WAVE_PREPROCESS_ERROR_MESSAGE_BODY
-
Enable the preprocessing of the message bodies
- of #error and #warning
- directives.
-
-
-
BOOST_WAVE_RETURN_PRAGMA_DIRECTIVES
-
If defined, then the #pragma
- directives are returned as a token sequence to the caller, if not defined,
- the whole #pragma directive is skipped.
-
-
-
BOOST_WAVE_PREPROCESS_PRAGMA_BODY
-
Enable the preprocessing of the bodies of
- #pragma directives.
- Note though, that the body of an operator _Pragma() is preprocessed
- always, as required by the C99 Standard [2].
-
-
-
-
BOOST_WAVE_ENABLE_COMMANDLINE_MACROS
-
Enable the functionality required to define macros
- with the command line syntax (-DMACRO(x)=definition)
-
-
-
BOOST_WAVE_STRINGTYPE
-
The tokens generated by the Wave library
- contain the token data and the file position, where this token was found
- in the input stream.
- This constant may be used to redefine the data type, which is used to
- hold the token data and the corresponding file name. If this isn't defined
- it defaults to std::string. (The here defined data type should be compatible
- to the std::string type)
-
-
-
BOOST_WAVE_SUPPORT_VARIADICS_PLACEMARKERS
-
If defined, then the preprocessor library supports
- variadics and placemarkers. Note, to support C99 mode, this constant must
- be defined too.
-
-
-
BOOST_WAVE_MAX_INCLUDE_LEVEL_DEPTH
-
If defined, it will determine the initial maximal
- possible include file nesting depth supported. It defaults to 1024.
-
-
-
BOOST_WAVE_SUPPORT_PRAGMA_ONCE
-
If defined, then the #pragma once directive is supported by Wave. This specifies that the file, in which the pragma resides, will be included
- (opened) only once by the compiler in a build.
-
-
-
BOOST_WAVE_SUPPORT_INCLUDE_NEXT
-
If defined, then the #include_next directive is supported by Wave. This is syntactically equivalent to the #include directives, but may be used to inherit a header file (i.e. to include a file, which is named as the current file containing the #include_next).
-
-
-
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.
-
To show, how this may be done, the Wave library contains several samples illustrating this possibility. 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
-
The Wave C++ preprocessor iterator library is build almost
- completely as a header only library (except for the re2c based lexer). If you're
- trying to include all required files at once you will mention, that the resulting
- compilation times are very large (up to an hour - depending on your system configuration).
- This straightforward method we'll call the inclusion compilation model. If you
- do not pay attention to compilation times, that's the way to go, no special
- handling is needed.
-
If you're interested in decreasing compilation times, the following
- method is to be used. This we will call it the separation compilation model.
- The trick is to separate the different objects such, that they are compilable
- separately. The function, which instantiates the templated object in question
- is factored out such, that its definition is visible to only one translation
- unit. To simplify this further this creation function is packaged into a small
- generator template structure.
-
There are two levels of separation implemented: the separation of
- 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
- shows these constants in detail.
-
-
-
Summary of possible compilation constants
- required
- to enable the separation compilation model
-
-
-
Separate
-
Preprocessor
- constant
-
-
-
C++ lexer
-
BOOST_WAVE_SEPARATE_LEXER_INSTANTIATION
-
-
-
Spirit grammars
-
BOOST_WAVE_SEPARATE_GRAMMAR_INSTANTIATION
-
-
-
The following table shows the explicit template instantiations required,
- if you want to use the separation compilation model. The TokenT placeholder
- type has to be replaced with your token type to use and the LexIteratorT placeholder type has to be replaced with your lex iterator type you've used while instantiation of the boost::wave::context<> object. You will achieve the best
- results, if you place these into separate compilation units each. The IteratorT
- placeholder should be replaced by the iterator type, which was used to instantiate
- the boost::wave::context<> object.
-
-
-
Summary of required explicit template
- instantiations
- required when using the separation compilation model
To see an example of this you can look at the Wave driver program
- 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
- times required to build the Wave example are dropped by up to 90%.
The Wave C++ preprocessor library is a Standards conformant
- implementation of the mandated C99/C++ preprocessor functionality packed behind
- a simple to use interface, which integrates well with the well known idioms
- of the Standard Template Library (STL).
-
The Wave C++ preprocessor is not a monolitic application,
- it's rather a modular library, which exposes mainly a context object and an
- iterator interface. The context object helps to configure the actual preprocessing
- process (as search path's, predefined macros, etc.). The exposed iterators are
- generated by this context object too. Iterating over the sequence defined by
- the two iterators will return the preprocessed tokens, which are to be built
- on the fly from the given input stream.
-
The C++ preprocessor iterator itself is fed by a C++ lexer iterator,
- which implements an abstract interface. The C++ lexers packaged with the
- Wave library may be used standalone, too, and are not tied to the C++
- preprocessor iterator at all.
-
To make the C++ preprocessing library modular, the C++ lexer is held
- completely separate and independent from the preprocessor. To prove this concept,
- two different, but functionally identical C++ lexers were
-implemented. Additionally there is implemented a IDL lexer, which allows to use the preprocessor library as the lexing component of a IDL oriented tool. All these lexers implement the mentioned abstract interface,
- so that the C++ preprocessor iterator may be used with all of them. The abstraction
- of the lexer from the preprocessor iterator library was done to allow
- plugging in different lexers without the need to reimplement the preprocessor.
- This will allow for benchmarking and specific fine tuning of the process of preprocessing
- itself.
-
The first of these C++ lexers is implemented with the help of the
- well known Re2C[3] tool, which generates
- C code from given regular expressions. The lexers generated with Re2C
- are known to be very fast, because they are not table driven but directly code the token building logic
-(very similar to hand coded lexers).
-
-
The second of these C++ lexers is built around a table driven lexer,
- where the DFA tables (discrete finite automaton tables) are generated from regular expressions with the help of
- a Spirit-based lexer generating framework named Slex[5].
- The Slex is fed during runtime with the token definitions (regular
- expressions) and generates the resulting DFA table. This table is used to combine
- the input characters into corresponding lexemes (tokens). The generated DFA table
- can be saved to disk to avoid the generation process at program startup.
-
Wave may be used for preprocessing IDL files too, since the token set needed for the IDL language is very similar to the C++ token set. That's the reason, why the Wave preprocessor library contains also an IDL lexer. The IDL lexer is also based on the Re2C tool, but recognizes a different set of tokens. So this lexer does not recognize any keywords (except true and false, which are needed by the preprocessor itself). This is needed because there exist different IDL language flavours, where identifiers of one flavour may be keywords of others - Ok, this requires postponement of keyword identification until after the
-preprocessing, but allows to use Wave for all of the IDL derivatives.
-
It is possible to build other C++ lexers if needed. Currently there
- are plans to adapt the Spirit C++ lexer example cpplexer[6],
- which is completely based on static Spirit[4]
- grammars.
-
Both of the included lexers and the library itself are able
- to act in a C99 compliant mode. In this mode the lexers reject C++-only tokens
- ('::', '->*', '.*' and the alternate keywords
- such as 'and', etc.). The preprocessor additionally handles placemarkers
- (empty macro arguments) and variadics (macros with variable parameter counts).
- As an extension to the C++ Standard, the library can be enabled to handle placemarkers
- and variadics in C++ mode too.
The macro expansion process described here was initially developed by Paul
- Mensonides and is implemented in Wave. It is much more understandable
- as the description of the desired macro expansion algorithm provided in the
- C++ Standard [1].
-
Macro replacement proceeds left-to-right.
-
If, during scanning (or rescanning) an identifier is found, it is looked up
- in the symbol table. If the identifier is not found in the symbol table, it
- is not a macro and scanning continues.
-
If the identifier is found, the value of a flag associated with the identifier
- is used to determine if the identifier is available for expansion. If it is
- not, the specific token (i.e. the specific instance of the identifier) is marked
- as disabled and is not expanded. If the identifier is available for expansion,
- the value of a different flag associated with the identifier in the symbol table
- is used to determine if the identifier is an object-like or function-like macro.
- If it is an object-like macro, it is expanded. If it is a function-like macro,
- it is only expanded if the next token is an left parenthesis.
- An identifier is available for expansion if it is not marked as disabled and
- if the the value of the flag associated with the identifier is not set, which
- is used to determine if the identifier is available for expansion.
-
(If a macro is an object-like macro, skip past the next two paragraphs.)
-
If a macro to be expanded is a function-like macro, it must have the exact
- number of actual arguments as the number of formal parameters required by the
- definition of the macro. Each argument is recursively scanned and expanded.
- Each parameter name found in the replacement list is replaced by the expanded
- actual argument after leading and trailing whitespace and all placeholder tokens
- are removed unless the parameter name immediately follows the stringizing operator
- ('#') or is adjacent to the token-pasting operator ('##').
-
If the parameter name immediately follows the stringizing operator ('#'),
- a stringized version of the unexpanded actual argument is inserted. If the parameter
- name is adjacent to the token-pasting operator ('##'), the unexpanded
- actual argument is inserted after all placeholder tokens are removed.
-
All concatenation takes place in the replacement list. (If a single concatenation
- yields multiple tokens, the behavior is undefined. Moreover, Wave in
- normal C++98 and C99 modes issues an error, if more then one token is produced
- as the result of the concatenation. In C++0x mode Wave treats token-pasting
- of unrelated tokens as well defined and inserts the reparsed string representation
- of the concatenated tokens into the replacement list.).
-
The flag in the symbol table entry associated with the name of the macro being
- expanded is set to indicate the that the macro is not available for expansion.
-
The replacement list is rescanned for further macro expansion. All leading
- and trailing whitespace tokens in the replacement list are removed (the placeholder
- tokens are left intact).
-
After rescanning completes, the flag in the symbol table entry associated with
- the name of macro being expanded is cleared to indicate that the macro is again
- available for expansion, and the sequence of tokens that constitutes the rescanned
- replacement list is returned to the point of invocation of the macro.
-
If this sequence of tokens is empty, it is replaced by a placeholder token.
- If a placeholder is found during scanning (or rescanning) it is ignored. (Also,
- if the only thing separating a parameter from the stringizing operator or token-pasting
- operator is placeholder, it is also ignored in that context.)
-
This sequence of tokens is inserted at the original point that the macro was
- invoked, and scanning continues starting with the last token of the newly inserted
- sequence of tokens. I.e. scanning looks back a single token (possibly a placeholder
- token) and continues.
-
The following table lists the macros, which are predefined by the
- Wave library. Some of these (all except the __LINE__,
- __FILE__, __BASE_FILE__, __DATE__,
- __TIME__, __STDC__, __INCLUDE_LEVEL__
- and __cplusplus macros) may be undefined from the command line of the driver executable
- (see the -U option) or through the function remove_macro_definition().
-
-
-
Summary of predefined macros
-
-
-
Name
-
Value
-
Undefinable
-
-
-
__STDC__
-
1 (a decimal constant)
-
yes
-
-
-
__cplusplus
-
199711L (a decimal constant), this
- is defined in C++ mode only (C99 mode is off)
- In the C++0x mode this decimal constant is guaranteed to be larger than
- 199711L (the concrete value is to be defined by the C++ committee).
-
no
-
-
-
__LINE__
-
The line number of the current source line (a decimal
- constant)
-
no
-
-
-
__FILE__
-
The presumed name of the source file (a character string literal)
-
no
-
-
-
__BASE_FILE__
-
This macro expands to the name of the main input file (a character string literal). This is the source file that was specified during construction of the wave::context template.
-
no
-
-
-
__DATE__
-
The date of translation of the source file (a character
- string literal of the form
- "Mmm dd yyyy", where the names of the months are the same as
- those generated by the asctime function, and the first character of dd
- is a space character if the value is less than 10).
-
no
-
-
-
__TIME__
-
The time of translation of the source file (a character
- string literal of the form "hh:mm:ss"
- as in the time generated by the asctime function).
-
no
-
-
-
__INCLUDE_LEVEL__
-
A decimal integer constant that represents the
- depth of nesting in include
- files. The value of this macro is incremented on every #include
- directive
- and decremented at every end of file.
-
no
-
-
-
__WAVE__ __SPIRIT_PP__
-
The version of the driver program (a hexadecinal
- constant of the form 0xMmrr, where 'M' is
- the major version number, 'm' the minor version
- number and 'rr' the release number).
-
yes
-
-
-
__WAVE_VERSION__ __SPIRIT_PP_VERSION__
-
The full version number of the driver program (a
- hexadecimal constant of the form 0xMmrrbbbb, where 'M'
- is the major version number, 'm' the minor
- version number, 'rr' the release number and
- 'bbbb' the build number).
-
yes
-
-
-
__WAVE_VERSION_STR__ __SPIRIT_PP_VERSION_STR__
-
The full version number of the driver program (a
- character string literal of the form "M.m.rr.bbbb",
- where 'M' is the major version number, 'm'
- the minor version number, 'rr' the release
- number and 'bbbb' the build number).
-
yes
-
-
-
__STDC_VERSION__
-
199901L (a decimal constant), this is defined in C99 mode only
-
yes
-
-
-
__STDC_HOSTED__
-
0L (a decimal constant), this is defined in C99 mode only
-
yes
-
-
-
__WAVE_HAS_VARIADICS__
-
1 (a decimal constant), this is defined in C++
- mode only if variadics and placemarkers are enabled, and it is defined
- in the C99 mode
During the last time many new features were developed as additions to the Spirit
- [4] parser construction framework and we
- felt more and more, that it would be very helpful, to have a 'real world' example,
- which could be used as a sandbox for testing the usability of certain features.
- Additionally a recent discussion on the Boost mailing list showed the widespread
- interest of developers to have a modern, open source C++ preprocessor library
- to play with. So we had the idea to implement a C++ preprocessor to fit
- this needs - Wave was born.
-
The Wave C++ preprocessor library uses the
- Spirit[4] parser construction
- library to implement a C++ lexer with ISO/ANSI Standards conformant preprocessing
- capabilities. It exposes an iterator interface, which returns the current preprocessed
- token from the input stream. This preprocessed token is generated on the fly
- while iterating over the preprocessor iterator sequence (in the terminology
- of the STL these iterators are forward iterators).
-
The C++ preprocessor is a macro processor that under normal
- circumstances is used automatically by your C++ compiler to transform your program
- before actual compilation. It is called a macro processor because it allows
- you to define macros, which are brief abbreviations for longer constructs. The
- C++ preprocessor provides four separate facilities that you can use as you see
- fit:
-
-
Inclusion
- of header files
- Macro
- expansion
- Conditional
- compilation
- Line
- control
-
-
These features are greatly underestimated today, even more, the preprocessor
- has been frowned on for so long that its usage just hasn't been effectively
- pushed until the Boost preprocessor library [7]
- came into being a few years ago. Only today we begin to understand, that preprocessor
- generative metaprogramming combined with template metaprogramming in C++ is
- by far one of the most powerful compile-time reflection/metaprogramming facilities
- that any language has ever supported.
-
The C++ Standard [2] was adopted back in 1998, but there is still no (known to me) C++ compiler, which has a bugfree implementation of the rather simple preprocessor requirements mandated therein. This may be a result of the mentioned underestimation or even banning of the preprocessor from good programming style during the last few years or may stem from the somewhat awkward standardese dialect of English used to describe it.
-
So the main goals for the Wave project are:
-
-
full
- conformance with the C++ standard (ISO/IEC 14882:1998) [1]
- and with the C99 standard (INCITS/ISO/IEC 9899:1999) [2]
- usage of Spirit[4]
- for the parsing parts of the game (certainly :-)
- maximal usage
- of STL and/or Boost libraries (for compactness and maintainability)
- straightforward
- extendability for the implementation of additional features
- building a
- flexible library for different C++ lexing and preprocessing needs
-
-
At the first steps it is not planned to make a very high performance or very
- small C++ preprocessor. If you are looking for these objectives you probably
- have to look at other places. Although our C++ preprocessor iterator works as expected and is usable as a reference 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
- dilates linearly under Wave, which causes it to easily outperform EDG based
-preprocessors when complexity increases.
-
As tests showed, the Wave library is very conformant to the C++ Standard,
- such that it compiles several strict conformant macro definitions, which are
- not even compilable with EDG based preprocessors (i.e. Comeau or Intel). The only preprocessor known to have similar Standards conformance
-today is the preprocessor of the gcc C/C++ compiler.
Preprocessing with Wave is highly configurable. You must
-define a few options to control it. Here are a few of the
-options you can define:
-
-
include
- search paths, which define, where to search for files to be included with
- #include <...> and #include "..." directives
- which
- macros to predefine and which of the predefined macros to undefine
- whether to enable any of several extensions to the C++
-Standard (such as for variadics and placemarkers)
-
-
-
You can access all these processing parameters through the boost::wave::context
- object. So you must instantiate one object of this type to use the Wave
- library. (For more information about the context template class, please refer
- to the class reference here.) To instantiate
- the boost::wave::context object you have to supply at least two template parameters:
- the iterator type of the underlying input stream to use and the type of the lexer iterator to be used as the token source for the preprocessing engine.
-
Do not instantiate the main preprocessing iterators yourself.
-Get them from the wave::context object instead.
-The following code snippet is taken from the quick_start sample, which shows a minimal usage scenario for Wave.
-
// The following preprocesses a given input file.
- // Open the file and read it into a string variable
- std::ifstream instream("input.cpp");
- std::string input(
- std::istreambuf_iterator<char>(instream.rdbuf()),
- std::istreambuf_iterator<char>());
-
- // The template boost::wave::cpplexer::lex_token<> is the
- // token type to be used by the Wave library.
- // This token type is one of the central types throughout
- // the library, because it is a template parameter to some
- // of the public classes and templates and it is returned
- // 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
- // with the token type.
- typedefboost::wave::cpplexer::lex_iterator<
- boost::wave::cpplexer::lex_token<> >
- lex_iterator_type;
- typedefboost::wave::context<
- std::string::iterator, lex_iterator_type>
- context_type;
-
- context_type ctx(input.begin(), input.end(), "input.cpp");
-
- // At this point you may want to set the parameters of the
- // preprocessing as include paths and/or predefined macros.
- ctx.add_include_path("...");
- ctx.add_macro_definition(...);
-
- // Get the preprocessor iterators and use them to generate
- // the token sequence.
- context_type::iterator_type first = ctx.begin();
- context_type::iterator_type last = ctx.end();
-
- // The input stream is preprocessed for you during iteration // over [first, last) while (first != last) {
- std::cout << (*first).get_value();
- ++first;
- }
-
-
-
The constructor of the boost::wave::context object can
- take a pair of arbitrary iterator types (at least input_iterator type
- iterators) to the input stream, which must supply the data to be processed.
- The third parameter supplies a filename, filename, which is reported in the preprocessor output to
-indicate the current context.
-Note though, that this filename is used
- only as long as no #include or #line directives are encountered,
- which in turn will alter the current filename reported.
-
The iteration over the preprocessed tokens is relativley straightforward. Just get the starting and the ending iterators from the context object
- (maybe after initializing some include search paths) and you are done! Dereferencing
- the iterator will return the preprocessed tokens, which are generated on
- the fly from the input stream. (To get further information about the token type,
- you may want to look here.)
Last updated:
- Saturday, February 12, 2005 10:07
-
-
-
-Sunday, May 15, 2005 12:23
\ No newline at end of file
diff --git a/doc/samples.html b/doc/samples.html
deleted file mode 100644
index 91a7920..0000000
--- a/doc/samples.html
+++ /dev/null
@@ -1,96 +0,0 @@
-
-
-
-Samples
-
-
-
-
-
-
-
-
-
-
Samples
-
-
-
-
-
-
-
-
-
-
-
-
-
The Wave library contains several samples illustrating how to use the different features. This section describes these samples and its main characteristics.
-
The quick_start sample
-
The quick_start sample shows a minimal way to use the Wave preprocessor library. It simply opens the file given as the first command line argument, preprocesses it assuming that there aren't any additional include paths or macros defined and outputs the textual representation of the tokens generated from the given input file. This sample may be used to introduce yourself to Wave, because it does not contain all the potential additional complexity exposed by more complex samples.
-
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 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
-
The list_includes sample
-
The list_includes sample shows how the Wave library may be used to generate a include file dependency list for a particular input file. It completely depends on the default library configuration. The command line syntax for this sample is given below:
-
Usage: list_includes [options] file ...:
- -h [ --help ] : print out program usage (this message)
- -v [ --version ] : print the version number
- -I [ --path ] dir : specify additional include directory
- -S [ --syspath ] dir : specify additional system include directory
-
-
Please note though, that this sample will output only those include file names, which are visible to the preprocessor, i.e. given the following code snippet, only one of the two include file directives is triggered during preprocessing and for this reason only the corresponding file name is reported by the list_includes sample:
-
Because of its general usefulness the wave sample is not located in the sample directory of the library, but inside the tools directory of Boost. The wave sample is usable as a full fledged preprocessor executable
- on top of any other C++ compiler. It outputs the textual representation of the
-preprocessed tokens generated from a given input file. It is described in more details here.
-
The waveidl sample
-
The main point of the waveidl sample is to show, how a completely independent lexer type may be used in conjunction with the default token type of the Wave library. The lexer used in this sample is supposed to be used for an IDL language based preprocessor. It is based on the Re2C tool too, but recognizes a different set of tokens as the default C++ lexer contained within the Wave library. So this lexer does not recognize any keywords (except true and false, which are needed by the preprocessor itself). This is needed because there exist different IDL languages, where identifiers of one language may be keywords of others. Certainly this implies to postpone keyword identification after the preprocessing, but allows to use Wave for all of the IDL derivatives.
-
It is only possible to use the Wave library to write an IDL preprocessor, because the token sets for both languages are very similar. The tokens to be recognized by the waveidl IDL language preprocessor is nearly a complete subset of the full C++ token set.
-
The command line syntax usable for this sample is shown below:
-
Usage: waveidl [options] [@config-file(s)] file:
-
-
- Options allowed on the command line only:
- -h [ --help ] : print out program usage (this message)
- -v [ --version ] : print the version number
- -c [ --copyright ] : print out the copyright statement
- --config-file filepath : specify a config file (alternatively: @filepath)
-
-
- Options allowed additionally in a config file:
- -o [ --output ] path : specify a file to use for output instead of stdout
- -I [ --include ] path : specify an additional include directory
- -S [ --sysinclude ] syspath : specify an additional system include directory
- -D [ --define ] macro[=[value]] : specify a macro to define
- -P [ --predefine ] macro[=[value]] : specify a macro to predefine
- -U [ --undefine ] macro : specify a macro to undefine
-
The Wave preprocessor library supports a couple of specific #pragma
- directives, which may be used to control some of the library features. All directives
- described here are usable as conventional #pragma directives and as
- operator _Pragma (if variadics are enabled). So for instance the
- following directives are functionally identical:
-
#pragma wave trace(enable)
-
and
-
_Pragma("wave trace(enable)")
-
All Wave specific pragma's must have the general form 'wave option[(value)]',
- where 'wave' is the specific keyword, '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 context_policies are call, so that the user of the library is responsible for
-
-
-
Supported pragma's
-
-
-
pragma option
-
pragma value
-
description
-
supported by
-
-
-
trace
-
enable/on/1
- disable/off/0
-
Enable or disable the tracing of the
- macro expansion process. This is needed, even if there is given the --trace
- command line option, because the trace output is generated only, if there
- is at least one trace(enable) pragma found.
-
Wave driver
-
-
-
stop
-
message
-
Stop the execution of Wave and print out
- the given message. This is very helpful for direct debugging purposes.
-
Wave driver
-
-
-
-
system
-
command
-
Try to spawn the 'command' as a new operating system
- command and intercept the generated stdout and stderr. The stdout output
- of this command (if any) is retokenized and used as the replacement text
- for the whole pragma, the stderr output is ignored. The command is considered
- to be successful, if/when the return value is zero, otherwise an error
- is reported.
-
-
Wave driver
-
-
-
timer
-
restart/0
- <no value>
- suspend
- resume
-
The value restart set the current elapsed
- time to 0 and restarts the timer.
- If no value is provided, the current elpsed time is printed to the std::cerr
- stream.
- The values suspend and resume allow to temporarily stop
- the timing.
-
Wave driver
-
-
-
All pragma's not listed here but flagged as 'wave' are reported as
- errors. The handling of all remaining pragma's depends on the compilation constant
- 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
- the pragma itself is evaluated. The #pragma variant is subject to preprocessing
- only, if the WAVE_PREPROCESS_PRAGMA_BODY compilation constant
- was specified during compilation. For more information about the possible compilation
- constants look here.
-
Additionally the Wave preprocessor supports the #pragma once directive,
- which specifies that the file, in which the pragma resides, will be included
- (opened) only once by the compiler in a build. This may be used to optimize
- the preprocessing of larger compilation units, which include a lot of files. Note though, that the #pragma once directive is supported only, if the compile time constant WAVE_SUPPORT_PRAGMA_ONCE was given during compilation of the library.
-
It is fairly easy to implement your own #pragma wave ... directives. All you have to do is to implement your own interpret_pragma function (see here) which should the handle additional directives. For an example of how to do it, you may have a look at the Wave driver application, which implements the #pragma wave timer() directive with the help of a supplied interpret_pragma function.
The following tables contain all those tokens, which should be recognized by
- a C++ lexer, which is to be used in conjunction with the Wave preprocessing
- engine. The tokens are grouped into categories to simplify some internal logic
- and eventually the driver programs. The token identifiers are defined as an
- enum, and it is recommended to reuse this definition for your own lexer
- implementations.
-
Note though, that the preprocessor engine does some token transformation, so
- that not all of the listet here token identifiers may occur inside tokens, returned
- from the preprocessing iterator.
-
-
-
-
List of literal token id's
-
-
-
Token identifier
-
Token category
-
Token value
-
-
-
T_CHARLIT
-
CharacterLiteralTokenType
-
'a', '\t', '\u0057'
-
-
-
T_FLOATLIT
-
FloatingLiteralTokenType
-
-1.23456e78
-
-
-
T_IDENTIFIER
-
IdentifierTokenType
-
C++ identifier
-
-
-
T_OCTALINT
-
IntegerLiteralTokenType
-
007
-
-
-
T_DECIMALINT
-
IntegerLiteralTokenType
-
10
-
-
-
-
T_HEXAINT
-
-
IntegerLiteralTokenType
-
0x1234
-
-
-
T_INTLIT
-
IntegerLiteralTokenType
-
T_OCTALINT, T_DECIMALINT or T_HEXAINT
-
-
-
-
T_LONGINTLIT
-
-
IntegerLiteralTokenType
-
0x1234LL
-
-
-
T_STRINGLIT
-
StringLiteralTokenType
-
"abc"
-
-
-
T_FALSE
-
BoolLiteralTokenType
-
false
-
-
-
T_TRUE
-
BoolLiteralTokenType
-
true
-
-
-
-
-
-
-
List of whitespace token id's
-
-
-
Token identifier
-
Token category
-
Token value
-
-
-
T_ANY
-
UnknownTokenType
-
any value not matched otherwise
-
-
-
T_CCOMMENT
-
WhiteSpaceTokenType
-
/* ... */
-
-
-
T_CPPCOMMENT
-
WhiteSpaceTokenType
-
// ... \n
-
-
-
T_SPACE
-
WhiteSpaceTokenType
-
blank or '\t'
-
-
-
T_SPACE2
-
WhiteSpaceTokenType
-
'\v' or '\f'
-
-
-
T_EOF
-
EOFTokenType
-
end of input
-
-
-
T_CONTLINE
-
EOLTokenType
-
'\\' followed by '\n'
-
-
-
T_NEWLINE
-
EOLTokenType
-
'\n'
-
-
-
-
-
-
-
-
List of keyword token id's
-
-
-
Token identifier
-
Token category
-
Token value
-
-
-
T_ASM
-
KeywordTokenType
-
asm
-
-
-
T_AUTO
-
KeywordTokenType
-
auto
-
-
-
T_BOOL
-
KeywordTokenType
-
bool
-
-
-
T_BREAK
-
KeywordTokenType
-
break
-
-
-
T_CASE
-
KeywordTokenType
-
case
-
-
-
T_CATCH
-
KeywordTokenType
-
catch
-
-
-
T_CHAR
-
KeywordTokenType
-
char
-
-
-
T_CLASS
-
KeywordTokenType
-
class
-
-
-
T_CONST
-
KeywordTokenType
-
const
-
-
-
T_CONSTCAST
-
KeywordTokenType
-
const_cast
-
-
-
T_CONTINUE
-
KeywordTokenType
-
continue
-
-
-
T_DEFAULT
-
KeywordTokenType
-
default
-
-
-
T_DEFINED
-
KeywordTokenType
-
defined
-
-
-
T_DELETE
-
KeywordTokenType
-
delete
-
-
-
T_DO
-
KeywordTokenType
-
do
-
-
-
T_DOUBLE
-
KeywordTokenType
-
double
-
-
-
T_DYNAMICCAST
-
KeywordTokenType
-
dynamic_cast
-
-
-
T_ELSE
-
KeywordTokenType
-
else
-
-
-
T_ENUM
-
KeywordTokenType
-
enum
-
-
-
T_EXPLICIT
-
KeywordTokenType
-
explicit
-
-
-
T_EXPORT
-
KeywordTokenType
-
export
-
-
-
T_EXTERN
-
KeywordTokenType
-
extern
-
-
-
T_FLOAT
-
KeywordTokenType
-
float
-
-
-
T_FOR
-
KeywordTokenType
-
for
-
-
-
T_FRIEND
-
KeywordTokenType
-
friend
-
-
-
T_GOTO
-
KeywordTokenType
-
goto
-
-
-
T_IF
-
KeywordTokenType
-
if
-
-
-
T_INLINE
-
KeywordTokenType
-
inline
-
-
-
T_INT
-
KeywordTokenType
-
int
-
-
-
T_LONG
-
KeywordTokenType
-
long
-
-
-
T_MUTABLE
-
KeywordTokenType
-
mutable
-
-
-
T_NAMESPACE
-
KeywordTokenType
-
namespace
-
-
-
T_NEW
-
KeywordTokenType
-
new
-
-
-
T_OPERATOR
-
KeywordTokenType
-
operator
-
-
-
T_PRIVATE
-
KeywordTokenType
-
private
-
-
-
T_PROTECTED
-
KeywordTokenType
-
protected
-
-
-
T_PUBLIC
-
KeywordTokenType
-
public
-
-
-
T_REGISTER
-
KeywordTokenType
-
register
-
-
-
T_REINTERPRETCAST
-
KeywordTokenType
-
reinterpret_cast
-
-
-
T_RETURN
-
KeywordTokenType
-
return
-
-
-
T_SHORT
-
KeywordTokenType
-
short
-
-
-
T_SIGNED
-
KeywordTokenType
-
signed
-
-
-
T_SIZEOF
-
KeywordTokenType
-
sizeof
-
-
-
T_STATIC
-
KeywordTokenType
-
static
-
-
-
T_STATICCAST
-
KeywordTokenType
-
static_cast
-
-
-
T_STRUCT
-
KeywordTokenType
-
struct
-
-
-
T_SWITCH
-
KeywordTokenType
-
switch
-
-
-
T_TEMPLATE
-
KeywordTokenType
-
template
-
-
-
T_THIS
-
KeywordTokenType
-
this
-
-
-
T_THROW
-
KeywordTokenType
-
throw
-
-
-
T_TRY
-
KeywordTokenType
-
try
-
-
-
T_TYPEDEF
-
KeywordTokenType
-
typedef
-
-
-
T_TYPEID
-
KeywordTokenType
-
typeid
-
-
-
T_TYPENAME
-
KeywordTokenType
-
typename
-
-
-
T_UNION
-
KeywordTokenType
-
union
-
-
-
T_UNSIGNED
-
KeywordTokenType
-
unsigned
-
-
-
T_USING
-
KeywordTokenType
-
using
-
-
-
T_VIRTUAL
-
KeywordTokenType
-
virtual
-
-
-
T_VOID
-
KeywordTokenType
-
void
-
-
-
T_VOLATILE
-
KeywordTokenType
-
volatile
-
-
-
T_WCHART
-
KeywordTokenType
-
wchar_t
-
-
-
T_WHILE
-
KeywordTokenType
-
while
-
-
-
-
-
-
-
List of operator token id's
-
-
-
Token identifier
-
Token category
-
Token value
-
-
-
T_AND
-
OperatorTokenType
-
&
-
-
-
T_ANDAND
-
OperatorTokenType
-
&&
-
-
-
T_ASSIGN
-
OperatorTokenType
-
=
-
-
-
T_ANDASSIGN
-
OperatorTokenType
-
&=
-
-
-
T_OR
-
OperatorTokenType
-
|
-
-
-
T_ORASSIGN
-
OperatorTokenType
-
|=
-
-
-
T_XOR
-
OperatorTokenType
-
^
-
-
-
T_XORASSIGN
-
OperatorTokenType
-
^=
-
-
-
T_COMMA
-
OperatorTokenType
-
,
-
-
-
T_COLON
-
OperatorTokenType
-
:
-
-
-
T_DIVIDE
-
OperatorTokenType
-
/
-
-
-
T_DIVIDEASSIGN
-
OperatorTokenType
-
/=
-
-
-
T_DOT
-
OperatorTokenType
-
.
-
-
-
T_DOTSTAR
-
OperatorTokenType
-
.*
-
-
-
T_ELLIPSIS
-
OperatorTokenType
-
...
-
-
-
T_EQUAL
-
OperatorTokenType
-
==
-
-
-
T_GREATER
-
OperatorTokenType
-
>
-
-
-
T_GREATEREQUAL
-
OperatorTokenType
-
>=
-
-
-
T_LEFTBRACE
-
OperatorTokenType
-
{
-
-
-
T_LESS
-
OperatorTokenType
-
<
-
-
-
T_LESSEQUAL
-
OperatorTokenType
-
<=
-
-
-
T_LEFTPAREN
-
OperatorTokenType
-
(
-
-
-
T_LEFTBRACKET
-
OperatorTokenType
-
[
-
-
-
T_MINUS
-
OperatorTokenType
-
-
-
-
-
T_MINUSASSIGN
-
OperatorTokenType
-
-=
-
-
-
T_MINUSMINUS
-
OperatorTokenType
-
--
-
-
-
T_PERCENT
-
OperatorTokenType
-
%
-
-
-
T_PERCENTASSIGN
-
OperatorTokenType
-
%=
-
-
-
T_NOT
-
OperatorTokenType
-
!
-
-
-
T_NOTEQUAL
-
OperatorTokenType
-
!=
-
-
-
T_OROR
-
OperatorTokenType
-
||
-
-
-
T_PLUS
-
OperatorTokenType
-
+
-
-
-
T_PLUSASSIGN
-
OperatorTokenType
-
+=
-
-
-
T_PLUSPLUS
-
OperatorTokenType
-
++
-
-
-
T_ARROW
-
OperatorTokenType
-
->
-
-
-
T_ARROWSTAR
-
OperatorTokenType
-
->*
-
-
-
T_QUESTION_MARK
-
OperatorTokenType
-
?
-
-
-
T_RIGHTBRACE
-
OperatorTokenType
-
}
-
-
-
T_RIGHTPAREN
-
OperatorTokenType
-
)
-
-
-
T_RIGHTBRACKET
-
OperatorTokenType
-
]
-
-
-
T_COLON_COLON
-
OperatorTokenType
-
::
-
-
-
T_SEMICOLON
-
OperatorTokenType
-
;
-
-
-
T_SHIFTLEFT
-
OperatorTokenType
-
<<
-
-
-
T_SHIFTLEFTASSIGN
-
OperatorTokenType
-
<<=
-
-
-
T_SHIFTRIGHT
-
OperatorTokenType
-
>>
-
-
-
T_SHIFTRIGHTASSIGN
-
OperatorTokenType
-
>>=
-
-
-
T_STAR
-
OperatorTokenType
-
*
-
-
-
T_COMPL
-
OperatorTokenType
-
~
-
-
-
T_STARASSIGN
-
OperatorTokenType
-
*=
-
-
-
T_POUND_POUND
-
OperatorTokenType
-
##
-
-
-
T_POUND
-
OperatorTokenType
-
#
-
-
-
T_AND_ALT
-
OperatorTokenType | AltTokenType
-
bitand
-
-
-
T_ANDASSIGN_ALT
-
OperatorTokenType | AltTokenType
-
and_eq
-
-
-
T_OR_ALT
-
OperatorTokenType | AltTokenType
-
or
-
-
-
T_ORASSIGN_ALT
-
OperatorTokenType | AltTokenType
-
or_eq
-
-
-
T_XOR_ALT
-
OperatorTokenType | AltTokenType
-
xor
-
-
-
T_XORASSIGN_ALT
-
OperatorTokenType | AltTokenType
-
xor_eq
-
-
-
T_LEFTBRACE_ALT
-
OperatorTokenType | AltTokenType
-
<%
-
-
-
T_LEFTBRACKET_ALT
-
OperatorTokenType | AltTokenType
-
<:
-
-
-
T_NOT_ALT
-
OperatorTokenType | AltTokenType
-
not
-
-
-
T_NOTEQUAL_ALT
-
OperatorTokenType | AltTokenType
-
not_eq
-
-
-
T_RIGHTBRACE_ALT
-
OperatorTokenType | AltTokenType
-
%>
-
-
-
T_RIGHTBRACKET_ALT
-
OperatorTokenType | AltTokenType
-
:>
-
-
-
T_COMPL_ALT
-
OperatorTokenType | AltTokenType
-
compl
-
-
-
T_POUND_POUND_ALT
-
OperatorTokenType | AltTokenType
-
%:%:
-
-
-
T_POUND_ALT
-
OperatorTokenType | AltTokenType
-
%:
-
-
-
T_OR_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??!
-
-
-
T_XOR_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??'
-
-
-
T_LEFTBRACE_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??<
-
-
-
T_LEFTBRACKET_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??(
-
-
-
T_RIGHTBRACE_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??>
-
-
-
T_RIGHTBRACKET_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??)
-
-
-
T_COMPL_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??-
-
-
-
T_POUND_POUND_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??=??=
-
-
-
T_POUND_TRIGRAPH
-
OperatorTokenType | TriGraphTokenType
-
??=
-
-
-
- The preprocessor tokens listet in the following
- table are returned by the C++ lexer only. The preprocessor naturally acts on
- these tokens and they are not returned by dereferencing the preprocessing iterators.
If you ever had the need to debug a macro expansion you had to discover, that
- your tools provide only little or no support for this task. For this reason
- the Wave library got 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
- macro in question only. This may be done with the help of a special, Wave
- specific #pragma:
-
#pragma wave trace(enable) // enable the tracing
- // the macro expansions here will be traced
- // ...
- #pragma wave trace(disable) // disable the tracing
-
In C99 mode or when specifying the --variadics command line option
- you may additionally use the operator _Pragma() variant to enable/disable
- the tracing output:
-
#define CONCAT(x, y) \
- _Pragma("wave trace(enable)") \
- x \
- _Pragma("wave trace(disable)") \
- ## y
-
This way you have the possibility to enable the tracing during the expansion
- of a part of a macro only. In the sample shown there is traced the expansion
- of the macro argument 'x' only. Note, that the operator _Pragma()
- directives expand to nothing inside the macro expansion result.
-
To see, what the Wave driver generates while expanding a simple macro,
- let's have a look at the tracing output for the following example:
-
// test.cpp
- #define X(x) x #define Y() 2 #define CONCAT_(x, y) x ## y
- #define CONCAT(x, y) CONCAT_(x, y)
- #pragma wave trace(enable)
- // this macro expansion is to be traced
- CONCAT(X(1), Y()) // should expand to 12
- #pragma wave trace(disable)
-
When preprocessed with 'wave -t test.trace test.cpp' the Wave
- driver generates a file test.trace, which contains (without the line
- numbers in front of the lines):
The generated trace output is very verbose, but allows to follow every step
- of the actual macro expansion process. The first line in this tracing example
- contains the reference to the position, from where the macro expansion was initiated.
- Additionally the following information is contained for every single macro expansion:
-
-
The reference to the position, where the macro to expand was defined first
- (see lines 2, 9, 21 and 32).
-
The real parameters supplied for this macro expansion (see lines 3, 10 and
- 33), this information is traced inside the invoked with block, where
- 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
- 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
- in the replacement list, unless preceded by a # or ## preprocessing
- token or followed by a ## preprocessing token, is replaced by the
- corresponding argument after all macros contained therein have been expanded"
- [1]).
-
The result of the argument substitution (see lines 15, 23, 29 and 39), i.e.
- the substituted replacement list.
-
The rescanning process, which again includes the full subsequent macro expansion
- process of all found macros (see C++ Standard [16.3.4.1]: "After all
- parameters in the replacement list have been substituted, the resulting preprocessing
- token sequence is rescanned with all subsequent preprocessing tokens of the
- source file for more macro names to replace." [1]).
-
The result of the actual macro expansion (this is the last line inside the
- corresponding rescanning block - see lines 18, 26, 42 and 45).
-
-
Every found macro to expand will add an additional indentation level inside
- the trace output.
-
-
-
-Sunday, May 8, 2005 19:55Sunday, May 15, 2005 12:23
\ No newline at end of file
diff --git a/doc/wave_driver.html b/doc/wave_driver.html
deleted file mode 100644
index d094328..0000000
--- a/doc/wave_driver.html
+++ /dev/null
@@ -1,237 +0,0 @@
-
-
-
-The Wave Driver
-
-
-
-
-
-
-
-
-
The
- Wave Driver
-
-
-
-
-
-
-
-
-
-
-
-
-
There is implemented a driver program for the Wave library, which
- utilizes nearly all capabilities of the library. It is usable as a preprocessor executable
- on top of any other C++ compiler. It outputs the textual representation of the
- preprocessed tokens generated from a given input file. This driver program has
- the following command line syntax:
-
Usage: wave [options] [@config-file(s)] file:
-
- Options allowed on the command line only:
- -h [--help]: print out program usage (this message)
- -v [--version]: print the version number
- -c [--copyright]: print out the copyright statement
- --config-file filepath: specify a config file (alternatively: @filepath)
-
- Options allowed additionally in a config file:
- -o [--output] path: specify a file to use for output instead of stdout
- -I [--include] path: specify an additional include directory
- -S [--sysinclude] syspath: specify an additional system include directory
- -F [--forceinclude] file: force inclusion of the given file
- -D [--define] macro[=[value]]: specify a macro to define
- -P [--predefine] macro[=[value]]: specify a macro to predefine
- -U [--undefine] macro: specify a macro to undefine
- -u [--undefineall]: undefine all macrodefinitions
- -n [--nesting] depth: specify a new maximal include nesting depth
-
- Extended options (allowed everywhere)
- -t [--traceto] arg: output trace info to a file [arg] or to stderr [-]
- --timer output overall elapsed computing time
- --long_long: enable long long support if C++ mode
- --variadics: enable variadics and placemarkers in C++ mode
- --c99: enable C99 mode (implies variadics and placemarkers)
- -l [ --listincludes ] arg: list included file to a file [arg] or to stdout [-]
- -p [ --preserve ]: preserve comments
-
-
-
The possible options are straightforward and self explanatory. The
- following describes some of these options in more detail. Please note, that
- the extended options (--c99 and --variadics) are available only, if the driver
- was compiled with the constant WAVE_SUPPORT_VARIADICS_PLACEMARKERS
- defined.
-
-o [--output] path
-
-
Specify a filename to be used for the generated preprocessed output
- stream. If this option is not given, then the standard output is used (stdout).
-
-
-I [--include] option
-
-
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system
- header file, substituting your own version, since these directories are
- searched before the system header file directories. However, you should
- not use this option to add directories that contain vendor-supplied
- system header files (use '-S' for that). If you use more than
- one '-I' option, the directories are scanned in left-to-right order,
- the standard system directories come after.
-
If a standard system include directory, or a directory specified with
- '-S', is also specified with '-I', the '-I' option will be
- ignored. The directory will still be searched but as a system
- directory at its normal position in the system include chain.
-
-
-I- [--include-] option
-
-
The Wave library maintains two separate search paths
- for include files. A search path for user include files and a search path
- for system include files, where the user include paths are searched before the system include paths.
-
Any directories specified with '-I' options before
- an eventually given '-I-' option are searched only for the case of '#include "file"'
- (user include files), they are not searched for '#include <file>'
- directives (system include files). If additional directories are specified
- with '-I' options after a '-I-' option was given, these directories are searched
- for all '#include' directives (ordinarily all '-I' directories are used this way.).
-
In addition, the '-I-' option inhibits the
- use of the current directory (where the current input file came from) as the first search directory for '#include "file"'
- directives . With '-I.' you can specify searching the directory which was current when the compiler was invoked. That is not exactly the same as what the
- preprocessor does by default, but it is often satisfactory.
-
-
-S [--sysinclude] option
-
-
Add the given directory to the head of the list of directories
- to be searched for system header files. If you use more than one '-S' option,
- the directories are scanned in left-to-right order. This option is most useful
- in the wave.cfg configuration file to specify, where the system include files
- are to be searched.
-
-
-F [--forceinclude] option
-
-
Process the given file as normal input and include all the resulting
- output before the processing the regular input file starts. If more than one
- such option is given, the files are pre-included in the sequence of its occurance
- on the command line.
This option allows to define ('-D') or predefine ('-P') a macro
- from the command line. The string given in conjunction with the '-D' or '-P'
- option should conform to the usual syntax MACRO(x)=definition as is described
- in more detail here.
-
The only difference between the '-D' and the '-P' options is,
- that the latter predefines a macro such, that it is not undefinable
- through an #undef directive from inside the preprocessed program.
-
-
-U [--undefine] macro
-
-
This allows to undefine some of the automatically predefined macros
- of the Wave library (see Predefined macros). The only exception are
- the __LINE__, __FILE__,
- __DATE__, __TIME__,
- __STDC__ and __cplusplus
- predefined macros, which are not undefinable. If -U and -D are both specified
- for one name, the name is not predefined.
-
-
-n [--nesting] depth
-
-
Specify a new maximal include nesting depth. If the preprocessing
- reaches this include file nesting depth, it aborts the preprocessing after
- emitting an error message. The default include file nesting depth is 1024.
-
-
-t [--traceto] path
-
-
Enable the tracing facility build into the Wave library.
- The path specifies the filename to use for the output of the generated trace
- log. If the filename given equals to '-' (without the quotes), the
- trace log is put into the standard error stream (stderr).
-
-
--timer
-
-
Enable to track the overall elapsed computing time required for
- the given input file. The elapsed time is printed to stdout after the compilation
- is completed.
-
-
--variadics
-
-
Enables support for variadics (macros with variable parameter lists),
- placemarkers (empty macro arguments) and operator _Pragma in
- normal C++ mode. This option predefines a special predefined macro __WAVE_HAS_VARIADICS__.
-
-
--c99
-
-
Enable the C99 mode. This mode enables certain C99 specific features
- as variadics (macros with variable parameter lists), placemarkers (empty macro
- arguments) and operator _Pragma support and disables some C++
- specific token types as for instance '::', '->*' and '->.'.
- Several predefined macros are different for this mode, for more information
- about predefined macros you may look here.
-
-
-
-l [--listincludes] path
-
-
Enable the output of the names of all opened include files. The path specifies the filename to use for the output of the generated include log. If the filename given equals to '-' (without the quotes), the include log is put into the standard output stream (stdout).
-
-
-p [--preserve]
-
-
Preserve the comments from the input stream not located inside of macro definitions. The comments located inside macro definitions are skipped even if this option is specified. If this option is not specified on the command line all comments are skipped.
-
-
@ [--config-file] option
-
-
Some of the possible command line options may be specified inside
- of special configuration files. This is very useful, as a shorthand for different
- global configurations. A config file may contain additional options (-I, -S,
- -F, -U, -D and -P options), one option per line. Empty lines and lines beginning
- with a '#' character are ignored (are treated as a comment lines). Note that
- the '#' character is treated as the beginning of a comment only, if it is
- the first non-whitespace character on a line. Here is a small sample illustrating the supported configuration file syntax:
-
#
- # enable variadics et.al. in C++ mode
- #
- --variadics
- #
- # enable timer support
- #
- --timer
- #
- # emulate gcc V3.3.2
- #
- -D__GNUC__=3
- -D__GNUC_MINOR__=3
- -D__GNUC_PATCHLEVEL__=2
- -D__GNUG__
- #
- # add Boost to the system include search paths
- #
- -S/usr/local/boost
-
There is a shorthand for specifying a configuration file on the
- command line: simply use the '@' character immediatly before the corresponding
- file name.
-
The options found in a configuration file are interpreted, as
- if they were place instead of the configuration file option on the command
- line.
-
-
The Wave driver program looks at startup for a configuration
- file named 'wave.cfg' in the same directory, where it was started from (where
- is located the driver executable). If this file exists, it is treated as a normal
- configuration file and the specified herein options are interpreted as if they
- were given as the first options on the command line. This feature is very useful
- for defining a global environment for the Wave preprocessor driver.