Boost logo

Boost :

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


   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

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