Boost logo

Boost :

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-02-09 10:51:34

"Tom Brinkman" wrote:
> The Wave C++ preprocessor library review begins today...
I think Wave should become part of Boost.

I tool look on documentation and shortly at
its code. I don't use it now and didn't try to
compile the code.

Few notes are bellow.

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

- load_file_to_string in cpp_iteration_context.hpp
  may be part of string_algos

- transform_iterator.hpp

- time_conversion_helper.hpp (don't know where to put it
  but it would come very handy many times)

2. The documentation may contain diagrams and/or tables
   identifying what parts of library belong to what module.

3. preface.html: sentence

" 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 ;-)

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.

5. Is it possible to set language mode (C99, C++98)
   per individual file (or directory)?

6. Does the library deal with Microsoft's #region
   and #endregion?

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.

8. Documentation should give example of often
   mentioned @config-file.

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.

10. Question: is the #pragma wave system executed
    before any follwing #includes are scanned?

For example if I have:

#pragma wave system "generate xyz.h somehow"
#include "xyz.h"

May it be possible to pass somehow current header
and end TU name into the "system" command?

May it be possible to use something as
#include CURRENT_FILE_NAME_BASE + ".generated_hpp"

11. tracing_facility.html: some mess on line
   starting with "When preprocessed with ...".

Maybe also "expand" pragma could be added, which
simply expands block of code, w/o explaining how.

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.

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.

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

@@ifdef CUSTOMER_X

@@ifdef CUSTOMER_Y
@@include "licensing_info_text"
#include <...>

Could it be described how/whether it can be done
with Wawe? Or maybe even sample.


Boost list run by bdawes at, gregod at, cpdaniel at, john at