[boost] Re: Formal Review: FOREACH macro

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-09 11:17:55

"Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote
>
>> "Andrei Alexandrescu (See Website For Email)"
> <SeeWebsiteForEmail_at_[hidden]> writes:
>> > 1. Start from the Boost implementation of the C++ preprocessor, and
>> > add sane features to it. Keep the old preprocessor features as
>> > deprecated.
>>
>> That one's a possibility.  I personally would not want to solve these
>> problems in the preprocessor layer because I want better integration
>> with the rest of the language than that approach can offer.  Others
>> may feel differently, of course.
>
> A better integration is not necessarily a good thing -- it's too
> restrictive.  Something like FOREACH, for example (let's pay a tribute to
> the subject of this discussion), would not be possible in a well-integrated
> system

Sure it would.

>  -- the piece of code it generates is not, by itself, a valid fragment
> of a C++ program.  

That doesn't matter.  One possible implementation would be (in a
made-up lisp-like language extension):

   [defmacro foreach [declaration *block] ...]

where a parameter called *whatever is expected to be a block of code
that syntactically follows the macro invocation.  Would you
(obviously) want to be able to do that?  for example:

   [defmacro lambda [decl-list *block] ...]

for 

   lambda(int x, int y) { whatever }

> So a totally independent code generation layer does have its
> advantages (at least it's more flexible).

That's true.  But for that kind of flexibility, we have the PP already
;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com