Boost logo

Boost :

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-04-13 19:48:34


> Attached is a document that I intend to give to Daveed Vandevoorde
> regarding several extensions to the preprocessor that would
> significantly help the field of preprocessor metaprogramming. If you
> are at all interested in Boost.Preprocessor or preprocessor
> metaprogramming--even template metaprogramming (as the two go hand in
> hand)--please read this paper.
>
> I need input regarding the paper itself and anything that should be
> added or subtracted from the paper. I'm also not really a writer, so
> any critique in this area is welcome as well.
>
> I need the support of as many people as possible with this proposal
> (to put at the end of the document), in order to prove the validity
> of preprocessor metaprogramming in a forum that is quite biased
> against the preprocessor.
>
> None of these extensions are without precedent or are major
> extensions--except a scoping mechanism, which I added because what
> I've seen of the current idea is fundamentally flawed.

I'm sure I'll have more comments, but, small comments for now:

1) Which "forum that is quite biased against the preprocessor" do
you mean? AFAICT, template metaprogramming has stressed the
resurgent need for the preprocessor. CPP use (or abuse :-) is no
longer "heretic" these days :)... I used to be a CPP "hater", but ....

2) region is not intuitive, I'm gravitating towards "module", along
with its friends "import" and "export".

3) "The second major problem is the use of #< and #> as
scoping directives. These directives are difficult to see in code
that contains many other directives, and this lack of visibility
would visibly complicate code."

--> Really? This is rather subjective, don't you think? While
I prefer the explicit #module module_name, I think you should
provide a convincing argument to substantiate your claim.

4) I tend to think that nested #modules are not necessary and
seems like an overkill. I wouldn't mind a flat, and simple #module
layout.

5) I wish to see how the proposal will have an impact with future
C++ features. OTOH, there's talk about abolishing the CPP and
replacing it with language mechanisms, continuing the inline
and const that replaced macros from old C. For instance, the
template book talks about variable template parameters. This
feature will lessen the need for the CPP. In an ideal world, I
would definitely want to program not in two languages,
just one: C++. However, I also tend to think that C++ is
already very heavy (and brittle?) that it would take a lot more
effort to extend it to support features which are possibly in the
domain of CPP.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk