0xd34df00d
30.10.2012 20:20 Azoth_primary
Отсортировать в обратном порядке? sortBy (flip $ comparing smth) вместо sortBy (comparing smth).
Это вам не ебля с rbegin/rend.
16 comments
recommend
bookmark
subscribe
>Это вам не ебля с rbegin/rend.
std::reverse
Ну да, давайте будем делать дополнительные операции.
ну ты высосал проблему из пальца и выплюнул ее на псто
нихуя не из пальца, ты не шаришь бля
Я вспомнил неосиляторство rbegin/rend Улидткой и его питонгурты на тему.
потому что они говно полное блядь, и соснули по принципам вашей любимой статической типизации
кокок
А отсюда поподробнее.
итератор — это блядь итератор, его тип (статический тип времени компиляции блядь) не должен меняться от того, в каком направлении мы итерируемся по контейнеру. Не находишь?
И если не начинать обмазываться ещё не готовыми кококококонцептами — то полностью generic код, работающий для любого плюсового итератора, обретает наш любимый ducktyping-стиль и любимые же наши ошибки компиляции в рандомных местах.
ошибки компиляции — не ошибки выполнения
Нахожу. Хотя бы потому, что ++ для forward и backward-итератора делает принципиально разные вещи, и reverse_iterator не имеет смысла для стримов.
причём тут блядь это
я о необходимости менять окружающий (вообще практически анрилейтед) код просто оттого, что ты обернешь итератор в std::reverse. Сравни с orderFunction → (flip orderFunction) в хаскеле у дедфуда, или с iter → reversed(iter) в питоне. ВСЁ, никаких изменений в окружающем коде не требуется, всё гарантированно работает.
держи http://en.cppreference.com/w/cpp/iterato...
ладно, согласен, я хочу от итераторов полиморфизма и мне нужен бекеровский any_iterator в неймспейсе boost::.
ты не понял проблему. В #tzeosz я описывал off-by-one от этого reverse_iterator и необходимость менять окружающий код (в том числе проверку завершения итерации этц).
ну, кстати, я так понял в плюсах тоже можно свой flip запилить, не?