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

Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-04-22 15:05:53

On 4/22/2012 5:45 AM, Paul Mensonides 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.

This is not completely true. Even though it would provide more work for 
a library implementor, a library could choose to use Boost Chaos for 
compilers that support it and choose to use Boost PP for compilers which 
do not ( including VC ).

In that case if Boost Chaos were better for preprocessor metaprogramming 
than Boost PP, as evidenced by Boost implementors using Boost Chaos 
instead of Boost PP, it would provide impetus for compiler vendors to 
make their preprocessor 100% C++11 compliant (and no, I do not expect 
VC++ to ever make an effort to be compliant but that is neither here nor 
there).

>  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).

Just my opinion but...

I think there should be a place in Boost for implementations which are 
aupported by a subset of compilers. I also see nothing wrong with a 
library which only supports compilers which implement some area of the 
standard and provides 0 workarounds for compilers which do not implement 
that area of the standard 100% correctly.