- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
#include <vector>
#include <iostream>
template<class T>
struct reverse_view_impl {
const T& cont;
reverse_view_impl(const T& cont): cont(cont) {}
using iterator = typename T::const_reverse_iterator;
};
template<class T>
reverse_view_impl<T> reverse_view(const T& cont) {
return reverse_view_impl<T>(cont);
}
template<class T>
typename reverse_view_impl<T>::iterator begin(const reverse_view_impl<T>& view) {
return view.cont.crbegin();
}
template<class T>
typename reverse_view_impl<T>::iterator end(const reverse_view_impl<T>& view) {
return view.cont.crend();
}
std::vector<int> one_two_three() { return { 1, 2, 3 }; }
int main() {
for (auto i : reverse_view(one_two_three())) {
std::cout << i << std::endl;
}
}
Follow us!
п.с. чет прям угнетает количество бойлерплейт кода, необходимого для реализации четырех версий итераторов (const/mutable forward/reverse)
Boost.Iterator
на самом деле, если херней не страдать, и без фанатизма к проблеме подходить, то простенькие и достаточные итераторы делаются достаточно просто и быстро. 90% приложений покрываются begin()/end() и operator++. я, к слову, делал преимущественно для того что бы не трахатся с объяснениями как пользоваться самопальными контейнерами.
header-only библиотека, который весь этот бойлерплейт возьмет на себя
всё что надо, это объявить чуток приватных методов определенной сигнатуры, например, объясняющих как двигаться итератору и как извлекать значение
лучше один раз сделать, чем сто раз услышать
потому что я в паре либ такое дело видел, и это был не детский кошмар. после этого я как раз и начал сырцы STL читать... мозги заворачивает, но после доморощеного попимаешь на кой хер они там в STL тыщи строк пишут. (что за либа уже не помню, а кошмары были с const/non-const версиями где иногда компилятор подбирал неправильную версию итератора/begin()/end() и компиляция вылетала со стандартными 10ти этажными сообщениями об ошибках. когда увидел cbegin()/cend() в C++11, невольно прослезился.)
class MyClass1::MyClass2 : public SomeBase { ...
не видел
И у каждой было своё условие внутри enable_if (проверка типа T на is_lvalue_reference), чтобы безошибочно отделять lvalue от rvalue аргументов.
Перегрузка, работающая с lvalue, просто захватывала ссылку на оригинальный контейнер.
Перегрузка для rvalue создавала новый объект и мувала в него "умирающий" аргумент-контейнер.
Да, типы возвращаемых значений были разные, но это не было проблемой в моём случае.
это пиздей какой-то xDDDDD