Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at