Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2012-04-24 15:46:15
[Paul A. Bristow]
> But I haven't understood if there will be grief from existing macro code if the Microsoft fix it?
Probably (VC preprocesses billions of lines of code). But if I were a compiler dev, I'd deal with it with pragmas (superior to compiler options, because a header could push/pop requests for preprocessor conformance).
> Is there anything Boost can do to support Paul (and Steven) by sending a collective message to
> Microsoft, lest they dismiss this as one man's rant?
For this and other bugs, it is helpful to hear:
"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)
In the absence of such information, we try to figure out how severe a bug is, which factors into its priority (along with the cost of fixing it, available devs, etc.). Severity is usually pretty obvious: silent bad codegen is worse than rejects-valid, which is worse than accepts-invalid, etc. But sometimes a bug looks deceptively innocuous, which is where additional info can help.
For example, I filed DevDiv#166326 "N3276: decltype v1.1", about a subtle corner case in a new-to-VC10 feature. Ordinarily, that sounds like low priority. (EDG and GCC's lack of support for this at the time further decreased the priority.) But the info that (a) this is a huge obstacle to implementing result_of (for bonus points, argued by a WG21 paper), (b) Boost (i.e. Eric Niebler) really wants it, and (c) the STL really wants it too, pushed it "over the bar" and it got fixed. (Which later made me super happy as I was going through customer-reported STL issues and found that one was dependent on decltype v1.1.)
One note, though - commenting on *resolved* Connect bugs generally doesn't do any good. It's not obvious, but we aren't notified of Connect comments. Comments on active bugs will typically be looked at when the bug is resolved, but we have no reason to look at already-resolved bugs in our database (not even I have time for that, which is why I resolve Connect bugs with my E-mail address).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk