Дорогие дамы и господа. Вас с измальства в институтах изматывали мантрой, касаемой программированием. И как религиозную догму вдалбливали, что оператором goto пользоваться ни в коем случае нельзя. Задумывались ли вы вообще над тем, что вам преподавали, или просто повторяете, но не проверяете?
Есть ли жизненные ситуации, где использование этого оператора упрощает читаемость кода, увеличивает перформэнс, облегчает рефакторинг и тадэ?

упрощает читаемость кода,
-----
Да
увеличивает перформэнс,
-----
Нет
облегчает рефакторинг
-----
Нет

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

Нет.
При правильном применении да.

Компайлер его то как раз знает.

его знает препроцессор , который подменяет его , а также if, while , и т.д. адресами памяти куда следует прыгнуть.
т.к. goto при программировании обходится несколькими операторами if или break , то реальной экономии нет,
хотя учитывая, что потом компайлер делает с кодом зная методов оптимизации компайлера и не угадаешь, что нужно сделать,
чтобы сьекономить пару микросекунд

О том, что делает компилятор, нужно думать, если не хватает производительности. Правило 80/20. // Ваш К.О.

В ОО-языках можно и нужно обходиться без него, а в С он может быть весьма полезен.

В С/С++: Препроцессор изменяет код программы, т.е. на выходе препроцессора все та же программа на языке С/С++ с теми же if, while и т.д. if, while и т.д. заменяет компайлер на соответствующие еквиваленты в машинных командах. Вычислением адресов также занимается компайлер.
Попробуй по условию оптимально выйти одновременно, например, из 5 вложенных циклов.

Если бы нас изматывали только этим, то это были бы цветочки. Да и сейчас, какие только новые догмы и религии не пытаются вдолбить.

А что толку задумываться, если goto просто исключили из языков и все тут. Да и почему бы не повторять, если за это деньги платят. Не хочется ведь, чтобы тебя уволили.

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

Нет.
-----
Да. При выходе из многократно вложенных циклов дешевле иметь один GOTO, чем проверку условий на каждом уровне или ловлю исключений.
да.
-----
Нет. Пока алгоритм тот же - без разницы. Когда алгоритм другой - то для начала надо как-то извернуться с эквивалентностью разных алгоритмов...

т.к. goto при программировании обходится несколькими операторами if или break
-----
Эээ... нее, сегодня я тебя не понимаю... какая-то инверсная логика...

Спасибо - Я жую не только Бейсик, но и Фортран с его ASSIGN... причем в варианте, когда целая игровая программа - Клинги... или Убеги от людоеда... - написана единым файлом, без подпрограмм... и в Спагети-стиле.
Сути это не меняет - применение GOTO для выхода из вложенных циклов предпочтительнее других решений.

Ну, если бы GOTO применялся исключительно для етого, ты был бы прав.

Напомню, что вопрос был:

Ответ - ДА.

Фиг с тобой, убедил.

Имхо нет. Тут целая философия и целая толпа копий на этой теме сломана. У каждого программера свое мнение. Для меня "гото" - как красная тряпка.
Я читаю рутину как рассказ. Если я вижу оператор перехода, я должен пойти куда то и посмотреть что там. Как Оффтоп
Проблема выхода из цикла решается брейками и в некоторых языках екзитами. То есть выпадение из рутины не куда-то, а на то место, откуда начал, на следующую строчку.
Операторы перехода удобны для себя любимого, когда код абсолютно известен и не надо ничего раскапывать.
Кстати "гото" не зря из многих языков выбросили.

http://eli.thegreenplace.net/2009/04/27/using-goto-for-error-handling-in-c/
Исключения - это современный goto. Их же не выбросили? ;)

Проблема выхода из цикла решается брейками
------
Ну и нарисуй примерчик. Скажем, 10 (30?.. 100!?.) вложенных циклов, циклы - сложные, с пред и с пост логикой, во внутреннем - нашлось условие незамедлительного прекращения всех действий во всех циклах... Вперед...
То есть выпадение из рутины не куда-то, а на то место, откуда начал, на следующую строчку.
-----
А мне туда не надо. В самом глубоковложенном цикле Я проверил развесистое (20 строк) условие (которое Я, к слову, еще и не понимаю - его формулировал спец-предметник) и выяснил, что мне надо выйти из всех циклов... и совершенно пофиг что там в них было... Т.е. другими словами мне надо скорректировать стек на все размещенные в нем переменные и продолжить с указанного места. Переход напишу Я, а коррекцию посчитает компилятор. Напиши мне тоже самое с брейками!!!
Операторы перехода удобны для себя любимого, когда код абсолютно известен и не надо ничего раскапывать.
-----
Увы, не понял сентенции.

Даже при правильном применении?

То есть, если пытаешься не использовать этот оператор и с помощью кучи флагов выйти из вложенных циклов, то программа работает столько же времени, что и с goto?

Но если с помощью goto изначально наделано меньше говнокода, чем без него, разве это не облегчает рефакторинг?

Гм, над этим я не задумывался Впрочем исключения - это исключения, то есть что то не стандартное. Но в общем да.

Не буду. Во первых изменить кусок кода с "гото" практически невозможно - нужно сразу писать по другому. Мне сложно представить 100 вложеных циклов, я бы организовал отдельные процедуры и в любом бы случае все в одну процедуру бы не пихал.
Во-вторых это философия. Ява позволяет выпасть наружу из любого уровня вложения, но я так не пишу.

Здесь не понял. Вы на чем пишете? Я работаю с высокоуровневыми переменными, меняя их значения.

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

Но если с помощью goto изначально наделано больше говнокода, чем без него, разве это не усложняет рефакторинг? Интересная точка зрения, основанная на определении "говнокод".

В моих языках goto нет, попробовать не могу. Почему бы вам не проверить это и не написать результат? Я думаю, что разница будет несущественна.

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

То есть, если пытаешься
-----
Перформансе имеет смысл при сравнении равных алгоритмов.
При неравных - т.е при использовании GOTO - он бессмыслен.
разве это не облегчает рефакторинг?
-----
Опять - Нет.
Получается ручной анализ вместо автоматизированного.

Чушь. Алгоритм может быть одним и тем же, но по-разному реализован.

А разве автоматизированый анализ нельзя настроить на оператор перехода? Или религиозная парадигма не позволяет?

изменить кусок кода с "гото" практически невозможно
-----
??? - всегда есть возможность написать без него. Но иногда проще именно с ним.
и в любом бы случае все в одну процедуру бы не пихал
-----
А давай попробуем?
Дано - граф. Вершины - понятно. Дуги, или переходные функции - закрытое ДСП.
Есть гений-специалист в своей области, знающий как надо считать то, что надо
считать в частных случаях. Этот же спец ничего не понимает в программинге и
совершенно не заинтересован в раскрытии своей методики.
По тому, что надо делать, если делать в лоб, получается матрица, большего, чем
можно обработать на имеющейся технике, размера, да еще с инфинитным итератором.
Гений - знает когда можно срезать инфинитность и заменить ее чем-то относительно
простым - уровень отсечения - те самые 100 циклов, зависящих от данных в переходных
функциях т.е. не укладывающиеся с стандартные решения...
Ответ на вопрос - Почему так? - у гения, в закрытом ДСП...
Вы на чем пишете?
------
На всем, что способно описать алгоритм.
но неудобны для разбора чужой программы.
-----
Сие не есть правда.

Алгоритм может быть одним и тем же
-----
Угу... и граф переходов будет одним и тем же...
А разве автоматизированый анализ нельзя настроить на оператор перехода?
-----
Распознавание - можно. Чего-то большего мне пока не встречалось. Оно и
понятно - безусловный переход выпадает схемы, требующей приведения
системы к виду - один вход = один выход...
Или религиозная парадигма не позволяет?
-----
Она самая...

Исключения - это вариант возврата (return). Т.е. есть два способа откинуться: по честному (от звонка до звонка), и по исключению (досрочно-условно-по-амнистии). Раньше это моделировали вручную. Потом паттерн реализовали на синтаксическом уровне.
К goto исключения не имеют отношения. Разве что отдаленно в плане споров о степени их вредоносности. Исключения вполне структурны и усложняют логику программы только из-за введения дополнительных путей наверх. А goto использует свою систему координат (лейблы), которая никак не связана и может противоречить структурным координатам (названия процедур, циклы и т.п.)

Нифига. Return - это возврат к месту входа в подпрограмму. Исключение - это по сути longjmp.

Имеют. См. выше.

Исключения упрощают логику программы.

Ну конечно же нет А не боитесь, что во время дисскусии без разбора пример сразу будет назван говнокодом? Холивар все таки

Clean Code считает, что исключения упрощают логику программы. Исключения ни в коем случе не возврат, а прыжок к ближайшему обработчику исключений, часто на много уровней выше. При правильном использовании это обработка исключительной ситуации - бросаем все, освобождаем ресурсы и бежим к запасному выходу, где при необходимости завем на помощь.
Логику это упрощает, потому что ситуации, обрабатываемые исключением, к логике отношения не имеют - это спасательная капсула, использование которой в плане работ не прописывается. А если все в порядке - смотрим план работ.

Давайте. Есть очень специфическая задача с кучей странных условий типа гения, алгоритм которой мне неизвестен. Разумеется в любой системе есть исключения и всегда можно придумать задачу под решение. Почему бы не сделать проще - сказать что шеф тащится от goto и за его использование накидывает премии И вот уже второй повод использовать goto.

Дело в том, что "прыжок к ближайшему обработчику исключений" как раз и следует пути возврата, т.е. мы идем обратно вдоль пути вызова процедур. Так что исключение это есть самый обычный возврат, плюс определенная логика его обработки, реализованная в языке (try-catch). То, что может происходить возрат "на много уровней выше" не меняет ситуацию, поскольку все эти уровни лежат на самом обычном пути возврата.

А при обычном возврате мы разве не бросаем все и не бежим к выходу? Так что исключения лучше называть "особенный возврат" или "специальный возврат", т.е. возврат, который можно обработать отдельно в точке возврата.
Вообще, часто нет принципиальной разницы как возвращаться: по обычному или по исключению, это вопрос хорошего дизайна. Простейший пример. Пишешь ты метод поиска чего-либо. Если ничего не найдено, то это обычный возврат или исключение? Однозначного ответа нет - делай как хочешь. В большинстве случаев проще с помощью обычного возврата, но некоторые озабоченные любят втыкать исключения куда не попадя (типа это круто), в результате вся программа это сплошные try-catch.
Так что исключения конечно бывает весьма полезны, но когда видишь, что люди с ней творят, то часто хочется, чтобы ее запретили.

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

Да, по стеку мы возвращаемся обратно. Но в пределах рутины нас выбрасывает куда-то.
Запускаем рутину. Из нее запускаем следующую и еще одну. Где то там в начале 5-го уровня обваливаемся. Нас выкинет на тот уровень, на котором естъ обработка исключения и в то место рутины, где эта обработка помещена. То есть обвалились мы на 5-м уровне в начале рутины, а выкинуло нас на 3-й, куда-то в середину.
В обычном варианте мы выходим через ту дверь, через которую вошли. Зашли в рутину - вышли на следующей строчке.

Есть. Все время вылазить по пожарной лестнице возможно, но как то не принято.

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

ППКС.

Ну кто назовёт говнокодом, пусть соизволит сказать как оно должно быть лучше, иначе он врун и мелкий засранец.
Нужно учитывать, что код пишет куча разных людей.
В теле функции могут в любой момент что-нибудь дополнить/убрать.
ссылка
Функция init_dev()
Особенно предлагаю задуматься, почему в функции всего лишь один return

Функция не умещается на одну страницу => говнокод.

Разбей на сотню подфункций, а потом, если нужно что-то добавить-изменить-убрать - переписывай заново. Особенно как в этом примере, когда делается stack based unrolling - т.е. требуется откатить те шаги, которые уже были сделаны, если что не так.
Правило про функция на одну страницу - не абсолютно, иной раз надо взвешивать и сопоставлять выгоду и недостатки.

Разбей на сотню подфункций
------
На 100 - не надо. Но вот разделить три операции, плотненько перемешанных в функции,
- совсем не вредно. Тем более, что начальный шаг уже сделан - alloc_tty_struct() - выделена,
но не доведена до нормальности.
т.е. требуется откатить те шаги
-----
И кто мешает иметь корректную - free_tty_struct() - делающую именно корректный фрее?
если нужно что-то добавить-изменить-убрать - переписывай заново
-----
Разумеется! Синхронизировать указанную пару - в любом случае это придется делать...
Что существенно - так это чтобы не надо было переписывать init_dev() когда поменяется
что- то в tty&Co

Я никогда не писал на чистом С.

Хорошо, что я не программирую на С. Не в смысле функция плоха сама по себе, но...
Я не знаю общепринятых нотаций в С, но читать такой код с ходу тудно. Особенно, если не представляешь, о чем идет речь. Все имена построены на сокращениях и со стороны ни о чем не говорят. Если по условию встречается goto, то это не прокомментировано. Понятно, что тому, кто это писал, это понятно. Но со стороны не понятно, почему был совершен прыжок из основного кода. Каждый goto блок освобождает определенные ресурсы и вызывает return. Зачем для каждого return нужен goto? Почену return нельзя сразу вызвать с того места, где он нужен?

Потому что RAII нет, это ж С :)

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

swar0g, практически любое предложение по оптимизации имеет свои основания и если вы с основанием не согласны, то это не повод штамповать. Для меня, например, в моей области, на первом месте стоит читаемость кода. По возможности отсутствие повторяемости кусков кода. И где-то около последнего места количество строк исходника.
Я, например, очень даже соглашусь, что все мои идеи по оптимизации и ломаного гроша в той области, где применяется этот код и на том языке, на котором написан этот код, не стоят.

да не знаю, код нормально читается. обычный драйвер на си, то бишь его инициализация. если хоть один сам в своей жизни написал, то сходу понимаешь, что там делается. по-сути использование goto в том примере - это как уже правильно говорил господин simple - реализация отсутствующих в си эксепшенов. но в отличие от последних, goto позволяет довольно однозначно и стройно построить схему stack unrolling, т.е. когда нужно выполнение несколько зависящих друг от друга операций, а в случае ошибки откатывать операции в обратном порядке. в драйверах такое сплошь и рядом. инициализация оборудования, выделение памяти под структуры, инициализация структур и т.п. если в каком-то месте ошибка - откатывать именно пройденные операции.
do a
if (err) goto err_a
do b
if (err) goto err_b
do c
if (err) goto err_c
...
return
...
undo c
err_c:
undo b
err_b:
undo a
err_a:
return

драйвер пишут люди. куча разных людей. разработка для ядра, где недочёты более трагично отражаются на стабильности системы, чем разработка в юзерспейсе. использование дебаггера либо очень осложнено, либо невозможно. нужно заранее сделать логичный и читаемый код.
вот представим себе, что в теле функций десяток выходов. в случае, если к коду что-то добавили - то добавивший должен был бы в каждом выходе проставлять подчищение за своей добавкой. один return пропустить и не добавить подчистку не легко, а просто очень легко. а потом ищи на уровне ядра, где память текёт. если же выход из функции в одном месте, то и подчистка в любом случае будет автоматически соблюдена при до/переписывании функций.
в данном же примере сильно фанатично старались оставлять лишь один return. я бы в двух последних местах, где стоит goto end_init, тоже бы поставил return. но это в данном случае непринципиально.

в данном случае предложение по оптимизации не отражали реалий жизни. если бы разработчики изначально знали что писать, они естественно более стройно разбили код на нужные функции. а это кусок кода, который годами дополнялся, дописывался, изменялся, в зависимости от нужд, изменяющегося api, погоды, наличия месячных у жён разработчиков.
и тем более предложение по оптимизации уводило тему в оффтопик. я продемонстрировал кусок кода, где применение goto было приемлимым, необходимым, делало код более читаемым, даже не смотря на длину функции (я специально длинную выбирал). если бы код был бы разбит на более мелкие функции и именно init_dev была бы короче, это бы ни насколько не умаляло оправданность использования goto.

Че-то не пойму, в чем отличие.

а так всё явно в одном месте.
------
У меня с одним из шефов был серьезный спор именно по данному вопросу.
Он мужик умный, но ему не всегда хватает времени сделать не как сделает,
а как надо сделать. И вот однажды он слепил что-то подобное...
Год оно глючило. Год Я просил его переписать, разделив смесь на компоненты.
Потом, когда больше делать было нечего, протрассировал что там делается.
Поправил с 10-к багов... и оставил глючить дальше.
Так что "всё явно в одном месте" при наличии более чем одной операции в
методе для меня аргументом не является.
Аргументом для меня будет следующее - есть методы:
- аллоцирования tty
- деаллоцирования tty
- подвязки tty к системе
- отвязки tty от системы
- валидации tty
и порядок их использования.
Если этих методов не хватит - опять таки посмотреть если среди требуемого
парные операции и так их и имплементировать. А танцы с бубном - нафиг-нафиг...
если мы хотим наплодить ещё больше строк исходник
-----
Количество строк уменьшится, если будет видна логика процесса и тот кто
пишет код понимает что он делает. На моей практике 29к сишного кода
ужались до 16 строк кода и таблицы с данными. При этом Я практически
ничего не сделал - только заменил написанный с использованием конструкций
языка автомат на его эквивалент в данных и простую процедуру изменения
состояния.

если же выход из функции в одном месте, то и подчистка в любом случае будет автоматически соблюдена
-----
Эээ... как бы это сказать по проще, что одно из другого как бы не очень следует...
Ну наверное так - написал Я в произвольном месте переход на ретурн...
Ну а ты мне объяснишь как автоматически подчиститься память...

В обсуждении слово "исключение" используется в двух смыслах:
1. как общий паттерн, когда нечто (ужасное, хотя и не обязательно) может случиться в разных местах, а обработчик нужен один. Это обсуждать довольно сложно, поскольку мы быстро доберемся до основ мироздания или из какого полупроводника компьютеры делают. В лучшем случае обсудим аспектно-ориентированное программирование.
2. как конкретная синтаксическая констукция современных языков (try-catch). Это, как уже было показано, это обобщение механизма возврата. В частности, возможность вернуть объекты разных типов, а потом при возврате фильтровать их по типу.
В данном примере (как и во многих подобных), goto это скорее общий ручной способ организовать процедуры (структуру), что, в частности, испльзуется для обработки особенных ситуаций (хотя ничего особенного в них конечно нет). Почему не объявить процедуры?
1. Это несколько дороже (что для драйверов важно).
2. Процедура ничего не должна знать о внешнем контексте (ведь ее могут вызвать откуда угодно). В Си это конечно легко обойти (что собственно и делается), но это будет нарушение логики, поэтому всю эту логику и забивают в одну длинную процедуру.
3. Процедура это уже совершенно конкретный способ работы со стеком, а значит других быть не должно быть. Если мы хотим сами ковыряться в стеке, то значит процедуры лучше не использовать. Если используем процедуры, то не надо работать со стеком вручну.

Я бы назвал это ручным управлением структурой стека, но при чем тут исключения? Это обычная логика почти любой программы. Что тут особенного? Что какое-то событие может произойти в разных частях, а обработать его (например, откатиться) хочется только в одной точке?
И почему ручной способ является однозначным и стройным? Если это ручное управление, то все зависит от того, кто написал. Один напишет криво, другой ровно. В этом и проблема goto (как и любых низкоуровневых операций), что он не гарантирует правильности и легко ведет к ошибкам.
Так что еще раз: goto не имеет большого отношения к исключениям. Исторически, раньше были только jmp, и все мыслили в терминах перехода. Соответственно, (дураки) его автоматически перетащили в новые высокоуровненвые языки в виде goto. А далее пришел Дейкстра и сказал, что все вокруг козлы и goto не нужел. Если бы это не был Дейкстра, то его бы забили камнями, поскольку это было как серпом по яйцам. Вот и все. А исключения здесь при том, что goto можно использовать, для ручной организации внутренней структуры программы (без структуризации с помощью процедур). А далее эта структура может использоваться для реализации определенных логических паттернов, типа когда обработчики ситуаций имеют лейблы, переход к которым осуществляется по goto из разных точек программы. Даже если мы назывем это механизмом исключений, то goto это всего лишь один из способов его реализации.

Ну так это же просто песня!

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

Столько написать, ничего при этом не сказав - тебе надо было становиться политиком! :-D

Столько прочитать, так ничего и не поняв - пора тебе в народ возвращаться! :-/

Девиз кодера - все, что с такими мучениями было написано, должно так же мучительно читаться. Это по поводу отсутствия комментариев.
Я драйвера никогда не писал. Согласен, что многие особенности продиктованы условиями.

Комментарии писать надо тоже уметь. Просто комментировать код - лучше бы таких комментариев не было.

Мне нравится это девиз. По крайней мере он многое объясняет.
Сразу другой девиз: всегда думай также о других кодерах, чтобы они не остались без работы, если твоя программа будет работать без ошибок.

Райское наслаждение

Все гораздо проще: лень-матушка ;)

на этапе инициализации это не играет никакой роли

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

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

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

goto - в данном месте способ написать наиболее ровно. правильности он не гарантирует (как и собственно не гарантирует правильности любой из языков программирования, какие бы они ни были продвинутые). goto - это инструмент, который должен быть задействован соответсвующим образом, а не абы-как

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

Не буду мешать вашему самовосхвалению.

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

из всего поста, 90% которого занимают только ваши самовосхваления, я не увидел ни одной ценной для себя информации

это в данной ситуации просто самый приямой способ реализации алгоритма.
goto - в данном месте способ написать наиболее ровно
-----
Да разве? И что, нет идеи как можно спрямить налепленную хрень? Правда нету?
А у меня где-то таки есть... причем точно знаю, что вся "сложная" процедура
упакуется, станет прозрачной и полностью управляемой... Мало того - код
процедуры, в части аллокации и освобождения, перестанет меняться при
изменениях...
откатываться надо в обратном порядке.
-----
А MCB-ишки или их аналоги уже отменили?
Ну даже если и отменили, то что именно заставляет освобождать память именно
в обратном порядке? Последний раз такое утверждалось для ДОС 3.20. Но там
это было оправдано - блоки не освобождались, а присоединялись к ближайшему
занятому, если таковой имелся...
с помощью исключений это можно сделать, оперируя переменные-флаги.
-----
Эээ... не знаю как это комментировать...

а как быть с проектами, которые "растут".
------
А что это меняет?
Ну есть "растущий" проект.
Пусть даже меняется размер tyy, других структур и их организация.
Вынеси логику размещения/освобождения памяти в данные и выполни
имплементацию процедур, используя данные для актуального управления
памятью - проблема "роста" просто исчезнет...
Правда появится другая проблема - большинство кодеров будет не в состоянии
модернизировать "код" в силу непонимания методики...
вам платят за то, что вы по идейным соображением перепишете рабочий и оттестированый кусок кода только потому, что так требует ваша религия?
------
Мне частенько платят за изготовление говнокода, к которому есть всего два требования:
1. Он должен быть условно-рабочим. Т.е. "не падать" в не предсказуемых местах.
2. Он должен быть написан в кратчайшие сроки. Мягко говоря - 10-12 мегабайт в день...
В других случаях, мне платят за то, Я беру кусок глючного кода и делаю из него
условно-рабочий код. Как - обычно не спрашивают, но хотят быстро...
Но наиболее полезным использованием меня является не кодинг, а гоняние молодых,
полных сил и здоровья, говнокодеров, с целью подвинуть оных на имплементацию
того, об чем они не слыхали до этого. Частенько это включает "переписывание", а
точнее - замену, рабочего, оттестированного, но переставшего решать поставленную
задачу кода, на другой, в зависимости от условий, более компактный, производительный
и устойчивый... Как правило - получается неплохо.

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

функция отлично читается и вполне прозрачна. сходу

здесь ядро, здесь имеет место не только освобождения памяти, но и инициализация/деинициализация оборудования (например, изменение pci регистров). как его деинициализировать, если на структуру, описывающую состояние оборудования, уже напустили free()/ ещё раз говорю, если вам так тяжело понять - здесь выполнение операций, зависимых друг от друга и от порядка их выполнения как в одну, так и в другую сторону. но ты же не читатель.

если бы знания позволяли бы, то знал бы

а если меняется апи?

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

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

хорошо. как ты эффективно выполнишь stack based unrolling?

Не надоело развеивать миф?

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

функция отлично читается и вполне прозрачна. сходу
------
Гений чтения сишного кода... а вот мне, после лет этак 15-ти отсутствия практики,
как-то так не показалось...
а если меняется апи?
------
Ну и? Ну поменялось. Что дальше? Перестало требоваться последовательное выделение
и обратное освобождение памяти? Нет?!! - значит будет замен набор управляющих данных,
а код останется без изменений - в нем, по условию, нет смеси операций - только управление
выделением и освобождением памяти...
здесь ядро
-----
Да-да... поэтому там "нельзя" перевести написанный код в релевантную машину состояний
и упростить все до безобразия... просто из-за того что, гото там не обходится, а по-другому
решение вообще не видится... хи-хи-кс...
понятно, завернём нашу писанину
-----
Об этом тебе и говорится - не понимаешь - не берись...
Последний раз Я это проделал с одной молоденькой китаянкой. Девочка была оооочень смарт,
но как и все западные - недоучена. Была поставлена писать небольшой сервис и она нарисовала
что-то похожее на "код ядра"... и уперлась в неуправляемость при расширении, что было основным
условием работы сервиса.
После этого в три приема была обучена тому что требовалось, уловила суть, написала драфт, после
анализа - поправила недоработку. Код - работает, расширяется модульно, без перестроения сервиса,
об проблемах - вообще не сообщалось... да их там и быть не может - код - простой и его совсем
не много, много меньше, чем нормальный прогер может удержать в мозгах.

как ты эффективно выполнишь stack based unrolling?
-----
Запущу автомат в обратном порядке... если этого будет недостаточно - заменю управляющий
набор на релевантный, позволяющий сделать нужную работу - прокрутить автомат а обратном
порядке...