Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-16 13:04:11

----- Original Message -----
From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>

> Many of the recent changes cause compilation slowdown, because the new
> macros are not yet optimized, but this should change in the future.

I'm looking forward to that; unfortunately my programs already compile too

When we write these sophisticated metaprogramming libraries to make
programming easier in a given domain, we want to be able to give these
things to inexperienced users and handle all the nasty stuff
behind-the-scenes. Even if we go to great lengths to give users reasonable
error messages, if it takes them a long time to find out what's wrong with
their code, it impairs the usability of even the best libraries.

> >The problem here is not showing how something *can be* used, it is
> >what
> >types of things it *can be used for* in the scope of a larger system.
> >Building
> >blocks are pretty useless without a larger understanding of how to put
> >together to make something useful. In its own way, preprocessor
> >meta-programming is almost an entirely separate language and programming
> >paradigm, and that is hard to pin down with documentation.
> Preprocessor metaprogramming is very much like programming in a strict,
> purely functional programming language. This will be even more true once
> new techniques will be fully incorporated and the user doesn't have to
> so much attention to preprocessor limitations.

That'll be nice. However, I firmly believe that even tools modeling a
solid, reasonably well-known formalism like functional programming are
still tools. Usability is important, and part of that is being able to
approach the tool before you're fully comfortable with the formalism.

> In my opinion, the preprocessor library should support preprocessor
> metaprogramming. This support should be in the form of generic,
> macros that either:
> - enhance the preprocessing abilities of the preprocessor (e.g. CAT,
> - enhance the computational abilities of the preprocessor (by making it
> a complete programming language).

All good.

> The preprocessor library should not degenerate into a collection of
> case macros for special cases encountered by C++ programmers.

I think part of the reason that keeps getting suggested is that people want
a way to do an end-run around the learning curve. If you want to prevent
the wrong constructs from getting library-ized, you need to make sure it's
sufficiently easy for someone who "just wants to get a job done" to build
them by hand.

> Instead the
> preprocessor library should make it significantly easier to build
> application specific macros for the special cases needed by the
> developers.

Bingo! Most of the work that's currently needed to achieve that is in the
documentation, not the code.

> Of course, the library should and does offer some support for
> C++ language constructs.

Yep. And the most commonly needed special case constructs shouldn't have to
be re-invented by each user of the library.


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