Boost logo

Boost :

Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-04-25 08:01:07

On Wed, 25 Apr 2012 12:08:23 +0100, Paul A. Bristow wrote:

>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Stephan T. Lavavej

>> "I maintain Boost.Foobar"/"I maintain Product X, with Y users and Z
>> revenue" and "this bug is
> bad/really
>> bad/kitten-vaporizing" (ideally, quantify how many kittens are
>> vaporized)

> PS I wouldn't put this issue in that category, but I think it is much
> more important than it might seem.

In terms of direct user base, the issue is not that big. In terms of
indirect user base (i.e. user's of other libraries in Boost which use
Boost.Preprocessor), the issue is larger, but in that case, it's an issue
that mostly affects Boost authors. Given the skill level of the typical
Boost author (and the inclination to innovate), it's a shame when a great
deal of time is wasted applying workarounds for compiler issues. It
increases the complexity of everything, and, in some cases, actually
affects interface. Such workarounds need not be preprocessor-related,
and, on the whole, the preprocessor is *not* as important as the core

However, it is also not *nearly* as complex as the core language--and
therefore not nearly as difficult to do correctly. In fact, in the last
24 hours, I implemented a macro expansion algorithm that, AFAICT, works
flawlessly--even in all the corner cases. (Grain of salt... I haven't
tested it very well, however, and it doesn't have a lexer or parser
attached to it, so it is not a "preprocessor"--it just takes a sequence of
preprocessing tokens and a set of existing macro definitions, and does the
macro replacement therein.)

The point of the above is that it is simply not that hard to do it right
if you actually know what doing it right is and take the time to do it.
Of course, doing it right also implies obeying the phases of

I would have less of a problem with all of this if it was just about
prioritization of fixes of implemented features and addition of missing
features of the language. But that doesn't appear to be case. Instead,
other extra-linguistic (and more easily marketable) things appear to take
priority away from the language itself. Not that those are necessarily
the same dev teams, but there are integration issues, nonetheless. I have
an even larger problem with "won't fix because that's the way it so deal
with it." As it currently stands, I will not use cl nor will I make sure
code is portable to VC++. Do I want variadic templates? Absolutely, but
while I'm waiting I can emulate variadic templates for VC++ if I have a
decent preprocessor. In fact, the preprocessor is the fundamental means
of dealing with compiler deficiencies and system discrepancies.

Paul Mensonides

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