[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