_Uglify the current member of move_iterator by miscco · Pull Request #1080 · microsoft/STL (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Contributor
•
edited by StephanTLavavej
Loading
Looking at counted_iterator I found that move_iterator has a non-ugly member current. The same for reverse_iterator
As this is a purely private member it is not user accessible and should be _Ugly
_Uglify the current member of reverse/move iterator _Uglify the current member of move_iterator
For final review, we should think about the bincompat consequences. (I think they're acceptable, as mentioned above.)
For final review, we should think about the bincompat consequences. (I think they're acceptable, as mentioned above.)
I don't recall CLR metadata knowing about access control at all, or caring about the names of members: it's primarily concerned with the sizes of non-static data members and their offsets within the complete object's layout. (We even had success with the <atomic> changes moving the first data member into a base class.) Altogether, I'm not concerned about bincompat here since we still have an object of type iterator_type in the same location.
Thank you for making our code, and our lives, a little _Uglier.
CaseyCarter pushed a commit to CaseyCarter/STL that referenced this pull request
Labels
Something isn't working