2016-11-05 4 views
1

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

Я хотел бы сравнить эти два решения. Первый использует оператор breaks, а второй использует множественное или комбинированное условие. Какой из них является «лучшим» или «правильным» способом выполнения задачи с точки зрения эффективности или надежности. Какой из них менее подвержен ошибкам? Не стесняйтесь предлагать другое решение.

const int MAX_SIZE = 10; 
int myArray[MAX_SIZE] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; 

// two ways to stop a loop 

for (int x = 0; x < MAX_SIZE; x++) { 
    if (myArray[x] == 7) { 
     break; 
    } 
    cout << myArray[x] << “ “; // fixed 
} 

for (int x = 0; (x < MAX_SIZE) && (myArray[x] != 7); x++) { 
    cout << myArray[x] << “ “; 
} 
+1

Я бы выбрал вторую форму, потому что она сохраняет условия в одном месте, а фактический код цикла свободен от несвязанных частей. Я думаю, это сводится к предпочтению. – user2296177

+2

Кажется, ваши петли имеют другое поведение. Предположим, что x равно 0, а myArray [0] равно 7. – PaulMcKenzie

+0

Я имею в виду, что вы делаете одинаковое количество сравнений каждый раз в обоих случаях.Я думаю, что первый из них более читабельен, хотя каждый может просто замаскировать стандартный код цикла 'for' и увидеть второе условие как нечто особенное. Честно говоря, я думаю, что это просто тривиально. –

ответ

3

Во-первых, петли ведут себя по-разному красивый - первый по-прежнему печатает номер 7, а другой нет.

В случае, если вы поменяли местами, это не будет иметь особого значения для компилятора, оба решения будут скомпилированы в почти том же самом собственном коде.

О читаемости (и склонны к ошибкам): Это зависит от того, что для такого простого правила, вероятно, лучше и читабельнее, чтобы сделать его частью условия. Но когда это происходит сложнее, может быть полезно ввести временную переменную, а затем вариант break легче читать. На самом деле довольно часто для более сложных алгоритмов использовать break внутри цикла, часто даже бесконечные петли с break внутри.

1

Две петли не эквивалентны. Для того, чтобы сделать первый цикл производства тот же результат, второй (по крайней мере, для содержимого массива вы указали), вы должны были бы изменить его

for (int x = 0; x < MAX_SIZE; x++) 
{ 
    if (myArray[x] == 7) 
    { 
     break; 
    } 
    cout << myArray[x] << " "; 
} 

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

Тот факт, что вы считаете, что форма, которую у вас была, была эквивалентной, свидетельствует о том, что озабоченность читабельностью затрагивает вас. Поэтому вторая форма была бы предпочтительнее.

+0

Спасибо. Эта форма цикла - это то, что я действительно имел в виду. – Galaxy

2

Как отмечали другие, эти два метода не эквивалентны, поскольку каждый из них производит больше выходов, чем другой. Однако, я думаю, это просто опечатка, и вы могли бы определенно определить это, запустив код.

Для сравнения, первое из них проще обобщать в случае, если вам нужно использовать больше условий остановки (это будет более читаемо, чем если бы было очень долго) или сделать что-то еще до остановки цикла. Например, вы можете сначала проверить, если myArray[x] == 7, а затем вывести что-то перед тем, как поломка цикла, возможно, причина для этого. Поэтому первый метод лучше, когда ваш код является сложным.

Производительность, эти методы очень похожи.

Смежные вопросы