Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки. Последние 9 лет я действительно обходился без goto, но недавно возникла задача, в которой обойтись без этого оператора было бы весьма неудобно (нужно перейти в более раннюю часть кода изнутри блока begin..end. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue, но с goto получилось явно изящнее. После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись. Я прав?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки. Последние 9 лет я действительно обходился без goto, но недавно возникла задача, в которой обойтись без этого оператора было бы весьма неудобно (нужно перейти в более раннюю часть кода изнутри блока begin..end. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue, но с goto получилось явно изящнее. После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись. Я прав?
Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код.
Здравствуйте, AlexRK, Вы писали:
ARK>Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код.
Удачи переписать без goto. Производительность пострадать не должна.
public struct ExtensionRuleParserState
{
public mutable newResult : int;
public mutable newEndPos : int;
public mutable bestResult : int;
public mutable bestEndPos : int;
public mutable lastResult : int;
public mutable curTextPos : int;
public mutable parseResult : ParseResult;
public Append() : void
{
assert3(newResult > 0);
//очищаем флаги
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] & ExtensibleRuleParser.RawTreeMask.Id;
//добавляем в список
parseResult.rawTree[newResult + ExtensibleRuleParser.RawTreeOfs.Next] = lastResult;
lastResult = newResult;
// выбираем лучшее правило: побеждает то правило, у которого находится поле спарсившее больше текста
// если оба правила имеют одинаковое кол-во полей, размеры которых идентичны, ситуация считается неоднозначностьюwhen (bestResult <= 0) goto new_better;
if (bestEndPos < 0) if (newEndPos >= 0) goto new_better; else goto equal;
else when (newEndPos < 0) goto best_better;
def newTokens = parseResult.TokenEnumerator1.Start(newResult, curTextPos);
def bestTokens = parseResult.TokenEnumerator2.Start(bestResult, curTextPos);
while (true)
{
def newSize = newTokens.NextTokenSize();
def bestSize = bestTokens.NextTokenSize();
when (newSize > bestSize) goto new_better;
when (newSize < bestSize) goto best_better;
when (newSize < 0) goto equal;
}
label equal;//АСТ равен лучшему. Неоднозначность.
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] | ExtensibleRuleParser.RawTreeFlags.Equal;
assert(bestEndPos == newEndPos);
return;
label new_better;//Новый АСТ лучше
bestEndPos = newEndPos;
bestResult = newResult;
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] | ExtensibleRuleParser.RawTreeFlags.Best;
return;
label best_better;
return;
}
}
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Удачи переписать без goto. Производительность пострадать не должна.
А что, изначально вместо goto вызов функции поставить — некошерно будет?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, WolfHound, Вы писали:
ARK>>Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код. WH>Удачи переписать без goto. Производительность пострадать не должна.
Пардон, но рефакторить весьма мусорный код в мои планы не входит.
Лаптев, кстати, правильно написал — выносите в функцию все, что в goto.
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки. Последние 9 лет я действительно обходился без goto, но недавно возникла задача, в которой обойтись без этого оператора было бы весьма неудобно (нужно перейти в более раннюю часть кода изнутри блока begin..end. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue, но с goto получилось явно изящнее. После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись. Я прав?
Нужно писать просто и понятно. Если чтобы избавится от goto можно только ценой сильного усложенния — я бы оставил goto.
Другое дело, что за последние 10 лет мне это понадобилось ровно 2 (два) раза, то есть эти случаи не частые.
Ну, это если не брать языки где без goto в принципе не обойтись.
Учтите, что continue, return и break (в С-подобных языках) это те же самые goto, точнее — ограниченные частные версии goto для наиболее употребительных случаев. И соответственно, запутать код они могут не хуже.
http://tinyurl.com/lzdxs3r
Я очень горд, что в этой книжке (Elements of Programming) есть, вы сейчас просто @#$%&%@#, GOTOS. Почему? Потому что в какой-то момент мы показываем, специально, потому что знаем, что вы будете кричать БУУУУУ и писать письма, может быть не все, но некоторые — мне всегда пишут письма что я дурак — потому что я не верю в объектную ориентацию, я использую goto — пропащий человек. И многие люди, в программировании есть такая идея что люди считают что это очень мило написать незнакомому человеку письмо говорящие что "ты дурак". Даже если вы так думаете — вы мне не говорите, потому что — не нужно, не обязательно.
Мы используем goto, для чего — потому что у нас есть структура которая реально является конечным автоматом. Если вы описываете конечный автомат, что он делает — он переходит из состояния этого в состояние то. Как нужно переходить из одного состояния в другое? Есть правильная инструкция — называется goto: идите от туда — туда. И структура программы становится очень элегантной.
То есть идея Дейкстры, Дейкстра великий человек — вы не думайте что $#%@#$%@#$, но он конечно же был не прав, потому что он думал, что плохая программа, потому что она пользуется какой-то синтаксической структурой. Нет — программа плохая, если она плохая. То есть может быть очень красивая программа на языке Assembler — очень элегантная. Может быть очень плохая программа на Java, уверяю вас.
Немецкий язык такой непоэтичный — но какая поэзия Самые красивые песни на каком языке? На немецком — Шуберт — необыкновенная красота. Хотя у них там гортанный, странный язык, но невероятно красивый. Всё можно сделать. goto может быть красивым. Я не верю в синтаксические лишения в семантических вопросах.
В меня всю жизнь камнями кидают, потому что я всё время такие вещи говорю — и мне говорят что я дурак. Но я не пытаюсь просто сказать дерзость. Я на самом деле пытаюсь объяснить какие-то вещи и в этой книжке никаких дерзостей.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AlexRK, Вы писали:
ARK>>Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код. WH>Удачи переписать без goto. Производительность пострадать не должна.
Здесь как раз goto не нужен.
Как вариант, можно переписать в единую цепочку if/else if/else (сейчас последный else неявный) и вынести все три кейса в отдельные методы.
Здравствуйте, AlexRK, Вы писали:
ARK>Пардон, но рефакторить весьма мусорный код в мои планы не входит.
Так быстро слил...
ARK>Лаптев, кстати, правильно написал — выносите в функцию все, что в goto.
Это сделает код лучше? Нет.
Медленнее? Да.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vmpire, Вы писали:
V>Здесь как раз goto не нужен. V>Как вариант, можно переписать в единую цепочку if/else if/else (сейчас последный else неявный) и вынести все три кейса в отдельные методы.
Покажи класс.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Здесь как раз goto не нужен. V>>Как вариант, можно переписать в единую цепочку if/else if/else (сейчас последный else неявный) и вынести все три кейса в отдельные методы. WH>Покажи класс.
Вы не понимаете предложенного решения, или просто хотите, чтобы за вас сделали работу?
Работу делать не буду, но что непонятно — объясню.
Здравствуйте, vmpire, Вы писали:
V>Вы не понимаете предложенного решения, или просто хотите, чтобы за вас сделали работу? V>Работу делать не буду, но что непонятно — объясню.
Я понимаю, что ты предлагаешь написать кучу кода, на ровном месте сделав решение хуже.
Осталось, чтобы и ты это понял.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ARK>>Пардон, но рефакторить весьма мусорный код в мои планы не входит. WH>Так быстро слил...
Сочувствую, в следующий раз сливайте помедленнее.
Если по теме: приводите не портянку говнокода с кучей не относящихся к делу деталей, а краткий псевдокод, акцентирующий внимание на проблеме и/или решении.
А пока что — номер не прошел.
ARK>>Лаптев, кстати, правильно написал — выносите в функцию все, что в goto. WH>Это сделает код лучше? Нет.
Да, это сделает код лучше.
WH>Медленнее? Да.
Только если компилятор глупый.
А так инлайн функций давно уже применяется.
Здравствуйте, WolfHound, Вы писали:
WH>Удачи переписать без goto. Производительность пострадать не должна.
На оптимизирующий компилятор закладываться можно? Или предполагается, что это всего лишь ассемблер с красивым синтаксисом?
Самое простое с т.з. рефакторинга в данном случае — написать три локальные функции, и вместо goto new_better делать return new_better(). Полагая, что компилятор их проинлайнит.
Либо понадеяться, что компилятор способен трассировать булевы флаги. Полное покрытие кода — это дело неподъёмное, но уж два-три флага отследить (00 — ещё неизвестно, 01 — новый лучше, 10 — старый лучше, 11 — они равны; либо 0xx — ещё неизвестно, 10x — они равны, 110 — новый лучше, 111 — старый лучше).
Причём для архитектуры с условными операциями (ARM) это позволит даже без лишних ветвлений обойтись. Код в единственном месте ветвится по необходимости — в цикле; остальное всё исполняется подряд.
Здравствуйте, AlexRK, Вы писали:
ARK>Если по теме: приводите не портянку говнокода с кучей не относящихся к делу деталей, а краткий псевдокод, акцентирующий внимание на проблеме и/или решении.
Тут всего 40 строк.
WH>>Это сделает код лучше? Нет. ARK>Да, это сделает код лучше.
Замена goto XXX; на { XXX(); return; } код лучше не сделает.
WH>>Медленнее? Да. ARK>Только если компилятор глупый. ARK>А так инлайн функций давно уже применяется.
Инлайн сделает несколько копий кода. Больше кода -> больше промахов кэша.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кодт, Вы писали:
К>На оптимизирующий компилятор закладываться можно? Или предполагается, что это всего лишь ассемблер с красивым синтаксисом?
Только если компилятор способен переписать код в то, что написал я.
Я знаю технику с помощью, которой компилятор может это сделать. Но не знаю, применяет ли её кто либо.
К>Самое простое с т.з. рефакторинга в данном случае — написать три локальные функции, и вместо goto new_better делать return new_better(). Полагая, что компилятор их проинлайнит.
Но что это даст? Чем оно принципиально отличается от goto кроме того что там нет слова goto?
Но можно пойти ещё дальше. Есть верование, что функция должна иметь ровно один выход. Чтобы соответствовать ему придётся вообще прыгать вокруг флагов.
К>Либо понадеяться, что компилятор способен трассировать булевы флаги.
Тут я вообще не понял, что ты предлагаешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
К>>На оптимизирующий компилятор закладываться можно? Или предполагается, что это всего лишь ассемблер с красивым синтаксисом? WH>Только если компилятор способен переписать код в то, что написал я. WH>Я знаю технику с помощью, которой компилятор может это сделать. Но не знаю, применяет ли её кто либо.
Что именно? Merge'ить код после инлайнинга с помощью безусловных переходов? Компиляторы C++ это умеют.
Например смотри вот тут
секцию "ASM для N=4" — там есть jmp на код перед ret, который разделяется несколькими ветками, хотя в самом заинлайненом коде этого не было — каждый вариант был сам по себе.
С другой стороны компилятор может решить этого не делать, даже если умеет.
К>>Самое простое с т.з. рефакторинга в данном случае — написать три локальные функции, и вместо goto new_better делать return new_better(). Полагая, что компилятор их проинлайнит. WH>Но что это даст? Чем оно принципиально отличается от goto кроме того что там нет слова goto?
Я например предпочитаю делать код функций короче, и выносить из них по возможности даже однократно используемый код.
Если же тебя твоя версия устраивает — не вижу никакого криминала.
WH>Но можно пойти ещё дальше. Есть верование, что функция должна иметь ровно один выход. Чтобы соответствовать ему придётся вообще прыгать вокруг флагов.
Да, это такого же рода предрассудки. Другой пример — гипертрофированная боязнь функций, мол всё должно быть объектом
Здравствуйте, WolfHound, Вы писали:
V>>Вы не понимаете предложенного решения, или просто хотите, чтобы за вас сделали работу? V>>Работу делать не буду, но что непонятно — объясню. WH>Я понимаю, что ты предлагаешь написать кучу кода, на ровном месте сделав решение хуже.
Понимание неправильное по обоим пунктам.
Вам это решение уже разжевали
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки. Последние 9 лет я действительно обходился без goto, но недавно возникла задача, в которой обойтись без этого оператора было бы весьма неудобно (нужно перейти в более раннюю часть кода изнутри блока begin..end. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue, но с goto получилось явно изящнее. После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись. Я прав?
Я воспитан на goto, потому что начинал на Фортране-4, а в нем не было цикла while. Поэтому методика написания этого цикла была : пишем как будто он выполняется 1 раз, потом условие с goto назад.
Тем не менее, уйдя с Фортрана, я применять goto прекратил. В последние лет 20 я его не написал ни разу.
Теоретически — все, что можно написать с goto, можно написать и без него. И не будет это хуже по эффективности, как бы кто ни заявлял.
Тем не менее я противник фанатизма, в т.ч. и goto-фанатизма. Заявлять, что категорически писать goto нельзя, я не буду. Тем более, что надо еще принять во внимание возможности того или иного языка (речь не о Фортране -4), насколько хорошо в нем реализованы замены. Например, я Яве выпутаться из кратных циклов можно достаточно элегантно, поставив break label, а в C++ — гораздо менее элегантно.
В общем, если использование goto делает код проще и понятнее — почему бы и нет ? Только сначала убедитесь, что иначе не получится.
Здравствуйте, WolfHound, Вы писали:
WH>>>Осталось, чтобы и ты это понял. V>>Ваша аргументация своей правоты меня восхищает. WH> Ну ты код то покажи.
Если вы по подробным инструкциям не способны сами написать код, то дискутировать с вами о преимуществах того или иного подхода считаю излишним.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Теоретически — все, что можно написать с goto, можно написать и без него. И не будет это хуже по эффективности, как бы кто ни заявлял.
Это будет хуже по эффективности.
Откройте какой мало-мальски критичный к производительности проект,
например тотже Фреймворк для дотнет и посмотрите сколько там гоуту ...
Здравствуйте, WolfHound, Вы писали:
ARK>>Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код. WH>Удачи переписать без goto. Производительность пострадать не должна.
Я бы сделал КА на switch'е. Без дополнительных функций.
Не то, чтобы я не любил goto, но легко допустить ошибку когда-нибудь потом, при расширении функциональности.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Khimik!
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны...
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки.
Я использую goto на всех языках, на которых я пишу. И не капли не комплексую по этому поводу.
И вообще, какой-то у тебя староватый комплекс. Сейчас народ комплексует по поводу шаблонов и функциональщины.
Здравствуйте, BoobenCom, Вы писали:
BC>Это будет хуже по эффективности. BC>Откройте какой мало-мальски критичный к производительности проект, BC>например тотже Фреймворк для дотнет и посмотрите сколько там гоуту ...
Хуже с goto или без ? Если без goto — пример, пожалуйста.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, WolfHound, Вы писали:
WH>>Удачи переписать без goto. Производительность пострадать не должна.
К>На оптимизирующий компилятор закладываться можно? Или предполагается, что это всего лишь ассемблер с красивым синтаксисом?
Неужели сейчас кого-то волнует производительность?
Причём такая, которую может сломать goto?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, BoobenCom, Вы писали:
BC>>Это будет хуже по эффективности. BC>>Откройте какой мало-мальски критичный к производительности проект, BC>>например тотже Фреймворк для дотнет и посмотрите сколько там гоуту ...
PD>Хуже с goto или без ? Если без goto — пример, пожалуйста.
Здравствуйте, Patalog, Вы писали:
ARK>>И рассуждение само по себе странное. У вас все программы из одной функции состоят? А то вдруг производительность того, просядет.
P>Оно странное только для того, кто никогда не занимался оптимизацией.
Обоснование?
(А то можно и наоборот: "оно не странное только для того, кто не писал ничего, кроме говнокода".)
K>После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись.
Поздравляю! Вы перешли на новый уровень в понимании Дао программирования.
Здравствуйте, WolfHound, Вы писали:
К>>Самое простое с т.з. рефакторинга в данном случае — написать три локальные функции, и вместо goto new_better делать return new_better(). Полагая, что компилятор их проинлайнит. WH>Но что это даст? Чем оно принципиально отличается от goto кроме того что там нет слова goto?
Это радикально улучшает читабельность, потому что return видно сразу.
Здравствуйте, WolfHound, Вы писали:
К>>Самое простое с т.з. рефакторинга в данном случае — написать три локальные функции, и вместо goto new_better делать return new_better(). Полагая, что компилятор их проинлайнит. WH>Но что это даст? Чем оно принципиально отличается от goto кроме того что там нет слова goto?
Это упростит трассировку покрытия кода и позволит компилятору провести какую-нибудь более мощную оптимизацию — например, проинлайнить твою функцию Append() или вывести для неё граничные условия. А так — компилятор увидел, что внутри спагетти, ну и бросил это гиблое дело.
WH>Но можно пойти ещё дальше. Есть верование, что функция должна иметь ровно один выход. Чтобы соответствовать ему придётся вообще прыгать вокруг флагов.
Или прыгать вокруг ветвящихся выражений — тернарного оператора, свитчей, паттерн-матчинга.
В функциональных языках это очень даже естественно.
Кстати, функцию ведь можно декомпозировать и наоборот: отделить диагностику от исполнения
А вот в языках с ручным управлением ресурсами (Си, бейсик там всякий) — один выход — это борьба за чистоту рук. Ведь перед выходом надо выполнить код освобождения локальных ресурсов. Чем больше выходов, тем больше копипасты.
К>>Либо понадеяться, что компилятор способен трассировать булевы флаги. WH>Тут я вообще не понял, что ты предлагаешь.
Вот что я предлагаю.
enum Decision { NotSet | ChooseNew | ChooseOld | Ambiguity };
public Append() : void
{
assert3(newResult > 0);
// флаг для трассировкиmutable decision = Decision.NotSet;
//очищаем флаги
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] & ExtensibleRuleParser.RawTreeMask.Id;
parseResult.rawTree[newResult + ExtensibleRuleParser.RawTreeOfs.Next] = lastResult;
lastResult = newResult;
// сдаётся мне, твой код when / if / else / else / when можно было написать более причёсанно,
// но не хочу вдаваться в логику и просто оберну два стейтмента - каждое в свою обёрткуwhen (decision == Decision.NotSet)
when (bestResult <= 0) decision = Decision.ChooseNew;
when (decision == Decision.NotSet)
{
if (bestEndPos < 0) if (newEndPos >= 0) decision = Decision.ChooseNew; else decision = Decision.Ambiguity;
else when (newEndPos < 0) decision = Decision.ChooseOld;
}
// двойная обёртка - только ради того, что здесь появились локальные переменные
// (кстати, компилятор С++ надавал бы по рукам за прыжки goto поверх переменных - потому что деструктор же!)
// отрефакторить легко: надо вместо def сделать mutable и выполнить единственное присваивание под обёрткой.when (decision == Decision.NotSet)
{
def newTokens = parseResult.TokenEnumerator1.Start(newResult, curTextPos);
def bestTokens = parseResult.TokenEnumerator2.Start(bestResult, curTextPos);
while (decision == Decision.NotSet)
{
def newSize = newTokens.NextTokenSize();
def bestSize = bestTokens.NextTokenSize();
if (newSize > bestSize) decision = Decision.ChooseNew; else
if (newSize < bestSize) decision = Decision.ChooseOld; else
when (newSize < 0) decision = Decision.Ambiguity;
}
}
// в этом месте мы можем поклясться, что решение принято.
// хотя из goto это следовало лишь трассировкой покрытия кода (по способам выпрыгнуть из while true)
// флаг позволяет добавить нам чуть больше отладочности!
assert (decision != Decision.NotSet);
// либо внести изменения в алгоритм, чтобы тот допускал дефолтные случаи (например, если вообще не входить в цикл)when (decision == Decision.NotSet) decision = ?????; // вот что-то такое сделать
// здесь надо бы написать match(decision) ..., но для единообразия продолжу на when.when (decision == Decision.Ambiguity) //АСТ равен лучшему. Неоднозначность.
{
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] | ExtensibleRuleParser.RawTreeFlags.Equal;
assert(bestEndPos == newEndPos);
}
when (decision == Decision.ChooseNew) //Новый АСТ лучше
{
bestEndPos = newEndPos;
bestResult = newResult;
parseResult.rawTree[newResult] = parseResult.rawTree[newResult] | ExtensibleRuleParser.RawTreeFlags.Best;
}
when (decision == Decision.ChooseOld) //Старый АСТ лучше
{
}
// нахаляву получили единственный return void.
}
Код стал страшнее и многословнее. Зато он стал линейным. Для некоторых платформ это одно удовольствие.
Только я хочу подчеркнуть: я не РЕЗКО ПРОТИВ goto.
Если по каким-то причинам (говнокомпилятор) чем меньше вызовов функций и лишних флагов, тем лучше, — то пожалуйста.
Хоть всю программу запихай в одну мега-кастрюлю со спагетти.
хъ
ARK>>>И рассуждение само по себе странное. У вас все программы из одной функции состоят? А то вдруг производительность того, просядет.
P>>Оно странное только для того, кто никогда не занимался оптимизацией.
ARK>Обоснование?
Чего? Что инлайн приводит к увеличению исполняемого кода? Тебе это не очевидно? Или не очевидно, что этот увеличившийся объем может не влезть в кэш? Или что если нагруженная ф-я не влазит в кэш то страдает перфоманс?
ARK>(А то можно и наоборот: "оно не странное только для того, кто не писал ничего, кроме говнокода".)
Я про твой говнокод ничего не говорил, не надо мне свои фантазии приписывать.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, WolfHound, Вы писали:
ARK>>>Обойтись без goto можно всегда. Есть люди, которые считают, что иногда goto делает код проще/лучше. Лично я считаю, что это не так. По моему мнению, если goto делает код проще, то это плохой код. WH>>Удачи переписать без goto. Производительность пострадать не должна.
SVZ>Я бы сделал КА на switch'е. Без дополнительных функций. SVZ>Не то, чтобы я не любил goto, но легко допустить ошибку когда-нибудь потом, при расширении функциональности.
Любой goto можно переписать в свитч, но это добавит ещё как минимум один переход и ещё одно сравнение. Ну и, если честно, в настоящем виде код читается не так уж плохо.
Здравствуйте, Patalog, Вы писали:
P>Чего? Что инлайн приводит к увеличению исполняемого кода? Тебе это не очевидно? Или не очевидно, что этот увеличившийся объем может не влезть в кэш? Или что если нагруженная ф-я не влазит в кэш то страдает перфоманс?
Из ложной посылки — и все остальное тоже ложь.
ARK>>(А то можно и наоборот: "оно не странное только для того, кто не писал ничего, кроме говнокода".) P>Я про твой говнокод ничего не говорил, не надо мне свои фантазии приписывать.
Пока что поток фантазий идет только с вашей стороны.
хъ
P>>Чего? Что инлайн приводит к увеличению исполняемого кода? Тебе это не очевидно? Или не очевидно, что этот увеличившийся объем может не влезть в кэш? Или что если нагруженная ф-я не влазит в кэш то страдает перфоманс?
ARK>Что инлайн приводит к увеличению исполняемого кода — нет, не очевидно. И не только мне: http://rsdn.ru/forum/philosophy/6025071
К сожалению, ты не асилил даже прочитать до конца сообщение на которое ссылаешься — "И начиная с определённого порога, такой вариант станет медленней "классического" подхода, как минимум потому что будет забиваться instruction cache". Хотя да, поскольку ты только погавкаться — тебе это не нужно.
Здравствуйте, Patalog, Вы писали:
ARK>>Что инлайн приводит к увеличению исполняемого кода — нет, не очевидно. И не только мне: http://rsdn.ru/forum/philosophy/6025071
P>К сожалению, ты не асилил даже прочитать до конца сообщение на которое ссылаешься — "И начиная с определённого порога, такой вариант станет медленней "классического" подхода, как минимум потому что будет забиваться instruction cache".
Хм. Причем тут это?
Вот эта ваша фраза, гражданин оптимизатор — "инлайн приводит к увеличению исполняемого кода" — ложь. И выводы из нее, соответственно, тоже.
В каких-то случаях приводит, в каких-то не приводит.
P>Хотя да, поскольку ты только погавкаться — тебе это не нужно.
У меня нет цели ни с кем "гавкаться". С этим обратитесь к зеркалу.
Если желаете конструктивного диалога, то не стоит начинать разговор с наезда.
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если мой вопрос совсем ламерский, или если баян. Где-то я читал, что операторы безусловного перехода goto хорошему программисту не нужны, их надо заменять на стандартные блоки. Последние 9 лет я действительно обходился без goto, но недавно возникла задача, в которой обойтись без этого оператора было бы весьма неудобно (нужно перейти в более раннюю часть кода изнутри блока begin..end. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue, но с goto получилось явно изящнее. После этого у меня создалось ощущение, что в сложных алгоритмах оператор goto всё-таки приходится иногда применять, без этого не обойтись. Я прав?
Хороший программист должен уметь обходиться не только без goto, но и без break, continue, while(true), for, return в середине функции.
На следующей ступени надо уметь избавляться полностью от while, foreach, if/switch statement, рекурсии и использовать только функции высшего порядка и сопоставление с образцом.
P.S. Тут есть одна важная деталь. Это надо уметь != это надо делать.
Здравствуйте, Patalog, Вы писали:
ARK>>Что инлайн приводит к увеличению исполняемого кода — нет, не очевидно. И не только мне: http://rsdn.ru/forum/philosophy/6025071
P>К сожалению, ты не асилил даже прочитать до конца сообщение на которое ссылаешься — "И начиная с определённого порога, такой вариант станет медленней "классического" подхода, как минимум потому что будет забиваться instruction cache".
Это замечание относится к альтернативному (стандартному) варианту реализации сортировки, а не к тому что inline даст больше кода чем вызовы.
В этом случае как раз наоборот — если выключить inline — то кода получится даже больше, так как у каждой ветки будет в конце выполняться полная перестановка элементов массива. С inline'ом же концы веток merge'аться компилятором, в том числе и безусловным переходом — goto/jmp.
Здравствуйте, Кодт, Вы писали:
К>Это упростит трассировку покрытия кода и позволит компилятору провести какую-нибудь более мощную оптимизацию — например, проинлайнить твою функцию Append() или вывести для неё граничные условия. А так — компилятор увидел, что внутри спагетти, ну и бросил это гиблое дело.
Это даже не смешно.
То у тебя компилятор творит чудеса с трассировкой потока исполнения. То не может проинлайнить функцию с goto. Ты уж определись.
К>Кстати, функцию ведь можно декомпозировать и наоборот: отделить диагностику от исполнения
И чем это лучше? Ну кроме того что стало больше кода и нужно гораздо больше полагаться на компилятор.
К>А вот в языках с ручным управлением ресурсами (Си, бейсик там всякий) — один выход — это борьба за чистоту рук. Ведь перед выходом надо выполнить код освобождения локальных ресурсов. Чем больше выходов, тем больше копипасты.
В случае с дурными языками паттерн
result = ...;
goto exit;
никто не отменял.
К>Вот что я предлагаю.
хъ К>Код стал страшнее и многословнее. Зато он стал линейным. Для некоторых платформ это одно удовольствие.
Линейным? В каком месте? Я вижу тут кучу ветвлений.
А вообще я с этой темя фигею. Предлагают копипасту, пляски вокруг флагов или замаскированный goto лишь бы не написать слово goto.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, HrorH, Вы писали:
HH>А что будет если newSize == bestSize >= 0 для всех следующих токенов ?
Такого не бывает.
Ибо это две конечные последовательности из неотрицательных элементов, в конце которых стоит -1.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Следи за цитированием.
BC>Ну по производительности код тоже не блещет.
В каком месте?
BC>Лучше сделать копипаст и избавится от гоуту. Слов нет одни эмоции.
BC>Например переход goto best_better; заменить на обычный return.
И превратить самодокументированный код в говно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
хъ
EP>Это замечание относится к альтернативному (стандартному) варианту реализации сортировки, а не к тому что inline даст больше кода чем вызовы. EP>В этом случае как раз наоборот — если выключить inline — то кода получится даже больше, так как у каждой ветки будет в конце выполняться полная перестановка элементов массива. С inline'ом же концы веток merge'аться компилятором, в том числе и безусловным переходом — goto/jmp.
Что есть "альтернативному (стандартному)"? Имеешь в виду обычный runtime код, без переноса его части в compile-time?
Меня не нужно агитировать за compile-time, я сам этого подхода придерживаюсь. В "стандартном" коде инлайн, чуть менее чем всегда дает больше кода. В большинстве случаев этим можно пренебречь, но иногда это становиться не приемлемым по уже озвученной причине. Кроме того, зачастую получается так, что из-за "инлайна" (в широком смысле — напр. развернутого цикла) престает встраиваться горячая ф-я выше по стэку со всеми вытекающими. Впрочем, я уверен, что ты про это прекрасно знаешь. Думаю что и Алекс тоже, но он решил встать в позу.
HH>На следующей ступени надо уметь избавляться полностью от while, foreach, if/switch statement, рекурсии и использовать только функции высшего порядка и сопоставление с образцом.
Здравствуйте, Patalog, Вы писали:
EP>>Это замечание относится к альтернативному (стандартному) варианту реализации сортировки, а не к тому что inline даст больше кода чем вызовы. EP>>В этом случае как раз наоборот — если выключить inline — то кода получится даже больше, так как у каждой ветки будет в конце выполняться полная перестановка элементов массива. С inline'ом же концы веток merge'аться компилятором, в том числе и безусловным переходом — goto/jmp. P>Что есть "альтернативному (стандартному)"? Имеешь в виду обычный runtime код, без переноса его части в compile-time?
По ссылке приведена сортировка, в которой для каждого возможного исхода применения less генерируется код обслуживающий соответствующую ветвь алгоритма. И чем больше элементов в массиве, тем больше будет кода. Если в этом случае делать inline, то кода становится меньше, так как некоторые части ветвей совпадают, и после инлайнинга компилятор может их слить, не говоря уж об оверхеде от call.
В "стандартной" же сортировке размер кода алгоритма не зависит от размера входных данных.
P>Меня не нужно агитировать за compile-time, я сам этого подхода придерживаюсь.
Я здесь не агитирую. Мой поинт в том, что после инлайнинга суммарный размер бинарного кода может как увеличиться, так и уменьшиться.
P>В "стандартном" коде инлайн, чуть менее чем всегда дает больше кода.
Это смотря как считать.
Например можно взять все случаи inline'а, и посчитать долю количества случаев в которых это даёт уменьшение размера кода. Я вот не думаю что тут всё так однозначно — например в C++ во многих случаях inline'а либо вставляется всего несколько инструкций, либо же вообще не добавляется "ничего" — так как повсеместно используются всякого рода dummy wrappers а-ля std::less.
По ссылке приведен спец. случай перевода части вычислений из рантайма на время компиляции. Это несколько иное, чем предлагалось (напомню, предлагалось тупо по-заменять goto на ф-и)
хъ
EP>Я здесь не агитирую. Мой поинт в том, что после инлайнинга суммарный размер бинарного кода может как увеличиться, так и уменьшиться.
...
P>>В "стандартном" коде инлайн, чуть менее чем всегда дает больше кода.
EP>Это смотря как считать. EP>Например можно взять все случаи inline'а, и посчитать долю количества случаев в которых это даёт уменьшение размера кода. Я вот не думаю что тут всё так однозначно — например в C++ во многих случаях inline'а либо вставляется всего несколько инструкций, либо же вообще не добавляется "ничего" — так как повсеместно используются всякого рода dummy wrappers а-ля std::less.
Я и не спорю что в нек. случаях специально обученный compile-time код может быть уменьшен. Но опять таки, вряд ли будет меньше его рантайм аналога, при условии что исходно существенная часть алгоритма не времени компиляции. Возможно даже, что при очень некоторых фазах луны локальный участок "стандартного" может уменьшится. :))
Ты сейчас вступаешь в роли КО, я прекрасно знаю во что схлопывается код типа boost.spirit или boost.simd, не раз рассматривал ассемблер, особенно что касается последнего. Но я опять же знаю, что начиная с опред. момента, компилер начинает генерить call для какого-нибудь make_tuple только потому, что встроилось дохрена барахла из редко срабатывающего условия (а убрать нельзя, и вынести тоже). Или по причине развернутого цикла — а при навязываемом подходе все декомпозировать на инлайн ф-и — нек. небольшие циклы как-то сами собой получаются развернутыми =), и мы на ровном месте огребаем проблемы с кэшем и потом пишем цикл от 0 до 2-х или перестает встраиваться горячая ф-я и начинается закат солнца в ручную каким-нибудь __forceinline.
Здравствуйте, Patalog, Вы писали:
EP>>По ссылке приведена сортировка ... P>По ссылке приведен спец. случай перевода части вычислений из рантайма на время компиляции. Это несколько иное, чем предлагалось (напомню, предлагалось тупо по-заменять goto на ф-и)
А я не говорил что весь пример целиком относится к теме. Я показал конкретное место в котором компилятор применил ту самую оптимизацию на goto/jmp о которой и говорил WolfHound
P>>>В "стандартном" коде инлайн, чуть менее чем всегда дает больше кода. EP>>Это смотря как считать. EP>>Например можно взять все случаи inline'а, и посчитать долю количества случаев в которых это даёт уменьшение размера кода. [...] P>Я и не спорю что в нек. случаях специально обученный compile-time код может быть уменьшен. Но опять таки, вряд ли будет меньше его рантайм аналога, при условии что исходно существенная часть алгоритма не времени компиляции.
Ещё раз, нужно определится с метрикой. Если рассматривать каждый конкретный случай инлайна функции, то может вполне оказаться что в большинстве случаев inline даёт меньше кода. При этом те редкие случаи в которых всё-таки получается больше кода, могут оказывать катастрофическое влияние на суммарный размер кода средне-сферической программы.
[]
EP>Ещё раз, нужно определится с метрикой. Если рассматривать каждый конкретный случай инлайна функции, то может вполне оказаться что в большинстве случаев inline даёт меньше кода. При этом те редкие случаи в которых всё-таки получается больше кода, могут оказывать катастрофическое влияние на суммарный размер кода средне-сферической программы.
Рассматривать цепочки пустых по сути ф-й, которые компилер схлопнет в ноль мне не интересно, извини.
Здравствуйте, Patalog, Вы писали:
EP>>Ещё раз, нужно определится с метрикой. Если рассматривать каждый конкретный случай инлайна функции, то может вполне оказаться что в большинстве случаев inline даёт меньше кода. При этом те редкие случаи в которых всё-таки получается больше кода, могут оказывать катастрофическое влияние на суммарный размер кода средне-сферической программы. P>Рассматривать цепочки пустых по сути ф-й, которые компилер схлопнет в ноль мне не интересно, извини.
Рассмотри не пустые, а короткие. Только один call без передачи аргументов это уже 5 байт кода.
. Чтобы обойтись без goto, можно было бы поставить блок while…end; (и где-то внутри него continue
Самые красивые песни на каком языке? На немецком — Шуберт — необыкновенная красота. Хотя у них там гортанный, странный язык, но невероятно красивый.
Перекуём баги на фичи!
Слов нет одни эмоции.
