Re: Understanding MPL

From: Alisdair Meredith (yg-boost-users_at_[hidden])
Date: 2003-04-03 18:31:26

Paul Mensonides wrote:

> I wouldn't go so far as to say, "fairly detailed."  What we were discussing then
> was more along the lines of a categorical grouping of macros with an
> accompanied, "this group of macros is part of mechanism x which does y."  That,
> IMO, is not a "from-the-ground-up" tutorial on the pp-lib.  It is essentially
> just a better structured index.  The macros are already grouped by directories
> and headers--that structure is apparent in the index of headers.  What is
> lacking is a general, simplistic overview of each group of macros (for those
> that can be grouped).

>From my (quite recent) experience with the PP library:
The docs were adequate for what I needed, but I came to the library with
a specific task to solve, so I was happy to jump around and find the
topics I needed.  Perhaps a few fully worked examples of solving
real-world problems would help introduce some of the sections.

The end result is that I have a better idea of how a subset of the
library works (conditional compilation) and a better idea of how to use
it, but am still largely in the dark on the rest of the library, and
what sort of problems I should consider using it for.

The problem I faced was fairly simple - reinventing the TRACE macro.  We
want the facility to set a trace 'level' and depending on that level
traces are omitted.  Trace level can vary at run-time (to get a more
detailed log from a user experiencing a problem) but we can also set a
'minimum level' for the compiler to completely omit low-level traces
from release builds or enable particularly intense logging when
targetting particular debug builds.  And of course, minimum level can be
set on a per-file basis, and may be suitably defaulted.

Throw in a little intrusive profiling using the same scheme, and it was
natural to turn to something like PP library that has already
pre-packaged fixes around many of the problems I may meet, including
hacks for bugs in a given compiler.  Given my aversion to the
pre-processor till now that was important, as I would not recognise a
compiler bug as distict to my own!!

PP made this quite easy and approachable to someone who has religiously
avoided writing macros since starting with the language 7 years ago, so
I think that is proof the library delivers!  It definitely helps to have
a goal in mind though (but isn't that true of learning most any
programming topic?)

-- 
AlisdairM