On Wed, 25 Apr 2012 12:08:23 +0100, Paul A. Bristow wrote:
[mailto:boost-bounces@lists.boost.org] 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