- User Since
- Feb 11 2015, 3:26 PM (210 w, 2 d)
Thu, Feb 21
Wed, Feb 20
Tue, Feb 19
Question: Why do we define those (almost trivial) functions in the dylib? It seems like those should always be in the headers?
Mon, Feb 18
Fri, Feb 15
I agree with the comments. I think we should strive to be strictly conforming. I make that argument all the time for libc++, so I'll be consistent :-).
Wed, Feb 13
This is looking better and better.
Rebase onto master and update the licenses to the new license. Ping!
This is a good start, but please make sure you implement and test the full paper.
I'll ship this. @eli.friedman I think this is your playground -- if you want any changes to happen post-review, please LMK and I will gladly cooperate.
LGTM, with some de-duplication suggested. I'm not an atomic wrangler, though, so I'd feel more comfortable if someone like @jfb could quickly double-check the implementation of the atomic operations.
Tue, Feb 12
Added missing #defines in tests
I'd like to enable this early in the LLVM 9 cycle.
Mon, Feb 11
Added tests for the abort() behavior and fixed UB I had missed in map::at().
I would like to merge this even though http://wg21.link/p1264 has not been voted into C++ yet, because this is arguably a bug and libc++ differs from other stdlibs in this regard. Once http://wg21.link/p1264 is merged into C++ in one way of another, libc++ will simply have nothing to do.
Here's a summary of what I understand the current state of the patch is (mostly for my own reference as a bird's eye view):
Actually, I'm looking at this and std::is_convertible again, and I think this should be using std::is_convertible in the implementation. I know the paper suggests the implementation in this patch, however it's unclear to me whether that implementation properly handles all the cases that std::is_convertible handles (notably with references). Also, using std::is_convertible under the hood means that we will use the __is_convertible_to intrinsic when it's available instead.
The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI stability from debug mode.
Wed, Feb 6
Tue, Feb 5
I like where this is going generally speaking, but there's a couple of things I'd like to understand. It would also be great if other maintainers with more experience could chime in regarding the rename of __c11_atomic_xxx to __cxx_atomic_xxx -- is this removing functionality that we're providing (but we shouldn't be providing :-)?
Thanks for the patch! Committed as r353206.
@Quuxplusone Please re-ping this when/if this feature makes it into the standard so that we avoid re-doing the work.
I think this functionality might be interesting, but trying to get this into libc++ before it is standardized is definitely putting the cart before the horse. I understand that putting the patch here may make it easier for people to apply it to their local copy of libc++. Hopefully not many people think of themselves as vendors and maintain their own libc++ :-).
Here's the justification for changes in this patch.