This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
A slight extension on my earlier mail.
Your implementation would break this code:
#include<algorithm>
struct S { bool operator==(const S& s) { return true; } };
int main(void) { S s[4]; std::find_end(s, s+4,s,s+4); }
(Notice the non-const operator==). Now, it is clear that this isn't standards-compatable code, but it is still broken.
Your technique also is not going to scale to some more commonly used code, in some of the more complex algorithms, such as lexicographic_compare, where you have two arrays, which could have different value_types, and have to do< comparisons both between the first and second array, and the second and first array. In that case you need a class so you can have two (actually four) overloads.
I think for this kind of cleanup in general, we are in a much better state than we were 5 or so years ago, as libc++ (clang's standard library) is using a very similar technique (with a class with several overloads, not a lambda function), so code is going to have to be fixed for that anyway. Also doing the switch under the C++11 flag is tempting to, as quite a bit of "bad" code is going to get broken by that anyway.
So in conclusion, I think this is a good idea, and might be the right time to do it. I'm just not clear on the advantage of lambdas over a class.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |