«break to out» from for/switch

goto

for(...) {
  switch() {
    case ...:
      ...
      goto exit_for;
  }
}
exit_for:

можно еще c continue поизвращаться

Оберни свой for(...){switch(...){...}} в отдельную функцию и делай return вместо RET = 21. Если переживаешь за оптимизацию, добавь #inline

Гото конечно

в отдельную функцию

Не всегда подходит. А так да, этот метод способствует структурированию кода

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

Я тоже за goto.

Хотя в нормальных языках есть break с меткой.

ну ребята, спасибо... конечно :о) но решил более очевидным и подходящим способом... :о) переИменовал переМенную условия ... она до «этого» была с менее понятным именем

for(i=1; i<BREAK; i++)
...
    BREAK = xxx;

как говориться в классике

- это и охота и убивать ни кого не надо :о)

развернЁте свою мысль, если не сложно?! :о)

xxx

И не поспоришь!

:о)

1. switch вложен в for
2. выброс реализован «хаком» условия for

Как правило, если этот код завернуть в функцию (или несколько функций) то лишние break исчезнут или станут return.

Ну если хочется извращений, то тогда уж надо было

#define EXIT 0

for(i=1; i<RET; i++)
{
...
switch(i)
{
...
  case 10:
  if(){
    ...
    RET = EXIT; // break to out
  }
  break;
...
}

и ... если главная функция состоит только из этого самомго for() то тогда код повысит свою дебильность и неудобочитабельность...:о)

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

имхо

решение найдено! но если есть еще идеи, обязательно предлагайте!

спасибо

Упс, чушь сморозил. Блин лучше уж RET = 0 писать для завершения цикла. А так переделай в функцию и выходи по return.

согласен! просто для «быстрого вкуривания» решил обойтись «просто переименованием»

спасибо

и … если главная функция состоит только из этого самомго for() то тогда код повысит свою дебильность и неудобочитабельность…:о)

bool work_complete(int i, ....) {
  switch ...
}

for(int i ...) {
  ...
  if (work_complete(i, ...)) break;
}

break с меткой это goto и есть, только с запутанным видом

а если таких switch-case() в функции с десяток... :о)

... то тогда код повысит свою дебильность и неудобочитабельность

и/или ... наплодим сущностей, необходимых только внутри одной единственной функции

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

пусть уж лучше будет одна единственная «дебильная» функция

спасибо

Хак уродский, лучше так не делать

Есть такое ключевое слово continue. Комбинируя его с break, можно сделать то что ты хочешь

так блин жешь :о)

BREAK = 0;
or
CNT = BREAK;

или я не правильно понял?!

тут вообще for+switch ненужен..условия-же подряд перебираются в порядке i, одно за другим.

приведённая конструкция (в псевдокоде)

for(int i=1;i<RET....)
switch(i) {
  case 1: if (condition_1) { action1(); i=RET;} break;
  case 2: if (condition_2) { action2();i=RET;} break;
}

аналогично совсем-совсем простому:

if (codition_1) { action1(); }
else if(condition_2) { action2();}
...

не в данном случае :о)

единственный верный совет с функцией. остальное - быдлокод. goto ни при каких случаях нельзя использовать

В каком «данном»? Нам ты дал код очевидно написанный шиворот-навыворот.

Аргументы? Типичный пример использования goto - обработка ошибок. В ядре Linux это используется повсеместно. По твоему мнению это быдлокод?

а то вы сами не знаете... то-то наши ядра дают стране угля :о)

как в том анектоде:

Ой, я вас умоляю! Вы посмотрите на этот мир и на эти брюки!

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

таки кланяюсь во все стороны, сползаю с табуретки, одеваю тапочки

break to out

что мосье хотел этим сказать?

не в данном случае :о)

в данном случае именно так..

более того - взять из реальной жизни иной случай довольно проблемно. комбинация for/switch как-бы намекает что всё через жопу и масса лишнего

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

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

вызов функции, это всего лишь джамп на адрес. с сохранением адреса возврата на стек. goto это тоже джамп на адрес.

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

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

for/switch как-бы намекает
всё через жопу
масса лишнего

блеск! анекдот напомнило

- Садись, Торчун - это пять!

как вам будет угодно!

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

ага экономим спички… и циклы развертываем, а то вдруг коНпилятор не справится. ты мне лучше приведи пример программы, где без goto нельзя обойтись. в других языках есть тоже табуированные операторы, например, with в JavaScript, global php, python (чит: используем возможности ООП)…

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

Вроде, Дейкстра доказал, что структурное программирование (где нет goto) равносильно бесструктурному программированию.

Давай ещё и авторов darktable поучим код писать.

а давайте переменные q,p,q,r,t называть, везде пихать goto и побольше макросов, чтобы все состояло из макросов, и каждый цикл чтобы был развернут

Никто не предлагает пихать goto везде.

То есть ты своим странным примером утверждаешь, что авторы darktable не умеют писать код на C?

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

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

Я не против goto. Это тоже инструмент, у которого есть своя область применения. Для разных задач есть свои инструменты. Для конкретно данного случая функция предпочтительней, чем goto, т.к. она ясно выделяет в коде обработку ситуации выхода из цикла, а с goto при большом теле switch для понимания логики работы в голову придётся загружать лишние сущности.

писать функцию с уверенностью, что компилятор её заинлайнит

В С++ вроде сильно зависит от компилятора. Я где-то вычитал, что стоит только смотреть дизасм, заинлайнилось ли по факту или нет. На https://isocpp.org/wiki/faq/inline-functions решил проверить, есть ли гарантии, но там конкретики особо нет.

Инфы нашёл больше про гарантии, когда точно не будет inline: рекурсии с порогом вложений, превышающий установленный, или явное использование опций а-ля -no-inline. Конкретно эти условия можно обойти с помощью __attribute__ ((always_inline)), но на этом дело заканчивается.

В С есть более строгие гарантии inline или речь про опыт работы с конкретным компилятором?

with

табуированные

Порассказывай мне тут.

https://phoboslab.org/q1k3/

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

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

пример - надо слить, сравнить или еще что - два файла, возвратить bool - успех/неуспех.

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

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

тогда как самый короткий и оптимальный тут код - c goto типа (некий псевдокод)

{
  file a = open(...)
  file b = open(...)

  ...
  if(something_wrong0) goto FAILED__;
  ...
  if(something_wrong1) goto FAILED__;

...
  close(a); //here all is correct
  close(b);
  return true;

FAILED__: //exit if failed
  close(a); 
  close(b); 
  log("critical operation bla-bla failed!");
  return false;
}

raii не рассматриваем, пусть это код сишный.

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

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

плохой goto - который эмулирует стандартный структурный оператор или пересекает границы блока.

там обфусцированный код. что ты им хотел показать/доказать? и в исходниках на гитхабе нету ниодного with…

а в чем «преимущество»??

вы ясночитаемый код превратили в две функции(зачем тут лишняя функция?), причем количество параметров функции handle по сути ничем не ограничено, это зависит от исходной сложности задачи(может там 100 ресурсов возникает? и их надо передать в handle)..

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

вы не показали общее решение - а если таких блоков(которые надо завершить нетривиально) внутри функции много?

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

вам нужен пример функции, где таких блоков с нетривиальным завершением например 5-10, часть из них вложенные, и семантика там сложная(чтобы список параметров ваших handle медом не казался).

а на вопрос - ну и зачем писать всю запутанную эту мутоту? - ответ только один… а чтобы удовлетворить формальному, неизвестно откуда взятому правилу, что goto это плохо…

да выкиньте вы это правило в помойку. goto хорошо, когда оно помогает компактности и читаемости кода.

Я тоже проголосую за goto. Никогда не голосовал, но в этот раз обязательно проголосую, — оператор от народа!