- 74f4da7 Stephan Tolksdorf: fixes the issue in the <atomic> header and adds corresponding tests. I've used macros to fall back to a user-provided default constructor if _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS (though I suspect that there won't be many users defining that macro). by Howard Hinnant · 11 years ago
- 7b9d6a8 Implement the ATOMIC_*_LOCK_FREE macros. by Howard Hinnant · 12 years ago
- 6ae4705 atomic_bool was missing (just a typedef to atomic<bool>). by Howard Hinnant · 12 years ago
- 7eb9f1e Align <atomic> with clang r163964 which disallows const _Atomic types. by Howard Hinnant · 12 years ago
- 300c67a Apply noexcept and constexpr to <atomic>. by Howard Hinnant · 12 years ago
- 6186c7f Switch libc++ from __atomic_* builtins to __c11_atomic_* builtins. by Richard Smith · 12 years ago
- b229209 Now that clang supports doing the right thing with regard to atomic by David Chisnall · 12 years ago
- 0341c82 Fix use of __atomic_is_lock_free() intrinsic. by David Chisnall · 12 years ago
- 83b2c84 Some fixes to <atomic> operations to explicitly use atomic types and operations. by David Chisnall · 13 years ago
- 08e1747 Windows support by Ruben Van Boxem. by Howard Hinnant · 13 years ago
- 154002b Provide a more readable error message for <atomic> until it is implemented. by Howard Hinnant · 13 years ago
- 770d1c4 After a long break to wait for the atomic spec to settle, this completes the library part of <atomic>. It currently won't even parse as it depends on the existence of the intrinsics specified at http://libcxx.llvm.org/atomic_design_a.html. Everything has been tested using fake intrinsics which have now been removed. As the intrinsics come online, the ATOMIC_* macros will need to be adjusted to reflect which operations are lock-free. These macros will probably need to be #ifdef'd for each supported platform. by Howard Hinnant · 14 years ago
- d2f6afb atomics ... by Howard Hinnant · 14 years ago
- 91e2f26 Work on <atomic> continues. The file size is actually sane now... by Howard Hinnant · 14 years ago
- 4777bf2 Getting <atomic> warmed back up. We have a hopefully more stable spec now. And I believe the intrinsic spec at http://libcxx.llvm.org/atomic_design_a.html is still good. by Howard Hinnant · 14 years ago
- bce9c31 [atomics.types.address] by Howard Hinnant · 14 years ago
- 5bbe97d atomic_schar, atomic_uchar, atomic_short, atomic_ushort, atomic_int, atomic_uint, atomic_long, atomic_ulong, atomic_llong, atomic_ullong, atomic_char16_t, atomic_char32_t and atomic_wchar_t. by Howard Hinnant · 14 years ago
- e738501 atomic_char by Howard Hinnant · 14 years ago
- 21ef47f Changing <atomic> to follow Design A by Howard Hinnant · 14 years ago
- 6cac2c2 Make flag type configurable by the compiler by Howard Hinnant · 14 years ago
- 002f1d3 Filling out the infrastructure in <atomic> by Howard Hinnant · 14 years ago
- 611fdaf Still working on the basic design of <atomic>. I'm working towards a system by which the compiler only needs to define the strongest intrinsics it can. Weaker atomics in the library automatically try stronger and stronger variants, picking the weakest compiler intrinsic available. If no compiler intrinsics are available for a given operation, the library locks a mutex and does the job. Better documentation to follow... by Howard Hinnant · 14 years ago
- 79101ae [atomics.flag] completed. Initialization is not working on clang and can't be made to work without defaulted default constructors. by Howard Hinnant · 14 years ago
- f701e25 Name change of intrinsics as suggested by Jeffrey Yasskin by Howard Hinnant · 14 years ago
- 767ae2b Contemplating this <atomic> reorganization... by Howard Hinnant · 14 years ago
- ed760f4 Wrestling with the slowly dawning realization that <atomic> isn't implementable on any compiler at my disposal... by Howard Hinnant · 14 years ago
- d1176e2 [atomics.order] by Howard Hinnant · 14 years ago
- 8f73c63 Getting started on <atomic> by Howard Hinnant · 14 years ago