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
> >types of things it *can be used for* in the scope of a larger system.
> >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,
> STRINGIZE, REPEAT), or
> - enhance the computational abilities of the preprocessor (by making it
> a complete programming language).
> 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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk