В 1968 году, в своей статье «Обоснование пагубности оператора goto», Эдсгер Дейкстра отметил, что качество кода обратно пропорционально количеству goto, используемых в коде. Дейкстра утверждал (это просто его мнение), что:
§ корректность кода без goto доказать легче
§ код с операторами goto трудно форматировать
§ goto влияет на логическую структуру программы
§ применение goto препятствует оптимизации, выполняемой компилятором
§ goto усложняет анализ кода
· На практике применение оператора goto, приводит к нарушению принципа хода алгоритма строго сверху вниз.
· Сторонники goto выступают за осторожное применение оператора, при определенных условиях.
· Большинство аргументов против goto, не говорит о полном отказе от этого оператора, а предостерегает от неразборчивого его использования.
· Хорошее программирование не означает исключение всех goto.
· Стремление к коду без goto не должно быть целью.
· Десятилетия исследований оператора goto не смогли подтвердить его вредоносность, а теоретические и экспериментальные доводы, выдвигаемые против этого оператора, оказались не убедительными.
· И наконец, операторы goto входят во множество современных языков.
· Microsoft чаще использует goto при автогенерации кода, когда этот код не предназначен для восприятия и редактирования человеком. Корректность такого кода определяется корректностью создающего его инструмента.
· Использование goto – это вопрос религии
Как неоднократно говорилось: "Дай дураку стеклянный хуй - он и его разобьёт и руки порежет".
Точно таким же макаром можно указатели и адресные операции запретить (что, собственно, эти ваши пехапе и прочие питоны с успехом и делают), чтобы "не дай бог не туда move сделал".
GoTo - обычный инструмент. Один из.
З.Ы. Да, иногда использую, в cmd-скриптах. И в хранимках TSQL, тоже он в тему иногда.
а зачем нужны в PHP адресные операции? есть &var и этого вполне достаточно... считай тот-же указатель, но без манипулирования адресами и смещениями типа *p++
В первом случае сначала производится инкримент потом возвращается значение переменной.
Во втором случает сначала ворачивается значение переменной потом делается инкремент.
вот наши тру программисты начитаются книжек и пишут только так
++i;
альтернативу не признают, так как она типа "медленее"
я же считаю что в данном случае одиночной операции разницы быть не может.
p.s я быдлокодер
Но когда они утверждают, что
for (int i = 0; i < MAX; ++i) {}
работает быстрее, чем
for (int i = 0; i < MAX; i++) {}
это глупость.
Иногда такое случалось. Дело было не в инкременте, а в шаблонах оптимизации, в которых были префиксные инкременты, но отсутствовали постфиксные. И в указанном выше примере 1) уничтожалось бы, а 2) крутилось с пустым телом. Ну или более приземленно - первый вариант мог бы развернуться, а второй - нет.
Но эта дичь, насколько мне известно, была лет 15-20 назад.
если на одной операции экономится наносекунда, а операций там пару миллиардов, то экономия выходит не такая и плохая
не используй CMS/фреймворки - пиши на чистом языке... никаких сторонних тяжелых библиотек, только прямые обращения с максиманой эффективностью - и ты ускоришь программу на 10 наносекунд ))
6-ой год, уже давно все на питонах, сишелах,явах пишут.
эта хрень только для компилируемых в машинный код языков имеет место
6-ой год, уже давно все на питонах, сишелах,явах пишут
где? на микроконтроллерах?
эта хрень только для компилируемых в машинный код языков имеет место
почему?
Похоже на несколько устаревший взгляд на вопрос. За почти 10 лет в разработке ни разу не натыкался на оправданное использование goto или на место, которое стало бы лучше, если goto туда добавить
Мсье плохой политик. Надо втихаря добавить goto, а потом под предлогом наличия goto выпиливать весь файл / модуль
Ну, есть у тебя двухмерный массив, и тебе его надо по строкам обрабатывать. При этом при определённом условии при обработке столбца надо выходить из обоих циклов. Как ты это нормально отрефакторишь, если не учитываем использование флага, который проверяет внешний цикл (т.к. это по сути костыль из-за отсутствия возможности)? Вынесение обоих циклов в отдельную функцию рассматривать не будем, т.к. во внутреннем цикле кроме проверки примитивная логика и особого профита от вынесения не получится
Если надо по строкам обрабатывать, то вынесу обработку строки в отдельную функцию, выход по return. Такой вариант позволит легко распараллелить обработку по принципу map/reduce, например.
Не совсем. Вынеся обработку строки в отдельную функцию, ты проблему не решишь, т.к. по return выйдешь только из цикла, который обрабатывает одну строку, что решается и break'ом. А тут суть в том, чтобы из обработчика строки завершить цикл, который по строкам идёт
А потом получается что производительность железа растет, а тормоза в по никуда не деваются.
вот-вот... люди используют всякие тяжелейшие CMS/фреймворки с кучей ненужного мусора внутри, но экономят наносекунды на циклах.
cmd-shell. Большой скрипт с мало-мальским наличием логических ветвлений без goto не напишешь.
И не надо про PowerShell рассказывать, 20 лет назад его не было. И альтернативы cmd - тоже.
20 лет назад его не было. И альтернативы cmd - тоже.
Perl появился в 1987 году, если что. И по удивительному совпадению, с 1997 года появилась версия для Windows.
Проблема ведь не в самом скриптовом языке как таковом, их овер9000 есть. Проблема их на голой винде развернуть.
Условно говоря, твоя система должна уметь полностью разворачиваться путём запуска одного файла.
Собственный инсталлер винды можно было со времён OSR2 запилить, и уж загнать туда интерпретатор вообще не проблема. Или скопировать с носителя, с которого на голую винду батник попадает. Вариантов много, отмазок ещё больше.
Тем более, что задач применения там дофига было. Те же бэкапы системы по расписанию, с последующим копированием-архивированием-прожигом.
Только потому, что в нем наличие goto суровая необходимость?
в switch/case внутри тот-же goto будет...
* и вообще это уже и не актуально )
** goto просто делает код запутанным, поэтому и считался нежелательным оператором ранее.
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору