Чи є технічна причина використовувати> (<) замість! = При збільшенні на 1 у циклі 'для'?

Я майже ніколи не бачу такого forциклу:

for (int i = 0; 5 != i; ++i)
{}

Чи є технічна причина використовувати >або <замість цього !=приріст на 1 у forциклі? Або це більше конвенція?

while (time != 6:30pm) {
    Work();
}

Це 6:31 вечора ... Чорт, зараз наступний мій шанс повернутися додому завтра! :)

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

Технічної причини немає. Але є пом’якшення ризику, ремонтопридатності та кращого розуміння коду.

<або >є більш сильними обмеженнями, ніж!= у більшості випадків і відповідають точно такій самій цілі (я б навіть сказав у всіх практичних випадках).

Існує дублікат питання тут ; і одна цікава відповідь .

Так, є причина. Якщо ви пишете (звичайний старий індекс) для циклу, як це

for (int i = a; i < b; ++i){}

тоді він працює як очікується для будь-яких значень aта b(тобто нульових ітерацій, коли a > bзамість нескінченного, якщо ви використовувалиi == b; ).

З іншого боку, для ітераторів ви писали б

for (auto it = begin; it != end; ++it) 

тому що будь-який ітератор повинен реалізувати operator!=, але не для кожного ітератора можна надати йогоoperator< .

Також на основі діапазону для петель

for (auto e : v)

- це не просто фантазійний цукор, але вони помірно знижують шанси написати неправильний код.

Ви можете мати щось подібне

for(int i = 0; i<5; ++i){
    ...
    if(...) i++;
    ...
}

Якщо ваша змінна циклічна запис записана внутрішнім кодом, ця i!=5петля може не порушити. Це безпечніше перевірити на нерівність.

Редагувати щодо читабельності. Форма нерівності набагато частіше використовується. Тому це дуже швидко читати, оскільки нічого особливого для розуміння (навантаження на мозок зменшується, оскільки завдання є загальним). Тому читачам це здорово використовувати ці звички.

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

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

Я б стверджував, що вираз, як

for ( int i = 0 ; i < 100 ; ++i )
{
  ...
}

більш виразне намір , ніж

for ( int i = 0 ; i != 100 ; ++i )
{
  ...
}

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

Ітератори є важливим випадком, коли ви найчастіше використовуєте !=позначення:

for(auto it = vector.begin(); it != vector.end(); ++it) {
 // do stuff
}

Звісно: на практиці я б написав те саме, спираючись на range-for:

for(auto & item : vector) {
 // do stuff
}

але справа залишається: звичайно можна порівнювати ітератори за допомогою ==або !=.

Умова циклу є інваріантним циклом.

Припустимо, ви не дивитесь на тіло петлі:

for (int i = 0; i != 5; ++i)
{
  // ?
}

в цьому випадку ви знаєте на початку ітерації циклу, iяка не дорівнює 5.

for (int i = 0; i < 5; ++i)
{
  // ?
}

у цьому випадку ви знаєте на початку ітерації циклу, яка iменша за5 .

Друга - це набагато, набагато більше інформації, ніж перша, ні? Тепер намір програміста (майже напевно) той самий, але якщо ви шукаєте помилок, мати впевненість у читанні рядка коду - це добре. А друга примушує цю інваріантну, а це означає, що деякі помилки, які б укусили вас у першому випадку, просто не можуть відбутися (або не спричинити пошкодження пам’яті, скажімо) у другому випадку.

Ви знаєте більше про стан програми, з читання менше коду, з, <ніж з !=. А на сучасних процесорах вони займають стільки ж часу, скільки немає різниці.

Якби ваше iтіло не маніпулювало в корпусі циклу, і воно завжди збільшувалося на 1, а воно починалося менше, ніж 5різниці не було б. Але для того, щоб знати, чи маніпулювали, вам доведеться підтвердити кожен із цих фактів.

Деякі з цих фактів відносно прості, але ви можете помилитися. Перевірка всього корпусу петлі - це, однак, біль.

В C ++ ви можете написати такий indexesтип, що:

for( const int i : indexes(0, 5) )
{
  // ?
}

робить те ж саме, що і з двох вищевказаних forциклів, навіть аж до компілятора, оптимізуючи його до того ж коду. Тут, однак, ви знаєте, що iне можна маніпулювати тілом циклу, як було заявлено const, без коду, що псує пам'ять.

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

Так; OpenMP не паралелізує циклів із !=умовою.

Може статися, що змінна iвстановлена ​​на якесь велике значення, і якщо ви просто використовуєте !=оператор, ви опинитеся в нескінченному циклі.

Як видно з інших численних відповідей, є причини використовувати <замість! =, Що допоможе у кращих випадках, початкових умовах, ненавмисній модифікації лічильника циклу тощо.

Чесно кажучи, я не думаю, що ти можеш достатньо наголосити на важливості конвенції. У цьому прикладі іншим програмістам буде досить легко бачити, що ви намагаєтеся зробити, але це спричинить подвійний результат. Одне із завдань під час програмування - це зробити його максимально зрозумілим та знайомим всім, тому неминуче, коли комусь доведеться оновити / змінити ваш код, це не потребує великих зусиль, щоб з'ясувати, що ви робили в різних блоках коду . Якби я бачив, як хтось використовує !=, я б припустив, що є причина, що вони використовували його замість, <і якби це був великий цикл, я переглянув би все це, намагаючись зрозуміти, що ти зробив, що зробило це необхідним ... і це витрачений час.

Як уже сказав Ієн Ньюсон, ви не можете надійно переосмислити плаваючу змінну і вийти за допомогою !=. Наприклад,

for (double x=0; x!=1; x+=0.1) {}

насправді буде циклічно назавжди, тому що 0,1 не може бути точно представлений у плаваючій точці, отже лічильник вузько пропускає 1. С < ним припиняється.

(Однак зауважте, що це в основному невизначена поведінка, незалежно від того, отримаєте ви 0,9999 ... як останнє прийняте число - яке порушує менше, ніж припущення, - або вже виїжджаєте на 1.0000000000000001.)

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

З цією метою відповідь: ні (*). (*) - "перегляньте посібник з процесора". Якщо ви працюєте з якоюсь кращою системою RISC або FPGA, можливо, вам доведеться перевірити, які інструкції генеруються і які коштують. Але якщо ви використовуєте досить багато будь-яку звичайну сучасну архітектуру, то немає суттєвої різниці рівня процесора в вартості між lt, eq, neі gt.

Якщо ви використовуєте крайній випадок ви можете виявити , що !=потрібно три операції ( cmp, not, beq) проти двох ( cmp,blt xtr myo ). Знову ж таки, RTM у цьому випадку.

Здебільшого причини - захисні / загартовувальні, особливо при роботі з покажчиками або складними петлями. Розглянемо

// highly contrived example
size_t count_chars(char c, const char* str, size_t len) {
    size_t count = 0;
    bool quoted = false;
    const char* p = str;
    while (p != str + len) {
        if (*p == '"') {
            quote = !quote;
            ++p;
        }
        if (*(p++) == c && !quoted)
            ++count;
    }
    return count;
}

Менш надуманим прикладом може бути те, коли ви використовуєте зворотні значення для виконання приростів, приймаючи дані від користувача:

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i != len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;

        std::cin >> step;
        i += step; // here for emphasis, it could go in the for(;;)
    }
}

Спробуйте це і введіть значення 1, 2, 10, 999.

Ви можете запобігти цьому:

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i != len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;
        std::cin >> step;
        if (step + i > len)
            std::cout << "too much.\n";
        else
            i += step;
    }
}

Але те, що ви, мабуть, хотіли

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i < len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;
        std::cin >> step;
        i += step;
    }
}

Існує також щось упереджене до конвенції <, оскільки замовлення в стандартних контейнерах часто покладається на operator<, наприклад, хешування в декількох контейнерах STL визначає рівність, кажучи

if (lhs < rhs) // T.operator <
    lessthan
else if (rhs < lhs) // T.operator < again
    greaterthan
else
    equal

Якщо lhsі rhsє визначений користувачем клас, пише цей код як

if (lhs < rhs) // requires T.operator<
    lessthan
else if (lhs > rhs) // requires T.operator>
    greaterthan
else
    equal

Виконавець повинен передбачити дві функції порівняння. Так <став прихильним оператором.

Існує кілька способів написання коду будь-якого типу (як правило), у цьому випадку просто буває два способи (три, якщо порахувати <= і> =).

У цьому випадку люди віддають перевагу> і <, щоб переконатися, що навіть якщо у циклі трапиться щось несподіване (наприклад, помилка), воно не зациклюється нескінченно (BAD). Розглянемо, наприклад, наступний код.

for (int i = 1; i != 3; i++) {
    //More Code
    i = 5; //OOPS! MISTAKE!
    //More Code
}

Якби ми використовували (i <3), ми б були в безпеці від нескінченного циклу, оскільки це поставило більше обмеження.

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

Сподіваюся, це допомогло!

Найпоширеніша причина використання <- це конвенція. Більшість програмістів вважають петлі на кшталт цього «поки індекс знаходиться в діапазоні», а не «поки індекс не досягне кінця». Там цінність дотримується умовності, коли можна.

З іншого боку, багато відповідей тут стверджують, що використання <форми допомагає уникнути помилок. Я б заперечував, що у багатьох випадках це просто допомагає приховати помилки. Якщо індекс циклу повинен досягати кінцевого значення, а натомість він фактично виходить за його межі, то трапляється щось, чого ви не очікували, що може спричинити несправність (або бути побічним ефектом чергової помилки). <, Ймовірно , затримає відкриття помилки. !=, Швидше за все, призведе до кабінки, зависання або навіть аварії, яка допоможе вам знайти помилку раніше. Чим раніше буде виявлена ​​помилка, тим дешевше її виправити.

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

Наприклад, якщо ви переходите через звичайний рядок C, зазвичай пишемо:

for (char *p = foo; *p != '\0'; ++p) {
  // do something with *p
}

ніж

int length = strlen(foo);
for (int i = 0; i < length; ++i) {
  // do something with foo[i]
}

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

За допомогою рядка C ++ std :: ви використовуєте діапазон для циклу, стандартного алгоритму чи ітераторів, навіть якщо довжина легко доступна. Якщо ви використовуєте ітератори, умовою є використання, !=а не <як:

for (auto it = foo.begin(); it != foo.end(); ++it) { ... }

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

Однією з причин не використовувати цю конструкцію є числа з плаваючою комою. !=це дуже небезпечне порівняння для використання з поплавками, оскільки воно рідко оцінить справжнє, навіть якщо цифри виглядають однаково. <або >знімає цей ризик.

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

(1) Трохи надмірності. На природній мові ми зазвичай надаємо більше інформації, ніж це суворо необхідно, як і виправлення помилок. Тут додаткова інформація полягає в тому, що змінна петля i(див. Як я тут використовував надмірність? Якщо ви не знали, що означає "змінна петля", або якщо ви забули ім'я змінної, прочитавши "змінну циклу i", ви отримаєте повну інформація) менше, ніж 5 протягом циклу, не просто відрізняється від 5. Надмірність підвищує читабельність.

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

Не розмовляйте навколо гарячої кашки. Просто висвітліть труднощі!

Перше речення - це дослівний переклад німецької ідіоми. Друга - це загальна англійська ідіома з основними словами, заміненими синонімами. Результат зрозумілий, але для розуміння цього потрібно набагато більше часу:

Не бийте навколо куща. Просто поясніть проблему!

Це справедливо навіть у тому випадку, якщо синоніми, які використовуються в першій версії, трапляються краще, ніж звичайні слова в англійській ідіомі. Подібні сили діють, коли програмісти читають код. Ось чому це 5 != iі 5 > iє дивні способи його розміщення, якщо ви не працюєте в середовищі, в якому звичайно проводити обмін на більш нормальне i != 5та i < 5таким чином. Такі діалектні спільноти існують, ймовірно, тому, що послідовність полегшує запам’ятовування писати 5 == iзамість природного, але схильного до помилок i == 5.

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

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

Іншим прикладом, який демонструє більш широку застосовність порівняння рівності в таких контекстах, є популярна головоломка з реалізацією unsignedітерації аж до 0. Це можна зробити як

for (unsigned i = 42; i != -1; --i)
  ...

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

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

• Заперечення ускладнюють розуміння коду
• <або >є лише один, але !=два

На додаток до різних людей, які згадували, що це зменшує ризик, воно також зменшує кількість перевантажень функцій, необхідних для взаємодії з різними стандартними компонентами бібліотеки. Наприклад, якщо ви хочете, щоб ваш тип зберігався в a std::setабо використовувався як ключ для std::mapабо використовувався з деякими алгоритмами пошуку та сортування, стандартна бібліотека зазвичай використовує std::lessдля порівняння об'єктів, оскільки для більшості алгоритмів потрібне лише суворе слабке впорядкування . Таким чином, стає доброю звичкою використовувати <порівняння замість !=порівнянь (де, звичайно, це має сенс).

З точки зору синтаксису проблеми немає, але логіка, що стоїть за цим виразом 5!=i, не є звуком.

На мій погляд, використання !=для встановлення меж циклу for циклу не є логічно здоровим, оскільки для циклу або збільшується, або зменшує індекс ітерації, тому встановлення циклу ітерації, поки індекс ітерації не вийде за межі (!= до чогось) належна реалізація.

Це буде працювати, але воно схильне до неправильної поведінки, оскільки обробка даних про кордони втрачається при використанні !=для додаткової проблеми (це означає, що ви знаєте з самого початку, якщо вона збільшується чи зменшується), ось чому замість !=цього <>>==>використовується.