Re: [boost] PREPROCESSOR library updated

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-11-24 15:50:32

From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> Aleksey Gurtovoy wrote:

> 1) I think it's our current convention that the composite library header
> that includes everything from "boost/<library_name>" sub-directory should go
> into top-level "boost" include directory; given that,
> "boost/preprocessor/preprocessor.hpp" should become
> "boost/preprocessor.hpp".

Ok.

> 2) In the light of our a while-ago discussion of monolithic headers and
> compilation times :), I would prefer to see the
> "boost/preprocessor/arithmetic.hpp" and "boost/preprocessor/logic.hpp"
> headers made composite too (and comparison operations factored out into
> separate (and composite :) "boost/comparison.hpp" header), resulting in the
> following directory structure:
[...]
> Besides conforming to the basic engineering principles we all know about :),

Ok. I totally agree with this. I guess I was just lazy... :)

> 3) The first note in the Tutorial's BOOST_PREPROCESSOR_IF says: "THEN and
> ELSE don't have to be macros." However, if a least one of the
> BOOST_PREPROCESSOR_IF parameters is a function-like macro (see 16.3
> [cpp.replace] para 3), and you want it to be expanded _after_ the
> BOOST_PREPROCESSOR_IF macro replacement took place, you have to make a
> second parameter a function-like macro too.
[...]

Hmn... I'll add an explanation of this issue into the documentation.

> It would be nice for the library to provide an easier way
> to handle such (in my experience, quite often) situations. For example:
>
> #define BOOST_PREPROCESSOR_IDENTITY(x) \
>     x BOOST_PREPROCESSOR_EMPTY \
[...]
> Vesa, what do you think?

Hey, that looks very nice! Definitely worth putting into the library.

If you look at the tuple header, you'll find an ID()entity macro that is
basically used for ensuring the proper expansion of the tuple macros. I'll see
if it can be replaced with the above IDENTITY or perhaps rename the ID()entity
macro.

> 4) Bad news - Metrowerks Codewarrior 7.0 has a bug in preprocessor
[...]
> So, this is not a problem of the library, but probably something that needs
> to be mentioned in the documentation,

Ok, I'll look into this.

> Ok, I guess that's all that I wanted to comment on. Everything else in the
> library looks perfect to me, and I am really looking forward to finally see
> in CVS! Oh, and as far as I can see, most, if not all, of the formal review
> comments have been addressed. Great job, Vesa!

Thanks! I have a couple of hours time now, so I'll try to fix these issues
right away. Next week I really need to work on other projects, so I have very
limited time for Boost then.

-Vesa