Вход на сайт
Оператор goto в языках программирования.
NEW 02.02.12 14:48
Мне нравится это девиз.
По крайней мере он многое объясняет.
Сразу другой девиз: всегда думай также о других кодерах, чтобы они не остались без работы, если твоя программа будет работать без ошибок.
Райское наслаждение
в ответ except 02.02.12 14:33
В ответ на:
Девиз кодера - все, что с такими мучениями было написано, должно так же мучительно читаться.
Девиз кодера - все, что с такими мучениями было написано, должно так же мучительно читаться.
Мне нравится это девиз.
По крайней мере он многое объясняет.Сразу другой девиз: всегда думай также о других кодерах, чтобы они не остались без работы, если твоя программа будет работать без ошибок.
В ответ на:
Я драйвера никогда не писал.
Я драйвера никогда не писал.
Райское наслаждение
NEW 02.02.12 16:59
на этапе инициализации это не играет никакой роли
если процедура вызовется всего один раз, чтобы инициализировать функцию, то её можно объявить inline. скорее всего, компилятор её сам запикает как inline.
нет. это не не ручная работа со стеком, это в данной ситуации просто самый приямой способ реализации алгоритма. точка.
откатываться надо в обратном порядке. с помощью исключений это можно сделать, оперируя переменные-флаги. и вот тут уже плодим лишнюю сущность
goto - в данном месте способ написать наиболее ровно. правильности он не гарантирует (как и собственно не гарантирует правильности любой из языков программирования, какие бы они ни были продвинутые). goto - это инструмент, который должен быть задействован соответсвующим образом, а не абы-как
дейкстра был прав, но только его высказывания касались устаревшего уже к тому времени языка паскаля, а не новых языков. в случае с си - его его тем более нельзя воспринимать, как догму, потому что очень быстро можно наступить на грабли.
в ответ svnv 02.02.12 13:40
В ответ на:
1. Это несколько дороже (что для драйверов важно).
1. Это несколько дороже (что для драйверов важно).
на этапе инициализации это не играет никакой роли
В ответ на:
2. Процедура ничего не должна знать о внешнем контексте (ведь ее могут вызвать откуда угодно). В Си это конечно легко обойти (что собственно и делается), но это будет нарушение логики, поэтому всю эту логику и забивают в одну длинную процедуру.
2. Процедура ничего не должна знать о внешнем контексте (ведь ее могут вызвать откуда угодно). В Си это конечно легко обойти (что собственно и делается), но это будет нарушение логики, поэтому всю эту логику и забивают в одну длинную процедуру.
если процедура вызовется всего один раз, чтобы инициализировать функцию, то её можно объявить inline. скорее всего, компилятор её сам запикает как inline.
В ответ на:
3. Процедура это уже совершенно конкретный способ работы со стеком, а значит других быть не должно быть. Если мы хотим сами ковыряться в стеке, то значит процедуры лучше не использовать. Если используем процедуры, то не надо работать со стеком вручну.
3. Процедура это уже совершенно конкретный способ работы со стеком, а значит других быть не должно быть. Если мы хотим сами ковыряться в стеке, то значит процедуры лучше не использовать. Если используем процедуры, то не надо работать со стеком вручну.
нет. это не не ручная работа со стеком, это в данной ситуации просто самый приямой способ реализации алгоритма. точка.
В ответ на:
Я бы назвал это ручным управлением структурой стека, но при чем тут исключения? Это обычная логика почти любой программы. Что тут особенного? Что какое-то событие может произойти в разных частях, а обработать его (например, откатиться) хочется только в одной точке?
Я бы назвал это ручным управлением структурой стека, но при чем тут исключения? Это обычная логика почти любой программы. Что тут особенного? Что какое-то событие может произойти в разных частях, а обработать его (например, откатиться) хочется только в одной точке?
откатываться надо в обратном порядке. с помощью исключений это можно сделать, оперируя переменные-флаги. и вот тут уже плодим лишнюю сущность
В ответ на:
И почему ручной способ является однозначным и стройным? Если это ручное управление, то все зависит от того, кто написал. Один напишет криво, другой ровно. В этом и проблема goto (как и любых низкоуровневых операций), что он не гарантирует правильности и легко ведет к ошибкам.
И почему ручной способ является однозначным и стройным? Если это ручное управление, то все зависит от того, кто написал. Один напишет криво, другой ровно. В этом и проблема goto (как и любых низкоуровневых операций), что он не гарантирует правильности и легко ведет к ошибкам.
goto - в данном месте способ написать наиболее ровно. правильности он не гарантирует (как и собственно не гарантирует правильности любой из языков программирования, какие бы они ни были продвинутые). goto - это инструмент, который должен быть задействован соответсвующим образом, а не абы-как
В ответ на:
Так что еще раз: goto не имеет большого отношения к исключениям. Исторически, раньше были только jmp, и все мыслили в терминах перехода. Соответственно, (дураки) его автоматически перетащили в новые высокоуровненвые языки в виде goto. А далее пришел Дейкстра и сказал, что все вокруг козлы и goto не нужел. Если бы это не был Дейкстра, то его бы забили камнями, поскольку это было как серпом по яйцам. Вот и все. А исключения здесь при том, что goto можно использовать, для ручной организации внутренней структуры программы (без структуризации с помощью процедур). А далее эта структура может использоваться для реализации определенных логических паттернов, типа когда обработчики ситуаций имеют лейблы, переход к которым осуществляется по goto из разных точек программы. Даже если мы назывем это механизмом исключений, то goto это всего лишь один из способов его реализации.
Так что еще раз: goto не имеет большого отношения к исключениям. Исторически, раньше были только jmp, и все мыслили в терминах перехода. Соответственно, (дураки) его автоматически перетащили в новые высокоуровненвые языки в виде goto. А далее пришел Дейкстра и сказал, что все вокруг козлы и goto не нужел. Если бы это не был Дейкстра, то его бы забили камнями, поскольку это было как серпом по яйцам. Вот и все. А исключения здесь при том, что goto можно использовать, для ручной организации внутренней структуры программы (без структуризации с помощью процедур). А далее эта структура может использоваться для реализации определенных логических паттернов, типа когда обработчики ситуаций имеют лейблы, переход к которым осуществляется по goto из разных точек программы. Даже если мы назывем это механизмом исключений, то goto это всего лишь один из способов его реализации.
дейкстра был прав, но только его высказывания касались устаревшего уже к тому времени языка паскаля, а не новых языков. в случае с си - его его тем более нельзя воспринимать, как догму, потому что очень быстро можно наступить на грабли.
NEW 02.02.12 17:59
Не буду мешать вашему самовосхвалению.
а как быть с проектами, которые "растут". вам платят за то, что вы по идейным соображением перепишете рабочий и оттестированый кусок кода только потому, что так требует ваша религия?
из всего поста, 90% которого занимают только ваши самовосхваления, я не увидел ни одной ценной для себя информации
в ответ Murr 02.02.12 12:55
В ответ на:
У меня с одним из шефов был серьезный спор именно по данному вопросу.
Он мужик умный, но ему не всегда хватает времени сделать не как сделает,
У меня с одним из шефов был серьезный спор именно по данному вопросу.
Он мужик умный, но ему не всегда хватает времени сделать не как сделает,
Не буду мешать вашему самовосхвалению.
В ответ на:
- аллоцирования tty
- деаллоцирования tty
- подвязки tty к системе
- отвязки tty от системы
- валидации tty
и порядок их использования.
Если этих методов не хватит - опять таки посмотреть если среди требуемого
парные операции и так их и имплементировать. А танцы с бубном - нафиг-нафиг...
- аллоцирования tty
- деаллоцирования tty
- подвязки tty к системе
- отвязки tty от системы
- валидации tty
и порядок их использования.
Если этих методов не хватит - опять таки посмотреть если среди требуемого
парные операции и так их и имплементировать. А танцы с бубном - нафиг-нафиг...
а как быть с проектами, которые "растут". вам платят за то, что вы по идейным соображением перепишете рабочий и оттестированый кусок кода только потому, что так требует ваша религия?
В ответ на:
Количество строк уменьшится, если будет видна логика процесса и тот кто
пишет код понимает что он делает. На моей практике 29к сишного кода
ужались до 16 строк кода и таблицы с данными. При этом Я практически
ничего не сделал - только заменил написанный с использованием конструкций
языка автомат на его эквивалент в данных и простую процедуру изменения
состояния.
Количество строк уменьшится, если будет видна логика процесса и тот кто
пишет код понимает что он делает. На моей практике 29к сишного кода
ужались до 16 строк кода и таблицы с данными. При этом Я практически
ничего не сделал - только заменил написанный с использованием конструкций
языка автомат на его эквивалент в данных и простую процедуру изменения
состояния.
из всего поста, 90% которого занимают только ваши самовосхваления, я не увидел ни одной ценной для себя информации
NEW 02.02.12 19:06
в ответ swar0g 02.02.12 16:59
это в данной ситуации просто самый приямой способ реализации алгоритма.
goto - в данном месте способ написать наиболее ровно
-----
Да разве? И что, нет идеи как можно спрямить налепленную хрень? Правда нету?
А у меня где-то таки есть... причем точно знаю, что вся "сложная" процедура
упакуется, станет прозрачной и полностью управляемой... Мало того - код
процедуры, в части аллокации и освобождения, перестанет меняться при
изменениях...
откатываться надо в обратном порядке.
-----
А MCB-ишки или их аналоги уже отменили?
Ну даже если и отменили, то что именно заставляет освобождать память именно
в обратном порядке? Последний раз такое утверждалось для ДОС 3.20. Но там
это было оправдано - блоки не освобождались, а присоединялись к ближайшему
занятому, если таковой имелся...
с помощью исключений это можно сделать, оперируя переменные-флаги.
-----
Эээ... не знаю как это комментировать...
goto - в данном месте способ написать наиболее ровно
-----
Да разве? И что, нет идеи как можно спрямить налепленную хрень? Правда нету?
А у меня где-то таки есть... причем точно знаю, что вся "сложная" процедура
упакуется, станет прозрачной и полностью управляемой... Мало того - код
процедуры, в части аллокации и освобождения, перестанет меняться при
изменениях...
откатываться надо в обратном порядке.
-----
А MCB-ишки или их аналоги уже отменили?
Ну даже если и отменили, то что именно заставляет освобождать память именно
в обратном порядке? Последний раз такое утверждалось для ДОС 3.20. Но там
это было оправдано - блоки не освобождались, а присоединялись к ближайшему
занятому, если таковой имелся...
с помощью исключений это можно сделать, оперируя переменные-флаги.
-----
Эээ... не знаю как это комментировать...
02.02.12 19:44
в ответ swar0g 02.02.12 17:59
а как быть с проектами, которые "растут".
------
А что это меняет?
Ну есть "растущий" проект.
Пусть даже меняется размер tyy, других структур и их организация.
Вынеси логику размещения/освобождения памяти в данные и выполни
имплементацию процедур, используя данные для актуального управления
памятью - проблема "роста" просто исчезнет...
Правда появится другая проблема - большинство кодеров будет не в состоянии
модернизировать "код" в силу непонимания методики...
вам платят за то, что вы по идейным соображением перепишете рабочий и оттестированый кусок кода только потому, что так требует ваша религия?
------
Мне частенько платят за изготовление говнокода, к которому есть всего два требования:
1. Он должен быть условно-рабочим. Т.е. "не падать" в не предсказуемых местах.
2. Он должен быть написан в кратчайшие сроки. Мягко говоря - 10-12 мегабайт в день...
В других случаях, мне платят за то, Я беру кусок глючного кода и делаю из него
условно-рабочий код. Как - обычно не спрашивают, но хотят быстро...
Но наиболее полезным использованием меня является не кодинг, а гоняние молодых,
полных сил и здоровья, говнокодеров, с целью подвинуть оных на имплементацию
того, об чем они не слыхали до этого. Частенько это включает "переписывание", а
точнее - замену, рабочего, оттестированного, но переставшего решать поставленную
задачу кода, на другой, в зависимости от условий, более компактный, производительный
и устойчивый... Как правило - получается неплохо.
я не увидел ни одной ценной для себя информации
-----
Ну значит тебе не надо - продолжай думать об организации логики с использованием
гото... в том месте где оно, по моему разумению, совсем не нужно.
------
А что это меняет?
Ну есть "растущий" проект.
Пусть даже меняется размер tyy, других структур и их организация.
Вынеси логику размещения/освобождения памяти в данные и выполни
имплементацию процедур, используя данные для актуального управления
памятью - проблема "роста" просто исчезнет...
Правда появится другая проблема - большинство кодеров будет не в состоянии
модернизировать "код" в силу непонимания методики...
вам платят за то, что вы по идейным соображением перепишете рабочий и оттестированый кусок кода только потому, что так требует ваша религия?
------
Мне частенько платят за изготовление говнокода, к которому есть всего два требования:
1. Он должен быть условно-рабочим. Т.е. "не падать" в не предсказуемых местах.
2. Он должен быть написан в кратчайшие сроки. Мягко говоря - 10-12 мегабайт в день...
В других случаях, мне платят за то, Я беру кусок глючного кода и делаю из него
условно-рабочий код. Как - обычно не спрашивают, но хотят быстро...
Но наиболее полезным использованием меня является не кодинг, а гоняние молодых,
полных сил и здоровья, говнокодеров, с целью подвинуть оных на имплементацию
того, об чем они не слыхали до этого. Частенько это включает "переписывание", а
точнее - замену, рабочего, оттестированного, но переставшего решать поставленную
задачу кода, на другой, в зависимости от условий, более компактный, производительный
и устойчивый... Как правило - получается неплохо.
я не увидел ни одной ценной для себя информации
-----
Ну значит тебе не надо - продолжай думать об организации логики с использованием
гото... в том месте где оно, по моему разумению, совсем не нужно.
<--- nobody harmed in this
action -->
NEW 02.02.12 20:53
функция отлично читается и вполне прозрачна. сходу
здесь ядро, здесь имеет место не только освобождения памяти, но и инициализация/деинициализация оборудования (например, изменение pci регистров). как его деинициализировать, если на структуру, описывающую состояние оборудования, уже напустили free()/ ещё раз говорю, если вам так тяжело понять - здесь выполнение операций, зависимых друг от друга и от порядка их выполнения как в одну, так и в другую сторону. но ты же не читатель.
если бы знания позволяли бы, то знал бы
а если меняется апи?
понятно, завернём нашу писанину через какую-нить жопу, обзовём всех дураками, вплоть до своего начальника и будем гордиться достигнутым
голословные утверждения, с учётом того, что было тобой выше сказано - ещё более невероятные
хорошо. как ты эффективно выполнишь stack based unrolling?
в ответ Murr 02.02.12 19:06
В ответ на:
Да разве? И что, нет идеи как можно спрямить налепленную хрень? Правда нету?
А у меня где-то таки есть... причем точно знаю, что вся "сложная" процедура
упакуется, станет прозрачной и полностью управляемой... Мало того - код
процедуры, в части аллокации и освобождения, перестанет меняться при
изменениях...
Да разве? И что, нет идеи как можно спрямить налепленную хрень? Правда нету?
А у меня где-то таки есть... причем точно знаю, что вся "сложная" процедура
упакуется, станет прозрачной и полностью управляемой... Мало того - код
процедуры, в части аллокации и освобождения, перестанет меняться при
изменениях...
функция отлично читается и вполне прозрачна. сходу
В ответ на:
А MCB-ишки или их аналоги уже отменили?
Ну даже если и отменили, то что именно заставляет освобождать память именно
в обратном порядке? Последний раз такое утверждалось для ДОС 3.20. Но там
это было оправдано - блоки не освобождались, а присоединялись к ближайшему
занятому, если таковой имелся...
А MCB-ишки или их аналоги уже отменили?
Ну даже если и отменили, то что именно заставляет освобождать память именно
в обратном порядке? Последний раз такое утверждалось для ДОС 3.20. Но там
это было оправдано - блоки не освобождались, а присоединялись к ближайшему
занятому, если таковой имелся...
здесь ядро, здесь имеет место не только освобождения памяти, но и инициализация/деинициализация оборудования (например, изменение pci регистров). как его деинициализировать, если на структуру, описывающую состояние оборудования, уже напустили free()/ ещё раз говорю, если вам так тяжело понять - здесь выполнение операций, зависимых друг от друга и от порядка их выполнения как в одну, так и в другую сторону. но ты же не читатель.
В ответ на:
Эээ... не знаю как это комментировать...
Эээ... не знаю как это комментировать...
если бы знания позволяли бы, то знал бы
В ответ на:
А что это меняет?
Ну есть "растущий" проект.
Пусть даже меняется размер tyy, других структур и их организация.
Вынеси логику размещения/освобождения памяти в данные и выполни
имплементацию процедур, используя данные для актуального управления
памятью - проблема "роста" просто исчезнет...
А что это меняет?
Ну есть "растущий" проект.
Пусть даже меняется размер tyy, других структур и их организация.
Вынеси логику размещения/освобождения памяти в данные и выполни
имплементацию процедур, используя данные для актуального управления
памятью - проблема "роста" просто исчезнет...
а если меняется апи?
В ответ на:
Правда появится другая проблема - большинство кодеров будет не в состоянии
модернизировать "код" в силу непонимания методики...
Правда появится другая проблема - большинство кодеров будет не в состоянии
модернизировать "код" в силу непонимания методики...
понятно, завернём нашу писанину через какую-нить жопу, обзовём всех дураками, вплоть до своего начальника и будем гордиться достигнутым
В ответ на:
В других случаях, мне платят за то, Я беру кусок глючного кода и делаю из него
условно-рабочий код. Как - обычно не спрашивают, но хотят быстро...
Но наиболее полезным использованием меня является не кодинг, а гоняние молодых,
полных сил и здоровья, говнокодеров, с целью подвинуть оных на имплементацию
того, об чем они не слыхали до этого. Частенько это включает "переписывание", а
точнее - замену, рабочего, оттестированного, но переставшего решать поставленную
задачу кода, на другой, в зависимости от условий, более компактный, производительный
и устойчивый... Как правило - получается неплохо.
В других случаях, мне платят за то, Я беру кусок глючного кода и делаю из него
условно-рабочий код. Как - обычно не спрашивают, но хотят быстро...
Но наиболее полезным использованием меня является не кодинг, а гоняние молодых,
полных сил и здоровья, говнокодеров, с целью подвинуть оных на имплементацию
того, об чем они не слыхали до этого. Частенько это включает "переписывание", а
точнее - замену, рабочего, оттестированного, но переставшего решать поставленную
задачу кода, на другой, в зависимости от условий, более компактный, производительный
и устойчивый... Как правило - получается неплохо.
голословные утверждения, с учётом того, что было тобой выше сказано - ещё более невероятные
В ответ на:
Ну значит тебе не надо - продолжай думать об организации логики с использованием
гото... в том месте где оно, по моему разумению, совсем не нужно.
Ну значит тебе не надо - продолжай думать об организации логики с использованием
гото... в том месте где оно, по моему разумению, совсем не нужно.
хорошо. как ты эффективно выполнишь stack based unrolling?
NEW 02.02.12 21:59
в ответ swar0g 02.02.12 20:53
функция отлично читается и вполне прозрачна. сходу
------
Гений чтения сишного кода... а вот мне, после лет этак 15-ти отсутствия практики,
как-то так не показалось...
а если меняется апи?
------
Ну и? Ну поменялось. Что дальше? Перестало требоваться последовательное выделение
и обратное освобождение памяти? Нет?!! - значит будет замен набор управляющих данных,
а код останется без изменений - в нем, по условию, нет смеси операций - только управление
выделением и освобождением памяти...
здесь ядро
-----
Да-да... поэтому там "нельзя" перевести написанный код в релевантную машину состояний
и упростить все до безобразия... просто из-за того что, гото там не обходится, а по-другому
решение вообще не видится... хи-хи-кс...
понятно, завернём нашу писанину
-----
Об этом тебе и говорится - не понимаешь - не берись...
Последний раз Я это проделал с одной молоденькой китаянкой. Девочка была оооочень смарт,
но как и все западные - недоучена. Была поставлена писать небольшой сервис и она нарисовала
что-то похожее на "код ядра"... и уперлась в неуправляемость при расширении, что было основным
условием работы сервиса.
После этого в три приема была обучена тому что требовалось, уловила суть, написала драфт, после
анализа - поправила недоработку. Код - работает, расширяется модульно, без перестроения сервиса,
об проблемах - вообще не сообщалось... да их там и быть не может - код - простой и его совсем
не много, много меньше, чем нормальный прогер может удержать в мозгах.
как ты эффективно выполнишь stack based unrolling?
-----
Запущу автомат в обратном порядке... если этого будет недостаточно - заменю управляющий
набор на релевантный, позволяющий сделать нужную работу - прокрутить автомат а обратном
порядке...
------
Гений чтения сишного кода... а вот мне, после лет этак 15-ти отсутствия практики,
как-то так не показалось...
а если меняется апи?
------
Ну и? Ну поменялось. Что дальше? Перестало требоваться последовательное выделение
и обратное освобождение памяти? Нет?!! - значит будет замен набор управляющих данных,
а код останется без изменений - в нем, по условию, нет смеси операций - только управление
выделением и освобождением памяти...
здесь ядро
-----
Да-да... поэтому там "нельзя" перевести написанный код в релевантную машину состояний
и упростить все до безобразия... просто из-за того что, гото там не обходится, а по-другому
решение вообще не видится... хи-хи-кс...
понятно, завернём нашу писанину
-----
Об этом тебе и говорится - не понимаешь - не берись...
Последний раз Я это проделал с одной молоденькой китаянкой. Девочка была оооочень смарт,
но как и все западные - недоучена. Была поставлена писать небольшой сервис и она нарисовала
что-то похожее на "код ядра"... и уперлась в неуправляемость при расширении, что было основным
условием работы сервиса.
После этого в три приема была обучена тому что требовалось, уловила суть, написала драфт, после
анализа - поправила недоработку. Код - работает, расширяется модульно, без перестроения сервиса,
об проблемах - вообще не сообщалось... да их там и быть не может - код - простой и его совсем
не много, много меньше, чем нормальный прогер может удержать в мозгах.
как ты эффективно выполнишь stack based unrolling?
-----
Запущу автомат в обратном порядке... если этого будет недостаточно - заменю управляющий
набор на релевантный, позволяющий сделать нужную работу - прокрутить автомат а обратном
порядке...
<---
nobody harmed in this action -->