Boost logo

Boost :

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-02-09 16:24:37

"Hartmut Kaiser" wrote:

>> 1. Some parts may be separated:
>> - load_file_to_string in cpp_iteration_context.hpp
>> may be part of string_algos
> Could you elaborate?
Looking again - not really worth of troubles.

>> - 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?
Maybe as small, standalone utility in date-time.

>> 9. Wave driver Win32 execuable should be available in
>> Boost, version that doesn't need any external DLLs.
> 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.
Very good. I didn't notice (having it in tools/).

>> Maybe also "expand" pragma could be added, which simply
>> expands block of code, w/o explaining how.
> Could you elaborate, please?
When I want to check how preprocessed source looks like now
I do things like cl /E xyz.cpp and then search through multimegabyte file.

If I could have

#pragma wave expand
.. what is here gets expanded but the rest not
#pragma wave expand-end

This would help to avoid these huge files
when I am not interested in trace output.

>> 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.
Maybe docs could give some hints what is needed
to touch.

One possible feature: would it make sense to have macro as
__TU_FILE__ which always expands into the name
of "initially processed file"?

Say one may like to automatically register modules
where certain feature is used.

(No idea how this would play with precompiled headers.)


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