информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
у goto есть только два реальных оправдания 22.11.15 15:14  Число просмотров: 8896
Автор: 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 <Денис Т.> Статус: The Elderman
<"чистая" ссылка>
И что самое "парадоксальное" - процессоры не могут обойтись без инструкций безусловного перехода.
Даже тривиальная загрузка x86 и инициализация BIOS начинается с банального far jmp по ffff:f0
GOTO бывает полезен в некоторых механизмах обработки ошибок,... 23.11.15 11:13  
Автор: Den <Денис Т.> Статус: 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 <Денис Т.> Статус: The Elderman
<"чистая" ссылка>
Равно как и catch блока try является завуалированным call(invoke) функции void catch(const exception&)
1




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


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