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

Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-04-22 18:52:10

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