Re: [boost] [preprocessor] Sequences vs. All Other Data Structures

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 
language.

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 
translation....

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.

Regards,
Paul Mensonides