Как параметризовать направление итератора? - PullRequest
Новая
       42

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

6 голосов
/ 25 февраля 2010

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

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, потому что begin () и 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);
   }

Ответы [ 2 ]

5 голосов
/ 25 февраля 2010

То, что вы хотите, может быть реализовано с помощью 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 , но гораздо менее общий, что означает, что он практически не будет иметь проблем с производительностью по сравнению с обычным итератором.

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

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

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

1 голос
/ 25 февраля 2010

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

...