Здравствуйте, 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. Тут есть одна важная деталь. Это надо уметь != это надо делать.

Здравствуйте, WolfHound, Вы писали:

А что будет если newSize == bestSize >= 0 для всех следующих токенов ?

 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;
      }

Здравствуйте, Patalog, Вы писали:

ARK>>Что инлайн приводит к увеличению исполняемого кода — нет, не очевидно. И не только мне: http://rsdn.ru/forum/philosophy/6025071

Автор: Evgeny.Panasyuk
Дата: 23.04.15

P>К сожалению, ты не асилил даже прочитать до конца сообщение на которое ссылаешься — "И начиная с определённого порога, такой вариант станет медленней "классического" подхода, как минимум потому что будет забиваться instruction cache".

Это замечание относится к альтернативному (стандартному) варианту реализации сортировки, а не к тому что inline даст больше кода чем вызовы.
В этом случае как раз наоборот — если выключить inline — то кода получится даже больше, так как у каждой ветки будет в конце выполняться полная перестановка элементов массива. С inline'ом же концы веток merge'аться компилятором, в том числе и безусловным переходом — goto/jmp.

Здравствуйте, Кодт, Вы писали:

К>Это упростит трассировку покрытия кода и позволит компилятору провести какую-нибудь более мощную оптимизацию — например, проинлайнить твою функцию Append() или вывести для неё граничные условия. А так — компилятор увидел, что внутри спагетти, ну и бросил это гиблое дело.
Это даже не смешно.
То у тебя компилятор творит чудеса с трассировкой потока исполнения. То не может проинлайнить функцию с goto. Ты уж определись.

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

К>А вот в языках с ручным управлением ресурсами (Си, бейсик там всякий) — один выход — это борьба за чистоту рук. Ведь перед выходом надо выполнить код освобождения локальных ресурсов. Чем больше выходов, тем больше копипасты.
В случае с дурными языками паттерн

result = ...;
goto exit;

никто не отменял.

К>Вот что я предлагаю.
хъ
К>Код стал страшнее и многословнее. Зато он стал линейным. Для некоторых платформ это одно удовольствие.
Линейным? В каком месте? Я вижу тут кучу ветвлений.

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

Здравствуйте, HrorH, Вы писали:

HH>А что будет если newSize == bestSize >= 0 для всех следующих токенов ?
Такого не бывает.
Ибо это две конечные последовательности из неотрицательных элементов, в конце которых стоит -1.

Здравствуйте, BoobenCom, Вы писали:

Следи за цитированием.

BC>Ну по производительности код тоже не блещет.
В каком месте?

BC>Лучше сделать копипаст и избавится от гоуту.
Слов нет одни эмоции.

BC>Например переход goto best_better; заменить на обычный return.
И превратить самодокументированный код в говно.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

хъ

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.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

хъ

EP>По ссылке приведена сортировка ...

По ссылке приведен спец. случай перевода части вычислений из рантайма на время компиляции. Это несколько иное, чем предлагалось (напомню, предлагалось тупо по-заменять 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 даёт меньше кода. При этом те редкие случаи в которых всё-таки получается больше кода, могут оказывать катастрофическое влияние на суммарный размер кода средне-сферической программы.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

[]

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

Рассматривать цепочки пустых по сути ф-й, которые компилер схлопнет в ноль мне не интересно, извини.

Здравствуйте, Patalog, Вы писали:

EP>>Ещё раз, нужно определится с метрикой. Если рассматривать каждый конкретный случай инлайна функции, то может вполне оказаться что в большинстве случаев inline даёт меньше кода. При этом те редкие случаи в которых всё-таки получается больше кода, могут оказывать катастрофическое влияние на суммарный размер кода средне-сферической программы.
P>Рассматривать цепочки пустых по сути ф-й, которые компилер схлопнет в ноль мне не интересно, извини.

Рассмотри не пустые, а короткие. Только один call без передачи аргументов это уже 5 байт кода.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

[]

EP>Рассмотри не пустые, а короткие. Только один call без передачи аргументов это уже 5 байт кода.

template <typename T>
inline
T (T a, T b)
{ return a + b; }

Вот такая ф-я достаточно короткая? :))