<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 20, 2015 at 4:23 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
We need to decide if libc++ should support <atomic> in C++03. libc++<br>
is usually considered to be "a c++11 standard library with C++03<br>
support." Almost all C++11 library features are supported in C++03 and<br>
supporting <atomic> would be consistent with this.<br>
<br>
Currently the atomic header behaves weirdly. Including <atomic> in<br>
C++03 with clang will explicitly cause a '#error <atomic> is not<br>
implemented'. However including <atomic> in C++03 with GCC works just<br>
fine. The reasons for this are accidental but this is how it currently<br>
stands.<br>
<br>
It is *trivial* to support <atomic> in C++03 for both Clang and GCC<br>
except for one feature.<br>
In C++03 std::atomic cannot support aggregate initialization. That<br>
means atomics cannot be initialized using either:<br>
<br>
    std::atomic<int> i = ATOMIC_VAR_INIT(42);<br>
    std::atomic<int> i = { 42 }<br>
<br>
Losing aggregate initialization means that non-local atomics can no<br>
longer initialized during the static initialization phase of program<br>
startup but instead during the dynamic initialization phase. This<br>
makes defining correct atomic globals very hard. As chandlerc<br>
previously pointed out, this is a pretty fundamental use case for<br>
atomics.<br>
<br>
Other than losing this feature, the rest of <atomic> works out of the<br>
box in C++03.<br>
<br>
Below are two options along with some of their pros and cons.<br>
<br>
1. Allowing use of <atomic> and #undef ATOMIC_VAR_INIT in C++03.<br>
    - Pro: Consistent with handling of other C++11 library features.<br>
    - Pro: This will not break existing C++03 code that previously<br>
worked with GCC.<br>
    - Pro: Almost all of <atomic> works in C++03.<br>
    - Con: atomics cannot be safely used during program startup.<br>
    - Con: ATOMIC_VAR_INIT would be missing in C++03.<br></blockquote><div><br></div><div>These cases result in build errors, rather than silent wrong behaviour, so they don't seem especially bad. Sure, <atomic> would be less useful in C++03, but it wouldn't be entirely useless. It would mean that you don't get generalized constant expressions and list initialization syntax using <atomic> in C++03, but that's true for all libc++ components, so it seems reasonably consistent.</div><div><br></div><div>The only slightly inconsistent part of this approach is making ATOMIC_VAR_INIT unavailable rather than making it work but be non-constant, and that seems important for safety.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Explicitly disallow use of <atomic> in C++03 by using `#error`.<br>
    - Con: This could possible break users who depend on atomic with<br>
GCC in C++03.<br>
    - Pro: This change won't break Clang users.<br></blockquote><div><br></div><div>Does the other change break Clang users somehow?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    - Pro: atomic is always feature complete when included.<br>
<br>
I have no preference one way or the other but I would like a decision<br>
to be made. Until then I do not know what to do with the <atomic><br>
tests.<br>
<br>
Any input is appreciated.<br>
<br>
/Eric<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>