Optimize the iterator comparison logic to compare Current.data() pointers. Use std::tie for assignments from std::pair. Replace the custom class with a function returning iterator_range.
Details
Diff Detail
Event Timeline
llvm/include/llvm/ADT/StringExtras.h | ||
---|---|---|
556–559 | this should also be a lower-case split now that it's a function. (Believe it or not, this is the reason I was first drawn to this -- it's uncommon to see a class used like this because, even in the cases where you do have a separate class, you usually create a function wrapper for it. The original reason for this is pragmatic (use of template argument deduction), but the practice is so ubiquitous that a deviation from it stands out.) |
llvm/include/llvm/ADT/StringExtras.h | ||
---|---|---|
556–559 | Yeah, that makes sense. In fact, I originally named the class lowercase for this exact reason. |
Make the function lowercase. I had to modify IR/DataLayout.cpp to call its own static split() via ::split().
Why are all the changes from separator character to separator string necessary or desirable?
Looks good to me, but I'd give @joerg a chance to respond first.
There's no good place to store the separator character. The functional version of split is implemented by creating a StringRef(&the_char, 1), but that won't work in the iterator version. Keeping it doesn't seem to be worth the trouble, as it does not have any performance benefits, and doesn't make the callsites more complicated.
Can't you wrap iterator_range<T> and possibly even support Twines like that? That is, don't extend the life time of the iterators, but store it in the range?
I am not sure that it is worth it, but I am not completely opposed to the idea either. Symmetry with StringRef::split also counts for something..
Do you have commit access? If not, please read the llvm developer policy and follow the instructions, thanks!
That's not the problem. The problem is that @labath and @joerg seem not to agree on how it should be done, and I don't know whether to hack support for char delimiter to preserve the old syntax as @joerg wanted, or to keep it as is (i.e. without support for char delimiter) as @labath originally suggested.
I'm fine with either option, and it doesn't seem to me like @joerg has a particularly strong more opinion either, so maybe you can cast the deciding vote?
I consider it more important to fix the equality operator and the name capitalization (in that order).
Restored support for char Separator — after all, it isn't hard and the cost is negligible.
Ok, this turned out to be a little bit harder than I anticipated — in particular I needed to add a copy constructor and assignment operator.
@labath, do you think it's fine or should I revert to non-char version?
It makes things a bit more complicated, which then makes the case for dropping char slightly stronger, but I still don't think it's worth making a fuss of it.
llvm/unittests/ADT/StringExtrasTest.cpp | ||
---|---|---|
317 | maybe EXPECT_THAT(Result, testing::ElementsAre("foo", "bar", "", "baz")); |
this should also be a lower-case split now that it's a function.
(Believe it or not, this is the reason I was first drawn to this -- it's uncommon to see a class used like this because, even in the cases where you do have a separate class, you usually create a function wrapper for it. The original reason for this is pragmatic (use of template argument deduction), but the practice is so ubiquitous that a deviation from it stands out.)