Віддаєте перевагу алгоритмам рукописних циклів?

Що з перерахованого нижче вам здається більш читабельним? Рукописний цикл:

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

Або виклик алгоритму:

#include <algorithm>
#include <functional>

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

Цікаво, чи std::for_eachдійсно це варте, враховуючи такий простий приклад, вже потрібна стільки коду.

Які ваші думки з цього приводу?

Існує причина, що лямбда були введені, і це тому, що навіть Стандартний комітет визнає, що друга форма смокче. Скористайтеся першою формою, поки не отримаєте підтримку C ++ 0x та лямбда.

Завжди використовуйте той варіант, який найкраще описує те, що ви маєте намір зробити. Це є

Для кожного елемента xв vec, робити bar.process(x).

Тепер розглянемо приклади:

std::for_each(vec.begin(), vec.end(),
              std::bind1st(std::mem_fun_ref(&Bar::process), bar));

У нас for_eachтеж є - yippeh . У нас є [begin; end)асортимент, над яким ми хочемо оперувати.

В принципі, алгоритм був набагато більш чітким і, таким чином, кращим перед будь-якою рукописною реалізацією. Але тоді ... Біндери? Мемфун? В основному C ++ internans про те, як влаштувати функцію члена? Для мого завдання я їх не хвилюю ! Ні я не хочу страждати від цього багатослівного, моторошного синтаксису.

Тепер інша можливість:

for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it)
{
    bar.process(*it);
}

Зрозуміло, це загальна модель розпізнавання, але ... створення ітераторів, петління, збільшення та відсилання. Це теж усі речі, які мені не цікаві , щоб виконати своє завдання.

Слід визнати, що це виглядає waay краще , ніж перше рішення (по крайней мере, контур тіла є гнучким і досить чітко), але все ж, це на самому ділі не що великий. Ми використаємо цю, якщо у нас не було кращої можливості, але, можливо, у нас є ...

Кращий спосіб?

Тепер повернемося до for_each. Чи не було б чудово буквально говорити for_each та бути гнучким у виконанні операції, яка також повинна бути виконана? На щастя, оскільки C ++ 0x лямбдас ми є

for_each(v.begin(), v.end(), [&](const Foo& x) { bar.process(x); })

Тепер, коли ми знайшли абстрактне, загальне рішення для багатьох суміжних ситуацій, варто зазначити, що в цьому конкретному випадку є абсолютний номер 1 улюбленого :

foreach(const Foo& x, vec) bar.process(x);

Це насправді не може стати набагато зрозумілішим за це. На щастя, C ++ 0x get - це аналогічний вбудований синтаксис !

Тому що це так нечитабельно?

for (unsigned int i=0;i<vec.size();i++) {
{
    bar.process(vec[i]);
}

загалом, перша форма читається майже всім, хто знає, що таке цикл, незалежно від того, на якому фоні вони є.

також взагалі, другий зовсім не такий читабельний: досить легко зрозуміти, що робить for_each, але якщо ви ніколи не бачили, std::bind1st(std::mem_fun_refя можу уявити, що це важко зрозуміти.

Насправді навіть із C ++ 0x я не впевнений for_each, що отримає багато кохання.

for(Foo& foo: vec) { bar.process(foo); }

Є спосіб більш читабельним.

Єдине, що мені не подобається в алгоритмах (у С ++) - це їх міркування щодо ітераторів, які створюють дуже багатослівні твердження.

Якби ви написали смужку як функтор, то це було б набагато простіше:

// custom functor
class Bar
{    public: void operator()(Foo& value) { /* STUFF */ }
};


std::for_each(vec.begin(), vec.end(), Bar());

Тут код досить читабельний.

Я віддаю перевагу останній, тому що він акуратний і чистий. Це насправді частина багатьох інших мов, але в C ++, це частина бібліотеки. Це насправді не має значення.

Зараз це питання насправді не характерне для C ++, я б сказав.

Вся справа в тому, що передача якогось функтора в іншу функцію не призначена для заміни циклів .
Передбачається спростити певні закономірності, які стають дуже природними завдяки функціональному програмуванню, наприклад, відвідувач і спостерігач , просто назвіть два, які мені спадають на думку негайно.
У мовах, яким не вистачає функцій першого порядку (найкраще прикладом є Java), такі підходи завжди потребують реалізації певного інтерфейсу, який є досить словесним та зайвим.

Загальне використання, яке я бачу багато в інших мовах, було б:

someCollection.forEach(someUnaryFunctor);

Перевага цього полягає в тому, що вам не потрібно знати, як someCollectionреально реалізується чи що someUnaryFunctorробить. Все, що вам потрібно знати, - це те, що його forEachметод буде повторювати всі елементи колекції, передаючи їх заданій функції.

Якщо ви особисто можете отримати всю інформацію про структуру даних, яку ви хочете повторити, та всю інформацію про те, що ви хочете зробити на кожному кроці ітерації, то функціональний підхід є надмірним ускладненням речей, особливо з мови, де це, як видається, досить нудно.

Крім того, ви повинні мати на увазі, що функціональний підхід повільніший, оскільки у вас є багато дзвінків, які надходять за певну ціну, які у вас немає в циклі.

Я думаю, що проблема тут полягає в тому, що for_eachнасправді це не алгоритм, це просто інший (і зазвичай неповноцінний спосіб) написання рукописного циклу. з цього погляду це повинен бути найменш використаний стандартний алгоритм, і так, ви, ймовірно, також можете використовувати цикл. однак порада в назві все ще стоїть, оскільки існує декілька стандартних алгоритмів, пристосованих до більш конкретного використання.

Там, де є алгоритм, який більш чітко виконує те, що ви хочете, тоді так, вам слід віддати перевагу алгоритмам над рукописними петлями. Очевидними прикладами тут є сортування з sortабо stable_sortпошук за допомогою lower_bound, upper_boundабо equal_range, але у більшості з них є певна ситуація, в якій їх краще використовувати в руці з кодованим циклом.

Для цього невеликого фрагмента коду обидва для мене однаково читаються. Взагалі я знаходжу ручні петлі, схильні до помилок і вважаю за краще використовувати алгоритми, але це дійсно залежить від конкретної ситуації.