RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005

From: Hartmut Kaiser (HartmutKaiser_at_[hidden])
Date: 2005-02-09 15:20:20

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