Рішення алгоритму:
std::generate(numbers.begin(), numbers.end(), rand);
Рішення для циклу на основі діапазону:
for (int& x : numbers) x = rand();
Чому я хотів би використовувати більш детальний опис std::generateна основі діапазону циклів for в C ++ 11?
begin()і end()?
rangeфункцію у своєму наборі інструментів. (тобто for(auto& x : range(first, last)))
boost::generate(numbers, rand); // ♪
Відповіді:
Перша версія
std::generate(numbers.begin(), numbers.end(), rand);
повідомляє нам, що ви хочете сформувати послідовність значень.
У другій версії читач повинен сам це зрозуміти.
Заощадження на наборі тексту зазвичай є неоптимальним, оскільки найчастіше втрачається під час читання. Більшість коду читається набагато більше, ніж набирається.
numbersдвічі без причини. Отже: boost::range::generate(numbers, rand);. Немає жодної причини, що ви не можете мати як коротший, так і більш розбірливий код у добре побудованій бібліотеці.
std::generate(number.begin(), numbers.begin()+3, rand), правда? Тож я думаю, вказати numberдвічі може бути корисно іноді.
std::generate(), ви можете замість цього зробити std::generate(slice(number.begin(), 3), rand)або навіть краще з гіпотетичним синтаксисом нарізки діапазону, таким чином, std::generate(number[0:3], rand)який усуває повторення number, дозволяючи при цьому гнучку специфікацію частини діапазону. Зворотне, починаючи з трьох аргументів, std::generate()є більш нудним.
Незалежно від того, чи цикл for заснований на діапазоні, це взагалі не впливає, це лише спрощує код всередині дужок. Алгоритми чіткіші тим, що вони демонструють намір .
Особисто я прочитав:
std::generate(numbers.begin(), numbers.end(), rand);
є "ми призначаємо все в діапазоні. Діапазон є numbers. Присвоєні значення є випадковими".
Моє початкове читання:
for (int& x : numbers) x = rand();
"ми робимо щось для всього в діапазоні. Діапазон є numbers. Що ми робимо, це присвоюємо випадкове значення."
Це дуже чорно схожі, але не однакові. Однією з правдоподібних причин, яку я міг би викликати до першого читання, є те, що я думаю, що найважливішим фактом цього коду є те, що він присвоює діапазон. Тож є ваше "чому я хотів би ...". Я використовую, generateтому що в C ++ std::generateозначає "присвоєння діапазону". Як і до речі std::copy, різниця між ними полягає в тому, з чого ви призначаєте.
Однак є незрозумілі фактори. На основі діапазону для циклів за своєю суттю більш прямий спосіб виразити, що діапазон є numbers, ніж алгоритми на основі ітераторів. Ось чому люди працюють над бібліотеками алгоритмів на основі діапазону: boost::range::generate(numbers, rand);виглядає краще, ніж std::generateверсія.
На відміну від цього, int&у вашому діапазоні циклу for є зморшка. Що робити, якщо тип значення діапазону не є int, тоді ми робимо щось надокучливо тонке, що залежить від того, наскільки він конвертований int&, тоді як generateкод залежить лише від повернення від randприсвоєння елементу. Навіть якщо тип значення такий int, я все одно можу зупинитися, щоб подумати, чи є це чи ні. Отже auto, що відкладає роздуми про типи, поки я не побачу, що їм присвоюють - auto &xя кажу "взяти посилання на елемент діапазону, який би тип не міг бути". Ще в C ++ 03, алгоритми (бо вони шаблони функцій) були способом приховати точні типи, тепер вони шлях.
Я думаю, що завжди було так, що найпростіші алгоритми мають лише незначну перевагу над еквівалентними циклами. Діапазон петель для поліпшення циклів покращує петлі (насамперед, видаляючи більшу частину шаблону, хоча в них є трохи більше, ніж це). Тож поля стають жорсткішими, і, можливо, ви передумаєте в деяких конкретних випадках. Але там все ще є різниця в стилі.
operator int&()? :)
int&на, SomeClass&і тепер вам доведеться турбуватися про оператори перетворення та конструктори з одним параметром, не позначені explicit.
operator int&()і operator int const &() const, але знову ж таки це може працювати, перевантажуючи operator int() constі operator=(int).
На мій погляд, Ефективний пункт 43 STL: "Віддайте перевагу викликам алгоритму рукописним циклам". все ще є гарною порадою.
Зазвичай я пишу функції обгортки, щоб позбутися begin()/ end()hell. Якщо ви зробите це, ваш приклад буде виглядати так:
my_util::generate(numbers, rand);
Я вважаю, що це перевершує діапазон, заснований на циклі, як у передачі наміру, так і в читабельності.
Сказавши це, я повинен визнати, що в C ++ 98 деякі виклики алгоритму STL давали непередаваний код, і слідування "Віддавати перевагу викликам алгоритму рукописним циклам" не здавалося хорошою ідеєю. На щастя, лямбди змінили це.
Розглянемо наступний приклад з Herb Sutter: Lambdas, Lambdas Everywhere .
Завдання: Знайти перший елемент у v, який є > xі < y.
Без лямбд:
auto i = find_if( v.begin(), v.end(),
bind( logical_and<bool>(),
bind(greater<int>(), _1, x),
bind(less<int>(), _1, y) ) );
З лямбдою
auto i=find_if( v.begin(), v.end(), [=](int i) { return i > x && i < y; } );
На мій погляд, ручний цикл, хоч і може зменшити багатослівність, бракує повторно:
for (int& x : numbers) x = rand();
Я б не використовував цей цикл для ініціалізації 1 діапазону, визначеного цифрами , тому що коли я дивлюсь на нього, мені здається, що він ітераціюється над діапазоном чисел, але насправді цього не робить (по суті), тобто замість читання з діапазону, це запис в діапазон.
Намір стає набагато чіткішим, коли ви використовуєте std::generate.
1. ініціалізація в цьому контексті означає надання значущого значення елементам контейнера.
std::generate, що можна припустити програмістом на C ++ (якщо вони не знайомі, вони шукатимуть, той самий результат).
&символ?) Перевага алгоритмів полягає в тому, що вони демонструють намір, тоді як з циклами ви повинні це зробити. Якщо у реалізації циклу є помилка, незрозуміло, чи є вона помилкою чи навмисною.
std::generate, просто з допомогою простого погляду, можна сказати , що - то генерується з допомогою цієї функції; що це щось відповідає третім аргументом функції. Я думаю, що це набагато краще.
Є кілька речей, які ви не можете зробити (просто) з циклами на основі діапазону, які алгоритми, які беруть ітератори як вхідні дані, можуть. Наприклад з std::generate:
Заповніть контейнер до limit(виключено, limitє дійсним ітератором numbers) змінними з одного розподілу, а решту змінними з іншого розподілу.
std::generate(numbers.begin(), limit, rand1);
std::generate(limit, numbers.end(), rand2);
Алгоритми на основі ітераторів дають вам кращий контроль за діапазоном, на якому ви працюєте.
Що стосується конкретного випадку std::generate, я погоджуюся з попередніми відповідями щодо питання читабельності / наміру. std :: generated мені здається більш зрозумілою версією. Але я визнаю, що це певним чином питання смаку.
Тим не менш, у мене є ще одна причина не викидати алгоритм std :: - є певні алгоритми, які спеціалізуються на деяких типах даних.
Найпростішим прикладом буде std::fill. Загальна версія реалізована як цикл for через наданий діапазон, і ця версія буде використана під час створення шаблону шаблону. Але не завжди. Наприклад, якщо ви надасте йому діапазон, який є std::vector<int>- часто він насправді буде дзвонити memsetпід капотом, даючи набагато швидший і кращий код.
Тож я намагаюся розіграти тут карту ефективності.
Ваш рукописний цикл може бути таким же швидким, як версія алгоритму std ::, але навряд чи він може бути швидшим. Більше того, алгоритм std :: може бути спеціалізованим для певних контейнерів та типів, і це робиться в чистому інтерфейсі STL.
Я відповів би, можливо, і ні. Якщо ми говоримо про C ++ 11, то, можливо, (більше як ні). Наприкладstd::for_each , насправді дратує використання навіть з лямбдами:
std::for_each(c.begin(), c.end(), [&](ExactTypeOfContainedValue& x)
{
// do stuff with x
});
Але використання діапазону для набагато краще:
for (auto& x : c)
{
// do stuff with x
}
З іншого боку, якщо ми говоримо про C ++ 1y, то я б стверджував, що ні, алгоритми не будуть застарілими на основі діапазону для. У стандартному комітеті С ++ існує дослідницька група, яка працює над пропозицією додати діапазони до С ++, а також проводиться робота над поліморфними лямбдами. Діапазони позбавлять потреби використовувати пару ітераторів, а поліморфна лямбда дозволить вам не вказувати точний тип аргументу лямбда. Це означає, що це std::for_eachможна використовувати так (не сприймайте це як важкий факт, це просто те, як сьогодні виглядають мрії):
std::for_each(c.range(), [](x)
{
// do stuff with x
});
[]лямбду, ви вказуєте нульове захоплення? Тобто, у порівнянні із просто написанням тіла циклу ви виділили шматок коду із контексту пошуку змінної, в якому він лексично відображається. Ізоляція, як правило, корисна для читача, менше думає про це під час читання.
for_eachвсе ще безглуздо, навіть коли використовується з лямбда-зондом. foreach + захоплення лямбда в даний час є багатослівним способом написання циклу, заснованого на діапазоні, і він стає дещо менш детальним, але все-таки більше, ніж цикл. Не те, що я думаю, що вам доведеться захищатись for_each, звичайно, але ще до того, як побачив вашу відповідь, я думав, що якщо запитувач хотів бити алгоритми, він міг би вибрати for_eachяк найм'якшу з усіх можливих цілей ;-)
for_each, але у нього є одна крихітна перевага перед діапазоном - ви можете зробити його паралельнішим легше, просто додавши до нього паралельний паралель_, щоб перетворити його parallel_for_each(якщо ви використовуєте PPL і вважаєте, що це безпечно для потоку) . :-D
std::algorithms прихована за їхнім інтерфейсом і може бути довільно складною (або довільно оптимізованою).
Одне, на що слід звернути увагу, це те, що алгоритм виражає, що зроблено, а не як.
Цикл на основі діапазону включає те, як все робиться: починаємо з першого, застосовуємо і переходимо до наступного елемента до кінця. Навіть простий алгоритм міг би робити все по-іншому (принаймні деякі перевантаження для конкретних контейнерів, навіть не замислюючись про жахливий вектор), і принаймні те, як це робиться, не стосується письменницької справи.
Для мене це велика різниця, інкапсулюйте якомога більше, і це виправдовує пропозицію, коли ви можете, використовуйте алгоритми.
For-loop на основі діапазону - це саме це. Поки звичайно стандарт не буде змінений.
Алгоритм - це функція. Функція, яка ставить деякі вимоги до своїх параметрів. Вимоги сформульовані в стандарті, щоб дозволити, наприклад, реалізацію, яка використовує переваги всіх доступних потоків виконання і прискорить вас автоматично.