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. 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). Regards, Paul Mensonides