информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft предупредила о двух незакрытых... 
 Перевод Firefox на DNS over HTTPS 
 Microsoft закрыла серьёзную уязвимость,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
у goto есть только два реальных оправдания 22.11.15 15:14  Число просмотров: 5576
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
первое - группа ситуаций, которые в большинстве современных языков решается break/continue, являющимися завуалированными безопасными goto.
второе - автоматически сгенерированный код, который людям не править.
<theory>
«GOTO or not GOTO?» – эпизод очередной 22.11.15 09:43  
Автор: Vedrus <Serokhvostov Anton> Статус: Member
Отредактировано 22.11.15 09:48  Количество правок: 4
<"чистая" ссылка>
Несколько лет назад я поднимал здесь подобную тему («Оправдано ли использование GOTO в струтурированных программах?»). Такую же тему я поднимал и на других форумах. Сейчас систематизировал все все «за» и «против», вот в этой статье на хабрахабре: «GOTO or not GOTO – вот в чём вопрос». Однако технологии не стоят на месте, наверняка по вопросу GOTO существуют новые мнения. Хотелось бы обсудить их, и потом, году так в 2018 – в честь 50-летнего юбилея спора по GOTO – новое резюме представить. Итак, приглашаю в дискуссию – для последующей систематизации всех «за» и «против» относительно актуальности GOTO. Перед тем как высказаться, пожалуйста, ознакомьтесь с моей статьёй на хабрахабре, – чтобы уже существующие аргументы из обсуждения исключить.

GOTO or not GOTO – вот в чём вопрос
Оправдано ли использование GOTO в струтурированных программах?
Использование GOTO – признак кривизны кода 2(40%)
Есть ситуации, оправдывающие использование GOTO 3(60%)
Нет смысла обсуждать – единого мнения никогда не будет0(0%)
Всего:5(100%)

Для участия в голосовании необходимо зарегистрироваться
Вообще-то от языка зависит. 30.11.15 23:36  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Вообще-то от языка зависит.
Старые языки не имели конструкций, позволяющих обойтись без GOTO.
Ни на Ассемблере, ни на Фортране, ни на Бэйсике не написать что-то разумного размера и сложности (расчет по формулам не в счет) без безусловного перехода.
На Сях это реально. Правда иногда затягивает и даже простую конструкцию выхода из вложенного цикла начинаешь реализовывать хуже, чем с GOTO.
Сначала я проголосовал. Потом прочитал мнения. Теперь пишу. Потом почитаю статьи, хотя, предчувствую, что ничего нового в них не найду.

Не совсем точно поставлены вопросы для голосования.
"Использование GOTO – признак кривизны кода" - вся фишка в том, что если язвк не пзволяет без GOTO красиво написать, то это не кривизна кода, а кривизна языка.
"Есть ситуации, оправдывающие использование GOTO" - никто не будет отрицать, но это не "довод в пользу", поскольку это не противоположность предыдущему утверждению.
"Нет смысла обсуждать – единого мнения никогда не будет" - смысл есть всегда и во всем, только он может быть видим или не видим даже при тщательном его поиске.
И что самое "парадоксальное" - процессоры не могут обойтись... 30.11.15 23:51  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
И что самое "парадоксальное" - процессоры не могут обойтись без инструкций безусловного перехода.
Даже тривиальная загрузка x86 и инициализация BIOS начинается с банального far jmp по ffff:f0
GOTO бывает полезен в некоторых механизмах обработки ошибок,... 23.11.15 11:13  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 23.11.15 15:22  Количество правок: 1
<"чистая" ссылка>
GOTO бывает полезен в некоторых механизмах обработки ошибок, когда программа, вместо того, чтобы использовать throw, выставляет код ошибки в переменной и осуществляется переход на обработчик ошибок по goto. Такой механизм может быть особенно актуален в системах реального времени, когда не хочется перегружать код обработчиком исключений try/catch с раскручиванием стека и накладными расходами на call/ret.
в принципе, в большинстве случаев это эквивалентно простому вываливанию из функции с кодом ошибки 23.11.15 19:54  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> GOTO бывает полезен в некоторых механизмах обработки
> ошибок, когда программа, вместо того, чтобы использовать
> throw, выставляет код ошибки в переменной и осуществляется
> переход на обработчик ошибок по goto. Такой механизм может
> быть особенно актуален в системах реального времени, когда
> не хочется перегружать код обработчиком исключений
> try/catch с раскручиванием стека и накладными расходами на
> call/ret.

Ну вот разве что. Хотя мне сложно представить современную программу, в которой экономят на call (в плюсах, если что, можно взять inline). try/catch - да, там все запущенней, но чтобы и тут выграть на goto, нужно совершенно огромный код запихнуть в одну логическую единицу.
у goto есть только два реальных оправдания 22.11.15 15:14  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
первое - группа ситуаций, которые в большинстве современных языков решается break/continue, являющимися завуалированными безопасными goto.
второе - автоматически сгенерированный код, который людям не править.
Равно как и catch блока try является завуалированным... 23.11.15 11:03  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Равно как и catch блока try является завуалированным call(invoke) функции void catch(const exception&)
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach