tim wrote:

in my experience compilers may provide the <atomic> header without fully implementing its content:

* some gcc versions only implement atomic<> for integral types, but not for structs

* libc++'s atomic<> for structs is broken if the struct has a constructor (showstopper for boost.lockfree)

That's not hard to address. We just need two macros, BOOST_NO_CXX11_ATOMIC_SCALARS and BOOST_NO_CXX11_ATOMIC_STRUCTS, unless of course you really meant integral types and pointers don't work, in which case it should be BOOST_NO_CXX11_ATOMIC_INTEGRALS, but I doubt it. (Scalars is not quite correct as well, because it includes floating point types and enums, which also may not work on some gcc versions, I don't know. Atomic floats or enums are rarely used in practice so it may be moot.)

Beman Dawes wrote:

We have run into a similar situation with compilers initially providing only partial implementations of language features. For example, Microsoft only supporting unconditional noexcept. The de facto policy has been to define the macro (BOOST_NO_CXX11_HDR_ATOMIC) until the feature is complete. Anyone who wants to take advantage of a partial implementation can test for the particular compiler or library version involved.

That's not very useful in this case, because many uses of <atomic> don't need atomic structs. atomic<integral> and atomic cover a lot of ground. shared_ptr, for example, only needs atomic_int_least32_t.

Rob Stewart wrote:

Add feature macros and test for them. The macros can be defined when the header is fully supported or for particular compilers.

If you're agreeing with Beman that BOOST_NO_CXX11_HDR_ATOMIC should not be defined when <atomic> is not 100% conforming, then I disagree. We do not have a practice of saying, via macros, that a header isn't present, and then saying, via other macros, that it actually is. BOOST_NO_CXX11_HDR_ATOMIC means that #include <atomic> would fail. Not defining it when the header is present but not useful, while a typical practice for us, is not the right thing to do when libraries disagree on whether the header is useful. When a header contains more than one feature, and some of them may be present while others may not be, we supply feature macros instead of a header macro. The lack of BOOST_NO_CXX11_ATOMIC_FEATURE means that #include <atomic> would work and provide $FEATURE.

Rob Stewart wrote:

You and Beman have now each stated the opposite.

No, we in fact have not.

Rob Stewart wrote:

On Dec 1, 2013, at 8:06 AM, "Peter Dimov" wrote:

...

Rob Stewart wrote:

...

Add feature macros and test for them. The macros can be defined when the header is fully supported or for particular compilers.

If you're agreeing with Beman that BOOST_NO_CXX11_HDR_ATOMIC should not be defined when <atomic> is not 100% conforming, then I disagree.

I replied, in another message, that Peter and Beman made opposite statements. Peter then claimed, in reply to me, that they did not disagree. I can't read the quote above any other way, so I'm confused.

Beman says that we often define a header macro which says that the header doesn't exist when the header exists, but is incomplete. This is correct. You then - apparently - suggested that we do that (pretend that the header doesn't exist), but in addition, supply other macros that signify that the header exists and provides some feature. I disagree that we should do that. (I say apparently because I wasn't sure that you did, hence my "if" qualifier above.) I think that in such a situation we should provide the feature macros, without a header macro. Any positive claim that a feature X exists and works implies the existence of the header. The header macro is - in this case - redundant.

On Dec 3, 2013, at 1:21 PM, "John Maddock" wrote:

...

Beman says that we often define a header macro which says that the header doesn't exist when the header exists, but is incomplete. This is correct.

You then - apparently - suggested that we do that (pretend that the header doesn't exist), but in addition, supply other macros that signify that the header exists and provides some feature. I disagree that we should do that. (I say apparently because I wasn't sure that you did, hence my "if" qualifier above.)

I think that in such a situation we should provide the feature macros, without a header macro. Any positive claim that a feature X exists and works implies the existence of the header. The header macro is - in this case - redundant.

That's what I was thinking, and I still think it's a good idea. It allows for either check, depending upon how one chooses to structure one's code. The header macro is general. The feature macros are stop-gaps. However, the latter are sufficient for the current need.

Right, that's basically what we've always done:

BOOST_NO_HEADER : when not defined, header exists and mostly (usefully) works. BOOST_NO_HEADER_FEATURE : when not defined then some "advanced" feature not covered by the above also works.

Of course deciding what you class as advanced vs usefully works is always troublesome.

We're in that gray area between in this case. ___ Rob (Sent from my portable computation engine)