Various cleanups: Impl and wrapper functions for vector algorithms #4146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First,
vector_algorithms.cpp
was defining functions within an unnamed namespace that were quasi-shadowing wrapper functions in<algorithm>
and<xutility>
:STL/stl/src/vector_algorithms.cpp
Lines 1440 to 1442 in f392449
STL/stl/inc/xutility
Lines 97 to 98 in f392449
This was incredibly confusing, so I'm renaming the
vector_algorithms.cpp
functions toimpl
. (I say it was "quasi"-shadowing because we never dragged them into the same scope, but we should never use the same names for things with different signatures/purposes like this. There are specific scenarios where function overloading is fine - usually when the compiler will handle types/arity and there's no risk of confusion about "which one" we're getting - and this is not such a scenario, so we should use different names.)Next, this moves
<algorithm>
and<xutility>
's vector algorithm wrapper templates (that handle 1/2/4/8-byte dispatching) from the global namespace tostd
. I noticed this while auditing the STL for namespace discipline - aside fromextern "C"
machinery in the global namespace, the STL is almost always careful to define all of its internal machinery withinstd
. (There are a few special exceptions for bitmask ops.) These wrapper templates were a major exception. I'm keeping their names, since they do strongly resemble theextern "C"
functions they're wrapping, but we should move them intostd
for cleanliness (and because this may make later work more convenient for me).