Здравствуйте, S.Yu.Gubanov, Вы писали:

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


SYG>Факт: В языках Си/Си++ не предусмотрена структурная инструкция выхода из нескольких циклов.
SYG>Варианты решения этой проблемы не уменьшающие быстродействия программы:
SYG>1) Забыть о дисциплине программирования и использовать неструктурную инструкцию goto.

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

тот же X/Motif написан на чистом С — исключительно объектно-ориентированная система.

SYG>2) Эмулировать инструкцию выхода из нескольких циклов структурной инструкцией return — выхода из функции.
повторю вопрос:
J>>предлагаешь объявлять функцию с 20 аргументами?

пиар skipped

You will always get what you always got
  If you always do  what you always did

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

J>повторю вопрос:
J>>>предлагаешь объявлять функцию с 20 аргументами?

Повторяю ответ:
http://www.rsdn.ru/Forum/Message.aspx?mid=812536&only=1

Автор: S.Yu.Gubanov
Дата: 17.09.04

Кстати, если не нравятся 20 аргументов, то заведи один — структуру из 20 записей.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Кстати, если не нравятся 20 аргументов, то заведи один — структуру из 20 записей.

Если этот цикл вызывается миллионы раз, этим мы добавим лишние тормоза. А если функцию надо вызвать 2-10 раз с новыми параметрами?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Факт: В языках Си/Си++ не предусмотрена структурная инструкция выхода из нескольких циклов.
SYG>Варианты решения этой проблемы не уменьшающие быстродействия программы:
SYG>1) Забыть о дисциплине программирования и использовать неструктурную инструкцию goto.
SYG>2) Эмулировать инструкцию выхода из нескольких циклов структурной инструкцией return — выхода из функции.

SYG>3) Сменить язык программирования на более современный, например Oberon, в котором есть структурная инструкция EXIT с помощью которой можно выйти из нескольких вложенных циклов.

LOL! С плюсов на оберон . А БЕГИН-ЭНД мы не запаримся нибивать? А вместо шаблонов, что использовать будем? Думаю, что такое предложение, мягко говоря, не вызовет энутузиазма у C/C++ программеров

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

K>Здравствуйте, S.Yu.Gubanov, Вы писали:

K>LOL! С плюсов на оберон . А БЕГИН-ЭНД мы не запаримся нибивать?

А где Вы в Обероне BEGIN-ы увидели? Там BEGIN встречается только в начале тела процедуры или тела модуля. Больше BEGIN-нов там нет. Все остальные синтаксические конструкции построены по контекстно свободной грамматике.
IF b THEN s END;
FOR i:=0 TO 10 DO s END;
WHILE b DO s END;
LOOP s END;
WITH a:T DO s END
Так что BEGIN-ы писать не запаритесь.

K>А вместо шаблонов, что использовать будем?

Слава богу, шаблонов в обычном обероне нет. Но если они Вам так нравятся, то можете использовать версию оберона с шаблонами. Или Вы не знали что есть версия Оберона c шаблонами?

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

J>что угодно можно обозвать кривым дизайном
J>было бы, конечно, здорово, если бы все задачи были простыми и укладывались в простые диаграммы с очевидной логикой
А для чего было придумано другое умное слово: "декомпозиция". Причем придумано оно уже довольно давно, вовсю используется, даже существуют различные методологии этой самой декомпозиции, как ты думешь, к чему все это? Да, я понимаю, что существует еще другое слово "оптимизация", и, как правило, оно сильно конфликтует с простотой и очевидностью кода, но и на оптимизацию есть стоя управа в виде профайлера. А во время разработки рекомендуется забивать на оптимизацию в пользу простоте и очевидности.

J>только вот реальный мир несколько сложнее, и реальные задачи отнюдь не всегда оказываются легко разложимыми на составляющие
А кто говорил, что все будет просто? Это и есть искусство проектирования ПО.

J>большинство научных вычислительных задач именно таковы
Зато они четко формализованы

J>пример, пожалуйста, применения для озвученного случая
Почитай Фаулера "Рефакторинг". У него там примеров полно.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>3) Сменить язык программирования на более современный, например Oberon, в котором есть структурная инструкция EXIT с помощью которой можно выйти из нескольких вложенных циклов.

У червей нет блох, а вот если бы были... (С) Старый анекдот.

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



LG>

LG>while(1)
LG>{
LG>  for(int i = 0; i < 100; i++)
LG>  {
LG>    if(i == 77)
LG>      // вот тут хочу выйти вообще из всех циклов - из  for и из while
LG>  }
LG>}
LG>

LG>Как это сделать?

while(1)
{
  for(int i = 0; i < 100; i++)
  {
    if(i == 77)
      // вот тут хочу выйти вообще из всех циклов - из  for и из while
      goto l1;
  }
}
l1:

Читать >350 сообщений лень.

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

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

J>>что угодно можно обозвать кривым дизайном
J>>было бы, конечно, здорово, если бы все задачи были простыми и укладывались в простые диаграммы с очевидной логикой
V>А для чего было придумано другое умное слово: "декомпозиция". Причем придумано оно уже довольно давно, вовсю используется, даже существуют различные методологии этой самой декомпозиции, как ты думешь, к чему все это? Да, я понимаю, что существует еще другое слово "оптимизация", и, как правило, оно сильно конфликтует с простотой и очевидностью кода, но и на оптимизацию есть стоя управа в виде профайлера. А во время разработки рекомендуется забивать на оптимизацию в пользу простоте и очевидности.

если я обижусь на изложение банальностей, я буду правильно понят? ;)

J>>только вот реальный мир несколько сложнее, и реальные задачи отнюдь не всегда оказываются легко разложимыми на составляющие
V>А кто говорил, что все будет просто? Это и есть искусство проектирования ПО.

я точно не говорил :)

J>>большинство научных вычислительных задач именно таковы
V>Зато они четко формализованы

ага. возьми любой алгоритм из линейной алгебры.

J>>пример, пожалуйста, применения для озвученного случая
V>Почитай Фаулера "Рефакторинг". У него там примеров полно.

вот ты думаешь, что все тут лохи и никто фаулера не читал и слова "декомпозиция" и "рефакторинг" не слышал? ;)

поверь, я говорю не с потолка, а из собственного опыта.
И мне встречалось множество примеров, когда рефакторинг никак не пристегнешь.
Хотя, конечно, обратных примеров неизмеримо больше.

You will always get what you always got
  If you always do  what you always did

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

J>если я обижусь на изложение банальностей, я буду правильно понят?
Просто тут начали говорить, что параметры в структурах — это дополниельный оверхед и пр. и поэтому это не надо использовать... С чем я не согласен.

V>>Зато они четко формализованы
J>ага. возьми любой алгоритм из линейной алгебры.
Если забить на оптимизацию, писать код по принципу: главное чтобы было просто и работало, думаю, особых проблем с линейной алгеброй не будет.


J>вот ты думаешь, что все тут лохи и никто фаулера не читал и слова "декомпозиция" и "рефакторинг" не слышал?
Фаулера я упомянул, чтобы отмазаться от примеров, а про декомпозицию — это у меня был типа сарказм...

J>И мне встречалось множество примеров, когда рефакторинг никак не пристегнешь.
Поделись. Мне интересно. Правда.

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

U>>Если внутри цикла используется 20 переменных, значит, давно пора провести рефакторинг, после которого в цикле останутся вызовы нескольких функций, т.к. иначе никто быстро в использовании 20 переменных не въедет.

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

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

J>Если у меня цикл работает сразу с десятью массивами/хэшами/листами, перелопачивая в них информацию, используя еще десяток (хорошо, если так) внешних параметров перелопачивания этой самой информации — никаким введением новых функций количество контейнеров и параметров изменить не удастся.

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

J>рефакторинг, конечно, — клёвое, модное и красивое слово, но его звучания недостаточно, чтобы делать такие заявления

Рефакторинг — это не только модное и красивое слово, но также и весьма полезное на практических задачах.

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


U>Введением новых функций избавиться от переменных, конечно, не получится...
Ну почему же? Очень даже получится... Если переменная используется один раз, то вместо нее можно вставить вызов ф-ции, производящей расчет значения этой переменной, подобно тому, как это делалось при её инициализации. Для тех, кто спросит: "а зачем это надо?", заранее отвечу, что выигрыш в том, что:
1) эта ф-ция может быть явно описана, как не имеющая побочных эффектов (а переменная может изменяться) и, таким образом, упростится понимание алгоритма.
2) эта ф-ция может быть использована повторно
3) упростится проведение других рефакторингов
Даже если значение переменной используется несколько раз, можно забить на оптимизацию и всеравно сделать ф-цию.
Обо всем этом хорошо написано у Фаулера...

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

J>>Если у меня цикл работает сразу с десятью массивами/хэшами/листами, перелопачивая в них информацию, используя еще десяток (хорошо, если так) внешних параметров перелопачивания этой самой информации — никаким введением новых функций количество контейнеров и параметров изменить не удастся.

U>Чтобы избавиться от количества переменных, нужно объединить десять массивов в несколько объектов, внешние параметры также нужно сгруппировать и объединить в объекты. Функции перелопачивания в этом случае станут составной частью объектов содержащих массивы. В результате код вместо явного использования двацати переменных будет выглядеть как вызовы методов нескольких объектов, в каждый из которых передается небольшое количество параметров, а уж сколько свойств переданного параметра используется внутри метода нам по барабану, хоть тысячу.

J>>рефакторинг, конечно, — клёвое, модное и красивое слово, но его звучания недостаточно, чтобы делать такие заявления

U>Рефакторинг — это не только модное и красивое слово, но также и весьма полезное на практических задачах.

Со всем согласен!!!

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

V>Ну почему же? Очень даже получится... Если переменная используется один раз, то вместо нее можно вставить вызов ф-ции, производящей расчет значения этой переменной, подобно тому, как это делалось при её инициализации.

Полностью согласен. Об этом способе я не подумал.

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

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

J>>если я обижусь на изложение банальностей, я буду правильно понят? ;)
V>Просто тут начали говорить, что параметры в структурах — это дополниельный оверхед и пр. и поэтому это не надо использовать... С чем я не согласен.

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

V>>>Зато они четко формализованы
J>>ага. возьми любой алгоритм из линейной алгебры.
V>Если забить на оптимизацию, писать код по принципу: главное чтобы было просто и работало, думаю, особых проблем с линейной алгеброй не будет.

я не готов жертвовать производительнотью кода в угоду красоте дизайна :)

J>>вот ты думаешь, что все тут лохи и никто фаулера не читал и слова "декомпозиция" и "рефакторинг" не слышал? ;)
V>Фаулера я упомянул, чтобы отмазаться от примеров, а про декомпозицию — это у меня был типа сарказм... :shuffle:

J>>И мне встречалось множество примеров, когда рефакторинг никак не пристегнешь.
V>Поделись. Мне интересно. Правда.

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

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

Когда красивый код считает 8 часов, а некрасивый — четыре, — угадай, что я выберу :)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Слава богу, шаблонов в обычном обероне нет. Но если они Вам так нравятся, то можете использовать версию оберона с шаблонами. Или Вы не знали что есть версия Оберона c шаблонами?

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

Здравствуйте, m.a.g., Вы писали:

MAG>- кто сейчас пишет парсеры вручную? есть же lex/yacc/bison/antlr etc Ведь парсеры — обработка, основанная на
MAG> правилах, структурно писать их не слишком удобно

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

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

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


LG>>Как это сделать?

OO>Например сгенерить исключение:

OO>

OO>try
OO>{
OO>   while(1)
OO>   {
OO>     for(int i = 0; i < 100; i++)
OO>     {
OO>       if(i == 77)
OO>          throw 77;
OO>     }
OO>   }
OO>}
OO>catch(int e)
OO>{
OO>   // e==77
OO>}
OO>

По-моему, исключения стоит использовать для исключительных ситуаций. А здесь не проще ли так:

bool fCondition = true;

while( fCondition )
{
for(int i = 0; i < 100; i++)
{
if(i == 77)
{
fCondition = false;
break;
}
}
}

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



LG>

LG>while(1)
LG>{
LG>  for(int i = 0; i < 100; i++)
LG>  {
LG>    if(i == 77)
LG>      // вот тут хочу выйти вообще из всех циклов - из  for и из while
LG>  }
LG>}
LG>

LG>Как это сделать?


По забрызганной слюнями ярости "колбасе" сообщений данной темы, я понял, что надо ставить goto и не парить себе мозги.

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

S>Ну это уже демагогия пошла — аналогия совершенно некорректная. Попробуй на С++ писать как на прологе.
Ты Loki, например, видел?

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

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

S>>Ну это уже демагогия пошла — аналогия совершенно некорректная. Попробуй на С++ писать как на прологе.
E>Ты Loki, например, видел?

А ты дату поста посмотрел?
Кто дернул поднимать эту доисторическую тему?