Как параметризовать на направлении итератора?

В основном я делаю следующее:

std::set<int> indices;
// ..fill indices

if (flag)
{
   // we need to process in ascending order
   BOOST_FOREACH (int i, indices) 
   {
      process(i);
   }
}
else
{
   // we need to process in descending order
   BOOST_REVERSE_FOREACH (int i, indices) 
   {
      process(i);
   }
} 

Интересно, существует ли способ записать то же самое в C++ 03 со всего одним вызовом для обработки (i), так или иначе параметризующий на заказе обработки? Как это (который, очевидно, не работает даже в C++ 0x, потому что начинаются () и rbegin () возвращают различные типы):

   auto iter = flag ? indices.begin() : indices.rbegin();
   auto end =  flag ? indices.end() : indices.rend();

   BOOST_FOREACH (int i, std::make_pair(iter, end)) 
   {
      process(i);
   }
6
задан Alex Jenter 25 February 2010 в 04:35
поделиться

2 ответа

То, что вы хотите, можно реализовать с помощью Boost.Variant.

Идея состоит в том, чтобы определить новый тип итератора, который хранит вариант (думайте об этом как об объединении на стероидах C), содержащий либо прямой, либо обратный итератор:

template<class InputRange>
struct any_dir_iterator
: std::iterator_traits<typename boost::range_iterator<InputRange>::type> {

    typedef typename boost::range_iterator<InputRange>::type forward_iterator;
    typedef typename 
        boost::range_reverse_iterator<InputRange>::type reverse_iterator;

    typedef boost::variant<forward_iterator, reverse_iterator> iterator_type;

    iterator_type current_it, end_it;

    any_dir_iterator(InputRange & input_range, 
                     bool fwd = true, 
                     bool end = false) 
    {
        end_it = fwd ? iterator_type(boost::end(input_range)) 
                     : iterator_type(boost::rend(input_range));

        if(end)
            current_it = end_it;
        else
            current_it = fwd ? iterator_type(boost::begin(input_range)) 
                             : iterator_type(boost::rbegin(input_range));
    }

    reference operator*() const {
        return boost::apply_visitor(dereference_visitor<any_dir_iterator>(), 
                                    current_it);
    }

    any_dir_iterator & operator++() {
        boost::apply_visitor(increment_visitor<any_dir_iterator>(), 
                             current_it);
        return *this;
    }

    bool operator==(any_dir_iterator const & rhs) {
        return boost::apply_visitor(equals_visitor<any_dir_iterator>(), 
                                    current_it, rhs.current_it);
    }    
};

Это похоже на Adobe's any iterator, но гораздо менее общий, что означает, что он практически не будет иметь накладных расходов на производительность по сравнению с обычным итератором.

Как видно из приведенного выше кода, вся логика делегирована статическим посетителям, которых мы определяем следующим образом:

template<class AnyDirIterator>
struct dereference_visitor 
: boost::static_visitor<typename AnyDirIterator::iterator_type> {

    typedef typename AnyDirIterator::reference result_type;

    template<class FwdOrRevIterator>
    result_type operator()(FwdOrRevIterator const & it) const { 
        return *it; 
    }
};

template<class AnyDirIterator>
struct increment_visitor 
: boost::static_visitor<typename AnyDirIterator::iterator_type> {

    typedef void result_type;

    template<class FwdOrRevIterator>
    result_type operator()(FwdOrRevIterator & it) const {
        ++it;
    }
};

template<class AnyDirIterator>
struct equals_visitor 
: boost::static_visitor<typename AnyDirIterator::iterator_type>
{
    typedef bool result_type;

    template <typename FwdOrRevIterator>
    bool operator()(FwdOrRevIterator const & lhs, 
                    FwdOrRevIterator const & rhs) const {
        return lhs == rhs;
    }

    template <typename T, typename U>
    bool operator()( const T &, const U & ) const {
        return false; // comparing fwd to rev or vice-versa
    }
};

Это была самая сложная часть. Но нам все еще нужно сделать это более удобным в использовании, для чего мы определяем вспомогательную функцию, которая полагается на функциональность, предоставляемую библиотекой Boost.Range:

template<class InputRange>
boost::iterator_range<any_dir_iterator<InputRange> > 
make_any_dir_range(InputRange & range, bool forward=true) {
    typedef any_dir_iterator<InputRange> iterator;
    return boost::make_iterator_range(iterator(range, forward),
                                      iterator(range, forward, true));
}

И это все. Теперь вы можете написать:

int main() {

    int items[] = { 1, 2 };
    typedef std::vector<int> container_type;
    container_type container(items, items + sizeof(items)/sizeof(items[0]));

    BOOST_FOREACH(int i, make_any_dir_range(container, true))
        std::cout << i << " ";

    std::cout << "\n";
    BOOST_FOREACH(int i, make_any_dir_range(container, false))
        std::cout << i << " ";

    return 0;
}

Которая печатает:

1 2
2 1

Это работает и с контейнерами const, хотя я не показал эту возможность в функции main.

Еще одна приятная вещь, которая вытекает из использования Boost.Range, - это то, что он работает с массивами из коробки. Так что вы можете сделать следующее:

int items[] = { 1, 2 };

BOOST_FOREACH(int i, make_any_dir_range(items, true)) // Prints "1 2"
    std::cout << i << " ";

Для краткости ответа я оставил несколько нереализованных вещей (но все они являются шаблонными, не требующими новых посетителей):

  • Оператор постфиксного инкремента
  • Оператор !=
  • Оператор ->

Вот весь код в Codepad. Из-за политики "рассматривать предупреждения как ошибки" Codepad его не проглотит, но и VS2008, и GCC 4.4 компилируют его нормально на моей локальной машине.

UPDATE

Я сделал несколько тестов и, по-видимому, boost::variant действительно вносит некоторые накладные расходы во время выполнения: цикл на основе BOOST_FOREACH, как в функции main, работает примерно в 4 раза медленнее (при компиляции в режиме release), чем эквивалентная версия с использованием обычного итератора. Было бы интересно проверить, насколько это лучше или хуже, чем накладные расходы, вносимые any_iterator от Adobe.

5
ответ дан 17 December 2019 в 02:27
поделиться

Что ж, очевидный вариант - создать класс, который обрабатывает логику этой ситуации, либо сохраняя флаг, либо используя полиморфизм. Однако в лучшем случае это будет «спрятать» оператор if .

1
ответ дан 17 December 2019 в 02:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: