Все вот говорят, что мол нельзя юзать goto - Небезопасно это.
Но сами юзают switch. Ведь он, по сути пострен на goto принципе.
Ваше мнение и что обычно юзаете: switch/case или if/else ?

все юзаем

До обсурда опускаться не будем, ладно? Естественно, что if/else - неотъемлемая часть. Я имею виду, когда у вас некая переменная может иметь несколько значений и вы должны по каждому из них произвести соответствующие действия.

фигасе!

Юзаю иногда...
Но обычно роль switch-а в моих программах выполняет таблица виртуальных функций

Кто - "все" ? Я вот не говорю. Вообще goto редко, но юзаю, ибо есть некоторые моменты, когда с goto самый красивый вариант. То же с switch/case



Это сообщение отредактировал(а) GrayCardinal - 25.4.2008, 09:54

Я тоже раньше думал что глобальные переменные - это нормально и ничего зазорного.

Rickert, 
СЛушай, добрый совет забей ты на шаблонное мышление. Тебе надо ? Так пиши хоть goto, хоть глобальные переменные. Вон хлопцы написали Perl 6 (Pugs) на Haskell и сидят - торчат, какие мы крутые, А вы тут про гооту и глобальные переменные   

Это сообщение отредактировал(а) GrayCardinal - 25.4.2008, 10:16

вообще, самое красивое применение goto я видел в совокупности с применением расширения компилятора gcc
что-то вроде этого

в каждом из stateX state изменяется по определенному алгоритму
перепишите ка этот пример без goto   
число переходов недетерминировано (т. е мы не знаем сколько раз будет выполняться goto *jumps[state])

Это сообщение отредактировал(а) MAKCim - 25.4.2008, 10:32

Не нельзя, а нежелательно. 

 А небезопасно потому, что "goto "  [goto label1]

label4:  Поэтому вместо того чтоб его использовать  [goto label5]
label1: не вкладывается в стиль языка   [goto label2]
label3: и затрудняет понимание ее же для самого же программиста   [goto label4]
label2: "давит" конструкцию программы   [goto label3]
label5: лучше и легче перефрзировать мысль 

Что вышеперечисленное  будет выглядеть без "goto"  приятнее, я думаю, спорить не будешь )) 

Бывают и красивые решения с "goto" - но человек должен хорошо чуствовать что он хочет.
A если он знает - то ему запреты и не нужны, но если бы не было бы "запретов" то многие  бы вместо того чтоб сформулировать мысль писали бы кучу goto.


так и return на том же принципе основон - только ты не в те принципы глядишь. Реализация команд на машинном языке не имеет никакого отношения к принципам  высокоуровневого языка . 


если надо проверить состояния одного объекта то "switch"
если другие условия то " if ".




Это сообщение отредактировал(а) mes - 25.4.2008, 10:27

Ага, спасибо за совет, я последнии несколько лет его придерживался, пока не понял что за деньги платят.

+1   

не совсем понял что делает этот код. дай угадаю. наверное что-то типа этого:

Mayk, 
я уже не помню, где я это видел (код мой, он просто принцип показывает)


нет
это просто динамический конечный автомат

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

А мне из-за шаблонного мышления пришлось отказаться от такого варианта:


к такому


И до сих пор меня терзают смутные сомнения, все время задаю себе вопрос: "На машинном уровне это jmp/loop + dec eax + cmp eax,N. Т.е. 3 долгих операции вместо одного jmp'a... Нафига мне оно надо было ? Из-за шаблонного мышления!

1. Никогда не думай, что ты лучше компилятора знаешь какие машинные комманды нужны - если все же лучше то пиши на асме
2. выход из "goto" все равно будет по проверке значения - так что от проверки ты не избавишься
3.  в твоем примере  воoбше не понятен смысл - но скорей всего ты неправильную конструкцию подобрал раз тебя терзают сомнения ))

Добавлено @ 11:05

Так ?


Это сообщение отредактировал(а) mes - 25.4.2008, 11:09

Попробую объяснить по памяти. Есть ряд чисел:

1,2,3,2,4,5,1,4

Задача: сгруппировать одинаковые цифры таким образом, чтобы получилось:

1,1
2,2
3
4,4
5

Т.е. объединить одинаковые цифры.

Внутри цикла for который выполняется 8 раз на каждую цифру приходится неизвестное количество проходов, неизвестное потому, что мы заранее не знаем какое количество совпадений будет в массиве.

Т.е. берем цифру 1 и в цикле goto проходим дальше по всему массиву начиная с 2 до тех пор пока не встретится 1 (предпоследняя).

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

что нет? покажи полностью небольшой пример когда контструкцию с goto *[] нельзя свести к switch/case.


зависит от оптимизатора компилятора. Некоторые вполне за О(1) перепрыгнут куда надо.

Добавлено через 1 минуту и 43 секунды

причем тут goto? это  простейшя задача для std::map'а или аналоигчной контсрукции

У меня в коде используются continue и break. Я точно не могу сказать что именно произойдет в этой ситуации, если с помощью continue/break я должен управлять циклом for, а не while: 





Я логику сократил, чтобы было яснее. На самом деле там массив из неизвестного количества столбцов, если все цифры во всех столбцах совпадают со всеми цифрами в других строках, то эти строки надо объединять. При этом есть еще ряд условий, которые не позволяют объединить цифры в строках, т.к. строки имеют разные ключи. В общем тут ничем кроме как многоэтажными for'aми и if'aми не обойтись.



Соотв строки 1, 4, 6 объединяются.

Это сообщение отредактировал(а) SABROG - 25.4.2008, 11:34

Ну вот в том то и дело. Если нет чего-то типа ::continue и ::break, то получается нужен goto вместо while.

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

 в том случае если состояние является константой на момент компиляции. 
в приведенных примерах с goto  состояние определяется в рантайме


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


Это сообщение отредактировал(а) mes - 25.4.2008, 11:57

 Если так рассуждать, все конструкции изменения хода выполнения в принципе построены на goto. goto - основополагающий принцип и остро отточенный инструмент. есть ситуации, когда более высокоуровневые конструкции менее кратки, удобны и понятны. но их совсем немного, как правило - наоборот.
по теме: больше 2х if/else наводят на мысль о switch. Кстати, switch может быть построен более эффективно, чем набор if: массив адресов перехода плюс всего одно сравнение и собственно переход. Т.е. фактически тот же jumps, что у MAKCim, только метки не изменяются.

Rickert, попробуй понять, почему так говорят. А выводы делай самостоятельно.

пипец вы развели, лучше пусть будет жрать больше времени CPU чем времени программиста, разбирающегося в этом коде. 
Насчет примера выше, то что написано у Майка просматривается за 3 секунды и приходит понимание. То что написано у Максима,я не понял до сих пор. goto ухудшает восприятие кода. А уж отказываться от свитча, это по моему маразм. Если у переменной много состояний то свитч, если мало то if'ы, я так считаю.

неа, если например case-ы - целые значения идущие по порядку, то смещение может быть вычислено вместо проверки всех условий, либо смещение берется из таблицы, либо просто вычисляется.
Недаром в синтаксисе языка такие ограничения на аргумент конструкции swtch

А меня не наводит из-за ограничения в том, что значение которое сравниваешь должно быть константной:



Да и goto - got'e рознь. В ассемблере мне известны следующие механизмы для перехода по адресам:

int'ы - прерывание
retn'ы - возврат, при желании можно изменить значения в стеке, чтобы ретурны использовались вместо callов
call'ы - тут все понятно, адрес возврата пихается в стек и происходит переход
jmp'ы/ja/jz/jb и т.д. - аналогично call'у, разве что one way.
loop'ы - условный переход, где условие - значение в регистре cx/ecx.

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

В программирование как в реале не стоит экономить время на не экономном.
Что лучше обойти большую лужу или сэкономить две секунды и пройти насквозь?
Все зависит от нескольких факторов:
1 критичность времени на данной момент
2. периметр против  глубины и "чистоты" лужи 
3. наличие подходящей обуви.
4 ...
И если все таки решились пройти сквозь лужу надо не забывать о том что она скрываетоткрытый люк - выбраться из которого далеко не просто. ))




Это сообщение отредактировал(а) mes - 25.4.2008, 12:27

а не проще разгрузить такое большое кол-во однотипных операций - самому же дышать легче будет.

к примеру так

тогда код выглядить будет примерно так

SABROG, код ужаснул меня...

Меня самого он ужасает, иногда прежде чем думать про оптимизацию сначала стоит задача сделать так, чтобы работало хоть как-то, чтобы понять в правильном вообще направлении я иду или нет. Уже 2 раза переписывал ядро программы. Причем иногда очевидные вещи даже в голову не приходят.


Если бы там были только текстовые данные, так там ведь может быть что угодно вообще. Одним toString() не обойдешься. Там и toDouble, и toUInt(), и toInt(). Причем в некоторых случаях int надо преобразовывать в указатель. По сути под каждый уникальный параметр (не тип!) свое действие.

Это сообщение отредактировал(а) SABROG - 25.4.2008, 14:01

смотри в сторону перегрузки метода

Добавлено через 2 минуты и 12 секунд

 в данном примере не оптимизация, а построение логики

Смотрел и шаблоны смотрел. Не особо меня радует это. Сделал вариант со свичем: 

P.S. для уникальных типов - уникальные операции
P.S.S кстати насчет строковых имен - я бы посоветовал бы использовать вместо них строковые константы 
Преимушества:
1. при опечатке компилятор заметит
2. при смене имени ключа не стоит переживать что где то  в теле завбудешь исправить имя
3. переменная может быдь названа более удобным способом -(например если ключ слишком длинный)
4. и многое другое))

ну ты и намудрил! но обсуждать здесь совесть не позволяет и так ушли от темы .
Если хочешь выслушать предложения заведи другую тему ))

Мда... Читать, если честно, ужасно  Рефакторить надо  

ЗЫ Функции больше 15 строчек есть зло!

ты не прав, есть ф-ии где по другому не обойтись. Да и в большинстве своем они больше 15 строчек...

значит функции злые - не всем же им добрыми быть))

Экстрактить в отдельный метод 

Это когда получается. А бывает, что надо заводить структуры на 5-10 параметров... ага. И в итоге код получается в два раза больше... и ни фига не понятнее.

И вообще, не надо впадать в крайности. Согласен, код функции, занимающий более 15-20 строчек, вызывает напряги. Но иногда невозможно разделить большую функцию на несколько маленьких (например, контекст огромный). Так же и с goto - в большинстве случаев он не нужен, но иногда (выход из вложенного цикла, например) он предпочтителен, так как и быстрей, и наглядней, по моему.

так может быть переполнение стека


замени в моем предыдущем примере статический массив динамическим   


чем больше состояний, тем больше среднее время выполнения одной итерации


наводит на мысль о двоичном поиске в таком случае, но не об O(1)
т. е 

и number = 4

при "тупой" реализации switch/case нужно 5 проверок
при реализации двоичного поиска 2-3
но никак не 1
соответственно число сравнений возрастает с увеличением числа case

Добавлено через 3 минуты и 39 секунд

смотря кто писАл код   


Это сообщение отредактировал(а) MAKCim - 25.4.2008, 20:40

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

не совсем понял .. что именно вызывает переполнение в отличие от "оригинального" примера?

да
и получим все тот же мой пример, только в неявном виде
+ у меня state не константен

Добавлено через 5 минут и 30 секунд

в оригинальном примере
state не константен и вычисляется динамически
т. е не обязательна последовательность state1() -> state2() -> state3()
+ state3() не обязательно пуст
в этом случае можем получить длинную цепочку вызовов, что приведет в конечном итоге к переполнению
если брать ваш  код в том виде, в котором он есть, переполнения, конечно, не будет
но он и не эквивалентен моему

так я просто для примера сделал его статическим )) 
под приравниваем подразумевалась определеная операция над состоянием результатом которой неизвестное на этап компиляции значение


у по идеи одно значение состояние  должно быть выходом из автомата


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

Это сообщение отредактировал(а) mes - 25.4.2008, 21:54

не обязательно
инвариант выхода может формироваться не только по state

ну а теперь?


Добавлено через 2 минуты и 7 секунд
P.S. inline функций в данном примере компилятор должен произвести сам ..

mes, 
а если в каждой из stateX требуется контекст Run()?
тащить его в каждую stateX? расточительно...

Это сообщение отредактировал(а) MAKCim - 25.4.2008, 22:29

1 контекст является глобальным окружением - (как и в примере с goto)
2. все это дольно быть классом и функции обслуживающие состояния являются его  членами
3. этот автомат обслуживает  сторонюю структуру данных - тогда придется ее передавать как параметр
4 или функции обслуживаюшие состояния являются внешними по отношению классу - тогда придется передавать себя как параметр
. 
P.S. если функции заинлайнятся, то  даже этих расходов на передачу параметров не будет.


Это сообщение отредактировал(а) mes - 26.4.2008, 09:54

Почему мои последние топики такие провакационные? Вроде спросил простую вещь  

Талант наверное.   

Резюмируя:

Без разницы, главное, что-бы в данном конкретном случае это хорошо читалось другими программистами. 
а столько многабукаф из-за того, что здоровенный switch- это как правило признак ошибки в проектировании... вот..

Это сообщение отредактировал(а) Lazin - 26.4.2008, 18:10

другие программисты не при чем - чтоб сам смог понять что там написано (спустя некоторое время) и было на душе приятно что нету костылей и заплаток..

В этом всё и дело, Rickert, чем проще вопрос ­— тем больше на него ответов. Это давно так     

solved  

Конечно switch. Но согласяться все, что без if/else порой ну никак не обойдись. Ну, или по крайней мере в некоторых случаях(местах) if/else использовать удобнее. 

вообще-то, switch/case довольно редко используемая конструкция (речь не о любителях Win32API) по сравнению в if/else.

А конструкция:



еще реже...

у меня так чаще, чем switch/case 

Аналогично

Паттерн Strategy рулед!

гг шучу