-
Notifications
You must be signed in to change notification settings - Fork 1.6k
<span> Implement span #142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
StephanTLavavej
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an incomplete review (we're still working on test infrastructure), but I thought I'd give you some feedback as you work on this.
|
@StephanTLavavej Thanks a lot. I was traveling the last week and hadnt had time to compile check my changes. I will update them most likely today. |
|
Hm you beat me to it. I have pushed the (not tested) changes that I did while traveling. This includes implementation of iterators and using a My appologies that you checked old code. I did not yet implement the container constructors. What I am unsure there is whether we need the full deduction information similar to what libcxx does (see and following) With the deduction guides at the end I would believe that we only need to ensure that for template <class _Tp, class _ElementType>
struct __is_span_compatible_container<_Tp, _ElementType,
void_t<
// data(cont) and size(cont) are well formed
decltype(data(declval<_Tp>())),
decltype(size(declval<_Tp>())),
// remove_pointer_t<decltype(data(cont))>(*)[] is convertible to ElementType(*)[]
typename enable_if<
is_convertible_v<remove_pointer_t<decltype(data(declval<_Tp &>()))>(*)[],
_ElementType(*)[]>,
nullptr_t>::type
>>
: public true_type {};I that correct or do we still needto explicitely remove |
5fa457a to
e6f36e4
Compare
|
I have finished the implementation following the current working draft N4830. It passes all the (expected to pass) tests from libcxx, which I have collected here. I am not really happy about all the iterator boiler plate but meh... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed most of the comments. I have to think a bit about the others though.
BTW It is really strange that github by defaults hides a lot of the comments. Nearly missed half of them
|
I have addressed most of the feedback. However, due to the constraints a lot of the constructors are barely readable anymore so I have to look at that. |
7e0a2f5 to
0543e3b
Compare
|
My kids were actually went so sleep so I finished the refactoring of I am really happy how it turned out. Thanks a lot for the suggestions. I am still not so sure about spaceship magic |
|
I implemented most of the remaining change requests. There are still two open points where I am unsure.
|
|
@StephanTLavavej All is fine. I will most likely be quite unresponsive in the near future. Please proceed without me as I dont kow when I have time between changing diapers. |
|
No problem, I'll take it from here. Should be able to merge this next week! |
|
LWG-3369 " |
|
Could you elaborate on the |
|
I should have clarified - it's the non-member function that Lines 142 to 149 in d862650
|
|
That is ... unfortunate :( |
I blame the author of WG21-P1474. |
span's constructors perform _CONTAINER_DEBUG_LEVEL checking, so the checking in _Span_extent_type was unnecessary and less specific. _Span_extent_type's converting constructor was simply never used.
An LWG issue has been submitted; it's necessary for span testing.
|
I've finished testing |
Move _Adl_verify_range out of _CONTAINER_DEBUG_LEVEL checks so that it works with checked iterators Use _Get_unwrapped_n to check validity of iterator + size constructor
BillyONeal
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your contribution!
|
Waiting for the final round of Microsoft-internal testing, then I will merge this. No additional changes should be pushed at this time. |
|
Success! THANK YOU for implementing this major feature and enduring this extensive code review. |
P0122R7 <span> (microsoft#142)
|
Thanks a lot for all the positive feedback. There was quite a steep learing curve, but your patient feedback helped enormously. Thanks for keeping up with it. |
Description
This is a work in progress of the implementation of std::span (See #4 )
Checklist:
Working Draft.
_Uglyas perhttps://eel.is/c++draft/lex.name#3.1 .
_Ugly.what happens to compile.
by an STL maintainer before CI is online, leave this unchecked for initial
submission).
members, adding virtual functions, changing whether a type is an aggregate or
trivially copyable, etc.). If unsure, leave this box unchecked and ask a
maintainer for help.
However, there are some troubles. I went with
_Compressed_pairto implement static extent, however it seems that it is notconstexpr-friendly. The tests that I have shamelessly copied from libcxx can be found here.At this point I am unsure, which option is better:
_Compressed_pairfullyconstexpr-friendly_Compressed_pairthat isconstexpr-friendlyAlso I followed the approach of string_view and added an indirection however I an unsure whether that is really necessary