on Sun Apr 22 2012, Paul Mensonides <pmenso57-AT-comcast.net> wrote:
On Sun, 22 Apr 2012 07:51:11 +0000, Nathan Ridge wrote:
I don't see why one compiler's lack of standards-conformance should prevent a useful library from becoming part of Boost.
Because it is not just MSVC that's the problem, and I know what the tendency will be. This will work with compiler XYZ with *just* this little workaround.... Any workaround whatsoever in Chaos is absolutely unacceptable to me. It ruins the very point of the library.
The library could be proposed to Boost with the explicit understanding that it is intended to work only with fully standards-conforming preprocessors. In the long run its presence in Boost might even contribute to putting pressure on vendors of non-conformant preprocessors to get their act together.
I doubt the latter that would happen. Essentially, because Chaos cannot be used when targeting VC++, Boost cannot itself use it. Without Boost itself using it, the target audience is too small. Now, if Boost said "screw VC++" and used Chaos anyway, that *might* do it. However, it would break Boost on more compilers than just VC++, and then we'd more likely just get a Python 2.x vs 3.x instead (apologies, Dave, if I'm mis- characterizing the current Python state) except with Boost.
Now, IFF there is a place in Boost for a library like Chaos which currently contains no workarounds and henceforth must not contain workarounds, then I'd be willing.
As far as I'm concerned, there are two places: 1. As a zero-workaround sub-library of Boost.PP 2. After review and acceptance as a standalone library.
However, there is no current analog of that in Boost, nor any Boost policy addressing that type of requirement, nor any means of enforcement (even a would-be automated enforcement such as grepping for _MSC_VER (etc.) would work because even slightly rearranging code in a less than (theoretically) ideal way is still a workaround).
It does leave me wondering what you will do when you discover an ambiguity in the standard that two implementations interpret differently, but that's a bridge you can cross when you come to it. -- Dave Abrahams BoostPro Computing http://www.boostpro.com