Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.88.33] |
|
Страницы: (7) 1 [2] 3 4 ... 6 7 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Есть статья Андрея Калинина в журнале Byte "Разумный goto" и в этом же журнале, но в последующем номере есть статья во всю хаящая Goto. Посмотри а сети.
Сам я goto использую, например при выходе из нескольких вложенных циклов. В OpenSSL часто используется в качестве обработки ошибок, например: if (ERROR_1) goto ERR_LABEL; ......... if (ERROR_n) goto ERR_LABEL; ............ return (0); ERR_LABEL: // Обработка ошибок Goto, как нам объясняли на первом курсе путает код. На самом деле часто он даже помагает читабельности. Если использовать goto в качастве циклов или if, то при нескоольких таких использованиях код может просто "умереть" - чем разобраться в ошибке в коде проще преиписать все заново. Чато код при использовании меток преобретает изящество, если не пытаться во чтобы то ни стало заменить goto на дрегие операторы. |
Сообщ.
#17
,
|
|
|
Цитата dark0ut, 06.10.03, 22:09:31 Да сабж в общем. Я не могу понять, почему так не любят оператор goto. Помню еще в школе, классе в 9-10 нам рассказали про него и тут же категорически запретили использовать. Сейчас в универе такая же фигня...Ну почему его не любят?? Это типа религии. Все говорят громкие слова и нравоучения, а сами поступают как выгодно и удобно. О наличии goto в "эталонных" C-исходниках - здесь уже сказано. В Object Pascal они замаскированы под видом exit, break, continue. В ассемблере без них и вовсе шага не сделать. Но если можно без, то лучше без. |
Сообщ.
#18
,
|
|
|
Цитата DVA, 09.10.03, 21:32:48 В Object Pascal они замаскированы под видом exit, break, continue. но в таком виде они являются куда меньшим злом, чем в первозданном. |
Сообщ.
#19
,
|
|
|
Академический вопрос: goto - это безусловный переход, и его использование вроде как дурной стиль, но if(...) goto - это уже условный переход и в его использовании ничего плохого нет?
|
Сообщ.
#20
,
|
|
|
2 WhiteWolf: Не плодите лишних сущностей (c). Пожалуй единственная причина, по которой goto плох -- появление в программе новых идентификаторов, а их надо помнить и ни с чем не спутать. Как сам понимаешь -- наличие или отсутствие if здесь ничего не меняет.
|
Сообщ.
#21
,
|
|
|
Goto в нутри одного блока {..} - я не против...
|
Сообщ.
#22
,
|
|
|
В общем, кому апельсин, а кому и свиной хрящик...
|
Сообщ.
#23
,
|
|
|
Еще:
Сколько видел "хороших" исхожников - везде goto используется только "последовательно" (не знаю как еще сказать). Тоесть имитация циклов вроде: LABEL: ......... if (...) goto LABEL; Приводит только к запутанности кода, и если возникает необходимость в таком переходе (например из вложенного блока с большой степенью вложенности), то обычно - это уже плохо спроектированный код. Я всегда использую goto ввиде, приведенном мной в пердидущем топике. |
Сообщ.
#24
,
|
|
|
LABEL:
......... if (...) goto LABEL; Предлагаю while( true ){ ... if( !... )break; } чем не красота один раз, действительно, было что без гото не вперед-не взад, а лабу завтра сдавать, ну и оставил... и как думаете, прокатило ?? НЕТ. |
Сообщ.
#25
,
|
|
|
Метки есть в ЛЮБОМ языке высокого уровня. Просто они замаскированы (так сказать, присыпаны листьями). Тот же if - чем не условный переход; while, for, repeat - без комментариев; case/switch - хотел бы посмотреть на реализацию без goto ;D
Операторы выхода из цикла типа break/continue были специально введены, чтобы не было goto. Если вообще надо выйти, например, сразу из 3-х циклов, используй функции или процедуры с exit-ом или return (в зависимости от языка). Все что можно написать с goto можно написать и без него (я говорю только про языки высокого уровня). Long live structured programming! УРА, товарищи!!! ;D ;D |
Сообщ.
#26
,
|
|
|
Изначально в лексике языков программирования использовались операторы типа if, for, goto.. Цикл можно было реализовать только параметрический с определенным шагом. Для организации циклов с "предусловием" и "постусловием" приходилось использовать структуры if .... goto. В последствии с развитием языков появилияь и с операторы циклов типа while и do и необходимость в "старом" методе организации циклов отпала сама по себе.. И на сегодняшний день необходимость в в goto осталась только в ассемблере..
P.S. Не мучайте голову.. не усложняйте чтение кода различными переходами типа goto... |
Сообщ.
#27
,
|
|
|
Вообще сложно думать наверное. Но это нужно делать, тогда будет понятно -- когда использовать goto, а когда нет.
Вот tserega пишет что мол для выхода из нескольких вложенных циклов можно определить функцию (inline я так понимаю), и юзать return. Тоже мне способ, вместо того, что бы поставить метку нужно ГДЕ_ТО_ТАМ определять функцию, которая будет вызываться ОДИН раз. Вместо того, что бы думать: "А что это за метка, и что на неё ссылается" мы будем думать: "А что это за функция и как она работает", просто супер прогресс какой то, зато без гоуту, наши духовные учителя будут нами довольны. |
Сообщ.
#28
,
|
|
|
Я имел ввиду не inline:
<br>function int aaa() {<br> ....<br><br> for (int i = 0; i < 10; i++) {<br> for (int j = 0; j < 10; j++) {<br> for (int k = 0; k < 10; k++) {<br>.......<br> return 0;<br> }<br> }<br> }<br>}<br> Есть такой критерий, показывающий насколько сложно разобраться в программе. Так вот, один за пунктов был относительно меток: опытный программист может разобраться в коде, если там не более N меток. Для каждого это N свое. Зачем усложнять себе жизнь? Подумайте на досуге над одним вопросом: почему в универах учат именно структурированное программирование, а не, допустим, Basic с переходами в каждой строчке? |
Сообщ.
#29
,
|
|
|
2tserega:
То, как учат в наших универах и институтах врятли можно взять за образец. Возьми код OpenSSL - полно goto, а ведь к нему приложил руку Стивен Хенсон - доктор MIT IMHO нельзя код бездумно дробить на функции, каждая функция должно нести ЛОГИЧЕСКУЮ (смысловую) нагрузку и просто выносить циклы в функцию из-за перехода не хорошо. |
Сообщ.
#30
,
|
|
|
Про код OpenSSL я возьму на заметку.
Неудобно читаемый код чаще всего является следствием неправильной проектировки (нехватка времени, лень и т.д.). Каждый подход имеет своих сторонников и противников (почти как борьба пользователей Windows и Linux), которые вряд ли договорятся. По крайней мере в обозримом будущем.... |