[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [libc++] RFC: Restricting use of <atomic> in C++03 (?)
From: Richard Smith <richard () metafoo ! co ! uk>
Date: 2015-07-21 0:45:09
Message-ID: CAOfiQqmv7RYGdFyr+-3O4A4brFXu4HVSb0KgctkFhv_upbJhNA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jul 20, 2015 at 4:23 PM, Eric Fiselier <eric@efcs.ca> wrote:
> Hi All,
>
> We need to decide if libc++ should support <atomic> in C++03. libc++
> is usually considered to be "a c++11 standard library with C++03
> support." Almost all C++11 library features are supported in C++03 and
> supporting <atomic> would be consistent with this.
>
> Currently the atomic header behaves weirdly. Including <atomic> in
> C++03 with clang will explicitly cause a '#error <atomic> is not
> implemented'. However including <atomic> in C++03 with GCC works just
> fine. The reasons for this are accidental but this is how it currently
> stands.
>
> It is *trivial* to support <atomic> in C++03 for both Clang and GCC
> except for one feature.
> In C++03 std::atomic cannot support aggregate initialization. That
> means atomics cannot be initialized using either:
>
> std::atomic<int> i = ATOMIC_VAR_INIT(42);
> std::atomic<int> i = { 42 }
>
> Losing aggregate initialization means that non-local atomics can no
> longer initialized during the static initialization phase of program
> startup but instead during the dynamic initialization phase. This
> makes defining correct atomic globals very hard. As chandlerc
> previously pointed out, this is a pretty fundamental use case for
> atomics.
>
> Other than losing this feature, the rest of <atomic> works out of the
> box in C++03.
>
> Below are two options along with some of their pros and cons.
>
> 1. Allowing use of <atomic> and #undef ATOMIC_VAR_INIT in C++03.
> - Pro: Consistent with handling of other C++11 library features.
> - Pro: This will not break existing C++03 code that previously
> worked with GCC.
> - Pro: Almost all of <atomic> works in C++03.
> - Con: atomics cannot be safely used during program startup.
> - Con: ATOMIC_VAR_INIT would be missing in C++03.
>
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.
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.
> 2. Explicitly disallow use of <atomic> in C++03 by using `#error`.
> - Con: This could possible break users who depend on atomic with
> GCC in C++03.
> - Pro: This change won't break Clang users.
>
Does the other change break Clang users somehow?
> - Pro: atomic is always feature complete when included.
>
> I have no preference one way or the other but I would like a decision
> to be made. Until then I do not know what to do with the <atomic>
> tests.
>
> Any input is appreciated.
>
> /Eric
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic