Hi Ovanes,

I have a file delived from some processor manufacturer which I can not change. In the file I have following defines, which wave can't parse:

#define UINT_MAX 4294967295U #define ULONG_MAX 1099511627775U

First error which happens during parsing of UINT_MAX is:

description: error: ill formed integer literal or integer constant too large: 4294967295U

I do not understand why I get the first error, since the value 4294967295U is 0xFFFFFFFF which is 32 bits long and should be fine (since it is also marked as unsigned for the preprocessor)...

This was a bug in Wave which is fixed now. Thanks for reporting!

Clearly the ULONG_MAX has a wrong numeric format (should be 1099511627775UL or 1099511627775ul), but unfortunately this file comes from some vendor and is deeply incorporated into the build process, so that it can not easily be changed. What do you think, could be the possible solution in this case?

Actually it should be 1099511627775ULL (at least on most 32 bit platforms), and even then the preprocessor is not required to recognize it, since the standard requires it to use long/unsigned long as the biggest internal representation of integer literals. To solve this I added the BOOST_WAVE_SUPPORT_LONGLONG_INTEGER_LITERALS compile time configuration constant to Wave, which enables the usage of boost::long_long_type/boost::ulong_long_type for the internal representation of integer literals (only available on platforms supporting these types, i.e. BOOST_HAS_LONG_LONG should be defined). If this is defined during compilaton of the library (not only your app!) then Wave uses the long long types for all integer literals, even if the suffix provided was only 'l' or 'ul' etc. Note, that this option may slow down preprocessing a bit because long long's may require some overhead if compared to long's. Since the option breaks standards conformance it will be disabled by default. But it's useful under certain circumstances (such as yours or when you have to emulate other platforms). The changes are committed to Boost::CVS head. Please note that in order to implement this correctly I had to fix a bug in Spirit as well, which is currently committed to the CVS::HEAD only (we'll try to get this into 1.34.1, but can't promise...).

My other question would be: Is there any change to allow the hooking interface to specify, which preprocessor directives should be expanded, an which not. Let me summarize:

I need some few macros to be expanded, which are defined in some 2-3 headers and I do not want wave to preprocess everything (huge source dir). Ideally, it would be great to have some functionality, which can notify the preprocessor whether to skip the preprocessing directive or not, e.g. function void found_include_directive(std::string const &filename, bool include_next); (as well as other functions like expanding_function_like_macro) from the default_preprocessing_hooks interface could additionaly return bool value, which would notify the preprocessor whether to include and expand the file/macro or not. May be in this second case I could solve the first problem as well, since I don't really need these defines, they are parsed as part of dependency, which is not required in my case.

This isn't implemented yet and requires a bit more effort to do so. Give me some time to think about this, ok? But there is another feature, which might be interesting for you in this context. The Wave driver tool has some #pragma's allowing to redirect or suppress the genereated output, which actually gives you some kind of partial preprocessing feature: #pragma wave option(output: "preprocessed/directory.hpp") Where the argument to the output option may be a "file name", null (no output), default (output as specified on the command line), or push/pop (with the obvious semantics). HTH Regards Hartmut

Ovanes,

I need some few macros to be expanded, which are defined in some 2-3 headers and I do not want wave to preprocess everything (huge source dir). Ideally, it would be great to have some functionality, which can notify the preprocessor whether to skip the preprocessing directive or not, e.g. function void found_include_directive(std::string const &filename, bool include_next); (as well as other functions like expanding_function_like_macro) from the default_preprocessing_hooks interface could additionaly return bool value, which would notify the preprocessor whether to include and expand the file/macro or not. May be in this second case I could solve the first problem as well, since I don't really need these defines, they are parsed as part of dependency, which is not required in my case.

The following preprocessing hooks now return a boolean value, which when returning 'true' cause the Wave library to skip the execution of the related preprocessing action: . found_directive: allows to skip the whole directive it is called for . expanding_object_like_macro: allows to skip expansion of the given object like macro, the macro symbol is copied to the output . expanding_function_like_macro: allows to skip the expansion of the given function like macro, the whole macro invocation (including all macro invocation parameters) are copied to the output without any further processing. Please note, that additionally I changed the interpretation of the return value of the found_include_directive() preprocessing hook: a return value of 'false' now processes the file to include normally and a return value of 'true' now skips the processing of the include file. The latter change was necessary to make the return values of the preprocessing hook consistent. Now return 'false' generally means: normal execution and return 'true' generally means: skip execution of the corresponding preprocessor action. HTH Regards Hartmut