Pavel Vozenilek wrote:
I think Wave should become part of Boost.
Thanks!
1. Some parts may be separated:
- flex_string may be standalone library
(flex_string.hpp: the link to CUJ HTML page should be replaced to link to Andrei's website, CUJ is accessible to subscribers only).
This was discussed already on this list in conjunction with the dicussion about the const_string library. I don't know, what's the current status, but IIRC there were some people interested in putting together several different string implementations compatible with std::string et.el.
- load_file_to_string in cpp_iteration_context.hpp may be part of string_algos
Could you elaborate?
- transform_iterator.hpp
Transform_iterator _is_ part of boost already, the difference is, that wave uses a slightly different version (for performance reasons the version contained in Wave returns the transformed value by reference - I don't know, whether this is commonly possible - in Wave it is used to flatten a parse tree). That's the reason, why it is named ref_transform_iterator.
- time_conversion_helper.hpp (don't know where to put it but it would come very handy many times)
Hmmm... Where does this belong? Any ideas?
________________________________________________________ 2. The documentation may contain diagrams and/or tables identifying what parts of library belong to what module.
Good point. Noted.
________________________________________________________ 3. preface.html: sentence
"...is by far one of the most powerful compile-time reflection/metaprogramming facilities that any language has ever supported."
may be questioned by those using Lisp ;-)
Haha! No religious war please!
________________________________________________________ 4. Performance question: if I add non-existent path on a slow (e.g. network drive) will the path be always examined during parsing or will it be checked only once?
Also is there chance to cache files found on slow drives or keep cached file listing of these?
I ask because this is nasty problem with BCB preprocessor.
Never thought about this problem, so Wave doesn't try to optimise this yet. But I assume it should be possible to add such features. The preprocessor currently exposes some hooks, ie. functions called in certain situations, such as 'macro defined', 'macro expanded' etc. Possibly additional hooks should be added to allow to implement such a functionality outside of the library. This would keep Wave smaller and more focussed, OTOH it would allow to add those features where needed. I'll think about that.
________________________________________________________ 5. Is it possible to set language mode (C99, C++98) per individual file (or directory)?
Should be possible, but I'll have to investigate this further. Will report back on this later.
________________________________________________________ 6. Does the library deal with Microsoft's #region and #endregion?
No. But good point, it should be added (at least these should be ignored). The library already has the option to recognise MS specific tokens, such as __declspec etc. #region and #endregion fall into the same category.
________________________________________________________ 7. There should be example(s) with #pragma wave system in supported_pragmas.html.
(This feature may show _very_ useful, IMHO.)
Other pragmas may also have examples in docs.
Noted.
________________________________________________________ 8. Documentation should give example of often mentioned @config-file.
Ok.
________________________________________________________ 9. Wave driver Win32 execuable should be available in Boost, version that doesn't need any external DLLs.
Reasons: people using old compilers may like but may be unable/unwilling/scared to compile it. Having exe would made initial playing with the system less troubling.
That's one of the goals. As you may have noted, the wave driver already resides in the boost/tools directory and the Jamfiles are setup such, that all libraries are linked statically.
________________________________________________________ 10. Question: is the #pragma wave system executed before any follwing #includes are scanned?
Yes. It's executed at the point of its occurrence. That's needed, because the stdout stream contents of the executed command is inserted in place of the #pragma (but not rescanned for macros afterwards).
For example if I have:
#pragma wave system "generate xyz.h somehow" #include "xyz.h"
Should work. But as I've said above, you may output the anticipated contents of xyz.h directly to stdout (std::cout) and it will be intercepted by Wave as the replacement text for the overall #pragma directive.
May it be possible to pass somehow current header and end TU name into the "system" command?
The body of the #pragma is macro expanded before the command is executed. So it is possible to pass the __FILE__ pp constant as a command line parameter to the executed command: < file test.cpp> #pragma wave system(cmd /c echo __FILE__) </file test.cpp> will generate "test.cpp" as the output (on Windows; for linux et.al. you'll have to write /bin/echo). The name of the translation unit isn't available from inside the preprocessed stream, but may be added as a predefined 'macro' (such as __FILE__).
May it be possible to use something as #include CURRENT_FILE_NAME_BASE + ".generated_hpp"
That's explicitely allowed anyway (but not with the '+'). The #include directive may contain a macro, which should get expanded to a syntactically valid file name ("" or <> syntax) - see Standard 16.2.4 [cpp.inlcude].
________________________________________________________ 11. tracing_facility.html: some mess on line starting with "When preprocessed with ...".
Noted. My version of Dreamweaver inserts these messy things from time to time - *sigh*.
Maybe also "expand" pragma could be added, which simply expands block of code, w/o explaining how.
Could you elaborate, please?
________________________________________________________ 12. Wishes:
a. Check for digraphs/trigraphs. Maybe driver could have option that checks presence of digraphs and trighraphs and reports error when it found some.
It may be used e.g. to check computer generated random string tables.
This can be implemented by a special driver program which analyses the tokens returned by the preprocessor iterators. The trigraph tokens are flagged as such, so this should be possible already.
b. Sometimes it may be useful to be able to "partially preprocess" given source. E.g. I would like to have cleaner version of STLport just for my platform.
It would be nice if I could specify list of #defines and #undefines to be processed, the rest left as is.
Hmmm, that's more complex, I'll have to think about this.
c. Own preprocessor: say there's app used for many customers. Code is shipped to them. I do not want one customer see code related to others.
I would like to have something as my own private preprocessor:
@@ifdef CUSTOMER_X .... @@else .... @@endif
@@ifdef CUSTOMER_Y @@include "licensing_info_text" #include <...> ... @@endif
Could it be described how/whether it can be done with Wawe? Or maybe even sample.
By default Wave respects the standard directive syntax only (starting with a '#'). But you can implement this very easily by providing your own lexing component, which fakes the pp tokens (used internally for #include, #define etc.) when recognising the @@include, @@define etc. in the input stream. Thanks for your suggestions and reports! Regards Hartmut