Существуют ли задачи, где использование GOTO оправдано?
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 10:21
Оценка: :))) :)
Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.

Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.

01.08.07 13:56: Перенесено из 'Алгоритмы'
Re: Существуют ли задачи, где использование GOTO оправдано?
От: minorlogic Украина  
Дата: 31.07.07 10:28
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.

Если вы хотите разубедить , разве это не значит что у вас и аргументы есть и примеры ?
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: NikeByNike Россия  
Дата: 31.07.07 10:33
Оценка: -14
Здравствуйте, Vedrus, Вы писали:

V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


ИМХО это признак кривизны кода...
Нужно разобрать угил.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 10:45
Оценка: :)
Я тоже считал раньше, что GOTO — признак кривизны. Но после спора с одним преподам (4 часа) признал, что был не прав. Он мне более конкретно выше озвученые темы привёл, но я их забыл . Вот и пытаюсь восстановить.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: sc Россия  
Дата: 31.07.07 10:57
Оценка: +2 :))) :))) :))) :))
Здравствуйте, Vedrus, Вы писали:

V>Я тоже считал раньше, что GOTO — признак кривизны. Но после спора с одним преподам (4 часа) признал, что был не прав. Он мне более конкретно выше озвученые темы привёл, но я их забыл . Вот и пытаюсь восстановить.


Я тоже когда-то с преподом согласился, что подпрограммы/ф-ции — это плохо. Когда третий раз пришел зачет сдавать. И вообще, чем старше становился (а времени становилось меньше), тем чаще с преподами соглашался.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Mycopka Россия http://mhehue.info
Дата: 31.07.07 11:03
Оценка: 3 (3) +1

3.3.2 Оператор goto



Презираемый оператор goto все-таки есть в С++:

goto идентификатор;

идентификатор: оператор

Вообще говоря, он мало используется в языках высокого уровня, но
может быть очень полезен, если текст на С++ создается не человеком,
а автоматически, т.е. с помощью программы. Например,
операторы goto используются при создании анализатора по заданной
грамматике языка с помощью программных средств.
Кроме того, операторы goto могут пригодиться в тех случаях,
когда на первый план выходит скорость работы программы. Один из
них — когда в реальном времени происходят какие-то вычисления во
внутреннем цикле программы.
Есть немногие ситуации и в обычных программах, когда применение
goto оправдано. Одна из них — выход из вложенного цикла или
переключателя. Дело в том, что оператор break во вложенных циклах
или переключателях позволяет перейти только на один уровень выше.
Приведем пример:

           void f()
           {
             int i;
             int j;

             for ( i = 0; i < n; i++)
                 for (j = 0; j<m; j++)
                     if (nm[i][j] == a) goto found;
                 // здесь a не найдено
                 // ...
             found:
                 //  nm[i][j] == a
           }


(c) Бьерн Страуструп. Язык программирования С++. Второе дополненное издание
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
---
With best regards и все такое :)
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Аноним  
Дата: 31.07.07 11:06
Оценка: -2
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.

Использование goto в языках высокого уровня действительно признак кривизны кода. А так goto-подобные команды повсеместно используются в языках низкого уровня, всякие там ассемблеры.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 11:06
Оценка:
Вопрос не в том, что препод лох. Он мне аргументированно объяснил. Препод математик, и очень хорошо разбирается в структурном программировании. Бывает объективная необходимость во включении GOTO, для увеличения быстродействия. Мне бы хотелось услышать ответы от тех, кто считает, что GOTO имеет право на жизнь с конкретными примерами. Остальные не обижайтесь, но не надо писать сюда.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 11:09
Оценка:
Спасибо, хорошая статья. Копаем дальше.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: _pk_sly  
Дата: 31.07.07 11:13
Оценка: 2 (1)
1. выход из вложенных if/switch/while на нужный уровень.

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

3.
for (...) {
  if (...) break;
}
// а тут надо что-то сделать в случае, если выход из цикла был не по break


4. выполнение cleanup-кода перед выходом из функции


disclaimer: я не призываю всегда в этих случаях пользоваться goto
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 31.07.07 11:13
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


V>>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


NBN>ИМХО это признак кривизны кода...


Напишите этот кусочек кода не криво плиз, а то я никак не соображу как

for(int i=0;i<n1;++i) {
  for(int j=0;j<n2;++j) {
    if(come_condition1) goto next1;
    for(int k=0;k<n3;++k) {
      if(come_condition2) goto next2;
    }
    // some code
  }
  next2:
  // some code
}
next1:
// some code
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Сергей Мухин Россия  
Дата: 31.07.07 11:21
Оценка: 1 (1) :)
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


здесь
Автор: MaximE
Дата: 31.03.05
---
С уважением,
Сергей Мухин
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 11:39
Оценка:
unreg_flex, _pk_sly, Сергей Мухин, спасибо, интересные примеры привели.
_pk_sly, можете уточнить по п.2? Я тоже где-то слышал, что в автоматах GOTO используется, но не могу сообразить зачем. Почему простой switch/case с селектором состояний не подойдёт?

ЗЫ. Может у кого ещё примеры есть
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 11:39
Оценка: +2
Здравствуйте, unreg_flex, Вы писали:

_>Напишите этот кусочек кода не криво плиз, а то я никак не соображу как


_>
_>for(int i=0;i<n1;++i) {
_>  for(int j=0;j<n2;++j) {
_>    if(come_condition1) goto next1;
_>    for(int k=0;k<n3;++k) {
_>      if(come_condition2) goto next2;
_>    }
_>    // some code
_>  }
_>  next2:
_>  // some code
_>}
_>next1:
_>// some code
_>


Ну дык он и так криво написан.

_> for(int k=0;k<n3;++k) {

_> if(come_condition2) goto next2;
_> }
Должно быть вынесено в функцию (или скорее использована стандартная)

_> for(int j = 0; j < n2; ++j) {

_> if(come_condition1 || find_by_condition2)
_> break;
_> // some code
_> }
Это тоже. Скорее всего оптимайзер это соптимайзит.

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

GOTO для отчистки кода — в 99.95% случаях самое что ни есть зло. Нормальный программист будет использовать автоматику (конструкторы/деструкторы).
GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции. Глядя на этот код — сразу появляется мысль, что у её авторов бывают функции больше чем на страницу и целый ряд прочих проблем.
Нужно разобрать угил.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 11:43
Оценка:
unreg_flex, _pk_sly, Сергей Мухин, спасибо, интересные примеры привели.
_pk_sly, можете уточнить по п.2? Я тоже где-то слышал, что в автоматах GOTO используется, но не могу сообразить зачем. Почему простой switch/case с селектором сосотяний не подойдёт?

ЗЫ. Может у кого ещё примеры есть
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Кодт Россия  
Дата: 31.07.07 11:46
Оценка: 4 (1)
Здравствуйте, unreg_flex, Вы писали:

_>Напишите этот кусочек кода не криво плиз, а то я никак не соображу как


1) Если не зарубаться на то, что всё это должно лежать внутри одной функции, то можно переделать, раскидав циклы по функциям.
2) Булевы флажки.

Кстати, можно заподозрить, что этот код — либо наглухо заоптимизирован, либо содержит логические ошибки, либо просто взят с потолка.
Потому что описания задач всё-таки тяготеют к иерархическим структурам (деревья принятия решений, рекурсивные формулы...), а граф конечного автомата — это результат трансляции.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: _pk_sly  
Дата: 31.07.07 11:49
Оценка:
V>_pk_sly, можете уточнить по п.2? Я тоже где-то слышал, что в автоматах GOTO используется, но не могу сообразить зачем. Почему простой switch/case с селектором состояний не подойдёт?

подойдёт.

это разные подходы к одному и тому же.

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

state_1:
  switch (signal) {
    case 1: goto state_5;
    case 2: goto state_10;
    case 3: goto state_8;
  }
state_2:
  switch (signal) {
    case 7: goto state_37;
    case 10: goto state_1;
    case 9: goto state_100;
  }
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: Vedrus Лес www.Indigo.RingingCedarsOfRussia.org
Дата: 31.07.07 11:56
Оценка:
А с точки зрения производительности эти варианты как-то отличаются? Или ещё чем?
Если не отличаются, то моё субъективное мнение, что с селекотором лучше
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: _pk_sly  
Дата: 31.07.07 12:01
Оценка:
V>А с точки зрения производительности эти варианты как-то отличаются? Или ещё чем?
V>Если не отличаются, то моё субъективное мнение, что с селекотором лучше

да, отличаются.

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

но обычно, goto — значительно быстрее.

вариант с селектором тоже имеет право на жизнь
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: elmal  
Дата: 31.07.07 12:04
Оценка: 1 (1)
Здравствуйте, unreg_flex, Вы писали:

_>Напишите этот кусочек кода не криво плиз, а то я никак не соображу как


_>
_>for(int i=0;i<n1;++i) {
_>  for(int j=0;j<n2;++j) {
_>    if(come_condition1) goto next1;
_>    for(int k=0;k<n3;++k) {
_>      if(come_condition2) goto next2;
_>    }
_>    // some code
_>  }
_>  next2:
_>  // some code
_>}
_>next1:
_>// some code
_>


Легко:

Можно свести к:
doSomeActivityInFor();
//someCode;

Главный цикл вынес бы в одну функцию
inline void doSomeActivityInFor() {
  for(int i=0;i<n1;++i) {
    for(int j=0;j<n2;++j) {
      if(come_condition1) return;

      if (some_condition3(i,j) {
         break;
      }
     // some code
   }
   // some code
}

inline bool some_condition3(i,j) {
   for(int k=0;k<n3;++k) {
      if(come_condition2()) return true;
   }
   return false;
}


При достаточно удачных выбранных именах для подфункций, на которые я разбивал, ИМХО код становится гораздо более читабельным. В исходном коде плох не сам оператор goto, а то, что имеем 2 вложенных цикла, в которых к тому же вложены еще и условия (хотя допустимый предел сложности не пройден). Я при разбиении не избавился от оператора goto, а избавился от некоторых недостатков кода. Макконел говорит например, что оператор goto не плох сам по себе, но часто соседствует с плохим кодом. И в случае, если бы исходный код также содержал 3 вложенных цикла без goto — все равно бы имело смысл упростить код (Я привел не все упрощения, ИМХО стоило бы продолжить).
Re: Существуют ли задачи, где использование GOTO оправдано?
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 12:06
Оценка: 9 (1) +1 :)
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


Goto — признак не кривизны кода, а кривизны языков, в которых без него порой никак (C, C++, C#, Pascal, Java, etc) и кривизны профанации под названием "структурное программирование" с его т.н. "циклами с предусловиями", "циклами с постусловиями" и "ветвлениями", которые являются не элементарными конструкциями, а типовыми паттернами, в которые задача не всегда удобно ложится.

Правда, пока для всяких Haskell не понаписали мегаоптимизаторов, Goto будет актульно для кодогенераторов в другие, более "низкоуровневые" языки.

Так что если кто-то пишет на C++ и вынужден юзать goto, пусть не стесняется, и посылает своих знакомых на 3 весёлых буквы. В конце концов, это не его вина. Кстати, виной K&R и Бьярни это тоже не является, т.к. это не они призывают в наш просвещённый XXI век всё и вся писать на C++ и (о боже!) на C.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Сергей Мухин Россия  
Дата: 31.07.07 12:42
Оценка:
K>Так что если кто-то пишет на C++ и вынужден юзать goto, пусть не стесняется, и посылает своих знакомых на 3 весёлых буквы. В конце концов, это не его вина. Кстати, виной K&R и Бьярни это тоже не является, т.к. это не они призывают в наш просвещённый XXI век всё и вся писать на C++ и (о боже!) на C.

Давайте на этой ноте и закончим. Или все бегом в "Свещенные войны"!!!
---
С уважением,
Сергей Мухин
Re: Существуют ли задачи, где использование GOTO оправдано?
От: last shinji  
Дата: 31.07.07 13:15
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


Goto в MSDN. Встретилось однажды.
http://support.microsoft.com/kb/182888
Носок исчез в гильбертовом пространстве. Туда ему и дорога.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 31.07.07 13:26
Оценка: +2 -1
Здравствуйте, NikeByNike, Вы писали:

NBN>Ну дык он и так криво написан.


_>> for(int k=0;k<n3;++k) {

_>> if(come_condition2) goto next2;
_>> }
NBN>Должно быть вынесено в функцию (или скорее использована стандартная)
При чем тут стандартные функции?
В исходной функции 4 параметра +2 ссылки на структуру, и большинство из них используется
при вычислении come_condition1 и come_condition2, идиотизм ради отсутствия четырех символов 'goto'
заводить метод (или несколько методов) делающий непонятно что и с непонятно какими параметрами.

_>> for(int j = 0; j < n2; ++j) {

_>> if(come_condition1 || find_by_condition2)
_>> break;
_>> // some code
_>> }
NBN>Это тоже. Скорее всего оптимайзер это соптимайзит.
Дело даже не в оптимизации, а в том что каждое из условий может быть вычислено только там где оно стоит.

NBN>Сам по себе кусок кода — ужасен, сразу мысль — этот код нужно рефакторить.

Вот я и спросил у вас как?
Чем он ужасен в вашем понимании?
Приведите пример красивого рефакторинга Дабы увеличить читабельность кода.

NBN>Если это не критический участок кода — его нужно сделать красивее.

Опишите ваше понимание красоты (оно у всех разное).
Если критический — менять алгоритм.

Это критический участок кода, сложность N^3, предлагаете сделать за N^4?
Тут обычный перебор всех троек точек заданного множества с перестановками (алгоритм RANSAC для подбора кривой).
Ума не приложу, как это можно сделать по другому.

NBN>GOTO для отчистки кода — в 99.95% случаях самое что ни есть зло.

Откуда число 99.95%?, до боли знакомая рекламная константа
Как считали?
В чем заключается зло?

NBN>Нормальный программист будет использовать автоматику (конструкторы/деструкторы).

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

NBN>GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции.

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

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

Эта функция занимает меньше страницы, хотелось бы конкретизации "ряда прочих проблем".
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 31.07.07 13:34
Оценка: +1
Здравствуйте, Кодт, Вы писали:

К>1) Если не зарубаться на то, что всё это должно лежать внутри одной функции, то можно переделать, раскидав циклы по функциям.

См пост для выше.
К>2) Булевы флажки.
Введение пачки булевых флажков и нескольких функций с кучей параметров несомненно увеличит, как читабельность, так понимание происходящего.

К>Кстати, можно заподозрить, что этот код — либо наглухо заоптимизирован, либо содержит логические ошибки, либо просто взят с потолка.

Это перебор по всем тройкам точек (модифицированный алгоритм RANSAC), с потолка ничего не взято и ошибок тут нет.

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

Это банальный МатСтат
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 13:59
Оценка:
Здравствуйте, unreg_flex, Вы писали:

NBN>>Должно быть вынесено в функцию (или скорее использована стандартная)

_>При чем тут стандартные функции?
Вполне возможно что конечный цикл можно заменить на std::find_if или что то подобное.

_>В исходной функции 4 параметра +2 ссылки на структуру, и большинство из них используется

Этого не видно из исходного кода

_>при вычислении come_condition1 и come_condition2, идиотизм ради отсутствия четырех символов 'goto'

_>заводить метод (или несколько методов) делающий непонятно что и с непонятно какими параметрами.
Как раз наоборот. На то они и методы что понятно что делают, в отличии от готу. Названия надо нормальные давать.

NBN>>Сам по себе кусок кода — ужасен, сразу мысль — этот код нужно рефакторить.

_>Вот я и спросил у вас как?
Тебе кажется уже показали в соседнем ответе. Я показал тебе принципы рефакторинга, отдельные модули на которые нужно разделить код

_>Приведите пример красивого рефакторинга Дабы увеличить читабельность кода.

Уже приели

NBN>>Если это не критический участок кода — его нужно сделать красивее.

_>Опишите ваше понимание красоты (оно у всех разное).
Ну, тут тебе надо почитать классиков.

_>Это критический участок кода, сложность N^3, предлагаете сделать за N^4?

Я??? Где я предлагаю N4??? Я вообще не знаю что это за алгоритм и с какого перепугу это критический участок кода. Это кодек какой-то?

NBN>>GOTO для отчистки кода — в 99.95% случаях самое что ни есть зло.

_>Откуда число 99.95%?, до боли знакомая рекламная константа
_>Как считали?
Это прикидка — какая доля людей дрова пишет (0.05%).

_>В чем заключается зло?

Гм. А как у тебя с С++? Зачем нужны конструкторы/деструкторы? А смартпоинтеры?
Когда в последний раз один чел задавал подобный вопрос — выяснилось, что он со строками руками работал (char*, выделение и освобождение памяти ручками). Ты тоже этим страдаешь? Когда это возможно — исключения используешь? Контейнеры?


NBN>>Нормальный программист будет использовать автоматику (конструкторы/деструкторы).

_>Нормальный программист будет писать понятно лаконично и эффективно.
По твоему это типа так?
for(int i=0;i<n1;++i){for(int j=0;j<n2;++j){if(c1)goto next1;for(int k=0;k<n3;++k){if(c2)goto next2;}}next2:;}next1:;

Судя по отсуствию пробелов в for'ах действительно лаконично написано...
Я предпочитаю писать так чтобы хорошо читалось.


NBN>>GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции.

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

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

_>Эта функция занимает меньше страницы, хотелось бы конкретизации "ряда прочих проблем".
Во-первых, я не сказал что-то конкретно про эту функцию. Я сказал, что глядя на стиль этой фунциии — начинаешь подозреать в плохом стиле и другие функции. К плохому стилю относятся длинные функции.
Во-вторых, это что всё тело функции??? Я так понимаю логика прогаммы помещена в operator bool() для come_condition1 и come_condition2?
Нужно разобрать угил.
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: Phoenics Россия https://sourceforge.net/projects/phengine
Дата: 31.07.07 14:18
Оценка: 4 (1) +1
Здравствуйте, Vedrus, Вы писали:

V>Вопрос не в том, что препод лох. Он мне аргументированно объяснил. Препод математик, и очень хорошо разбирается в структурном программировании. Бывает объективная необходимость во включении GOTO, для увеличения быстродействия. Мне бы хотелось услышать ответы от тех, кто считает, что GOTO имеет право на жизнь с конкретными примерами. Остальные не обижайтесь, но не надо писать сюда.




Конкретный пример привести не могу так как давно его забыл. Писал как-то переборщик паролей. Долго его оптимизировал разыми способами, так же у меня там был в цикле один оператор GOTO — дало по результатам профилировки VTune 30% прирост производительности. Конечно можно было написать цикл 100000-способов без GOTO, и я многие из них перепробовал, но из тех что я пробовал только этот дал столь существенный прирост.

Это был единственный раз в моей жизни, когда я использовал GOTO.

Вообще моё мнение такое — GOTO имеет право жить. Это такой же инструмент программирования как и любой другой, но этим инстурментом нужно ОЧЕНЬ аккуратно пользоваться, необходимость в нём возникает КРАЙНЕ редко. Я согласен с твоим преопдом что для оптимизации КРИТИЧНЫХ кусков кода, ИЗРЕДКА оператор GOTO может быть использован с пользой.

А вообще при программировании GOTO конечно является признаком кривизны кода. Знаю товарищей окторые пишут циклы, в циклах свичи километровые и в кейсах GOTO... Без целей оптимизации — просто так пишут... Код такой поддерживать просто кошмар.
---=== С наилучшими пожеланиями, Phoenics ===---
_
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 14:25
Оценка:
Здравствуйте, Phoenics, Вы писали:

P>Вообще моё мнение такое — GOTO имеет право жить. Это такой же инструмент программирования как и любой другой, но этим инстурментом нужно ОЧЕНЬ аккуратно пользоваться, необходимость в нём возникает КРАЙНЕ редко. Я согласен с твоим преопдом что для оптимизации КРИТИЧНЫХ кусков кода, ИЗРЕДКА оператор GOTO может быть использован с пользой.


P>А вообще при программировании GOTO конечно является признаком кривизны кода. Знаю товарищей окторые пишут циклы, в циклах свичи километровые и в кейсах GOTO... Без целей оптимизации — просто так пишут... Код такой поддерживать просто кошмар.


Подписываюсь.
Нужно разобрать угил.
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: Кодт Россия  
Дата: 31.07.07 15:32
Оценка:
Здравствуйте, unreg_flex, Вы писали:

К>>Кстати, можно заподозрить, что этот код — либо наглухо заоптимизирован, либо содержит логические ошибки, либо просто взят с потолка.

_>Это перебор по всем тройкам точек (модифицированный алгоритм RANSAC), с потолка ничего не взято и ошибок тут нет.

Тогда остаётся первый вариант: этот код заоптимизирован
Дай, пожалуйста, ссылку на описание алгоритма. А то "come_condition" и "//some code" не очень отражают суть. То ли это хитрая отсечка, то ли хитрый поиск.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 15:51
Оценка: 1 (1)
Здравствуйте, NikeByNike, Вы писали:

NBN>>>Должно быть вынесено в функцию (или скорее использована стандартная)

_>>При чем тут стандартные функции?
NBN>Вполне возможно что конечный цикл можно заменить на std::find_if или что то подобное.

Ага, map/filter/fold.

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


Названия внятные быстро заканчиваются, как раз после после do_that_mysterious_thing_2 и do_that_mysterious_thing_3.

NBN>Это прикидка — какая доля людей дрова пишет (0.05%).


А мне казалось, это ссылка на правило трёх сигм.

_>>В чем заключается зло?

NBN>Гм. А как у тебя с С++? Зачем нужны конструкторы/деструкторы? А смартпоинтеры?

Деструкторы нужны, потому что нет GC. Смартпоинтеры — потому же.

NBN>>>GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции.

_>>Угу, обязательно на отдельные, даже когда во вложенных циклах используется десяток параметров.
NBN>Функторы?

Замыкания?

_>>Вы никогда не используете вложенных циклов?

NBN>Использую, правда два вложенных — это максимум на одну функцию и в дальнейшем это очень часто подвергается рефакторингу.



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

_>>Эта функция занимает меньше страницы, хотелось бы конкретизации "ряда прочих проблем".
NBN>Во-первых, я не сказал что-то конкретно про эту функцию. Я сказал, что глядя на стиль этой фунциии — начинаешь подозреать в плохом стиле и другие функции. К плохому стилю относятся длинные функции.

Сам когда-то в детстве (а это было как раз во время чтения мной рекомендаций по оформлению кода в GNU) страдал от подобных комплексов. Но после того, как изучил Scheme, быстро от них избавился. Это на Scheme и Haskell можно писать лаконично. А если нужно писать на C#, то нечего комплексовать, если метод занимает 200 строк. В конце-концов, есть комментарии, форматирование. Кроме того, сейчас столкнулся с такими задачами... Например, вычислительная геометрия. Где бы не смотрел исходники, везде получается длинно, так что сам не очень комплексую. Ах, как мне на работе не хватает Nemerle, с его вложенными функциями, замыканиями, лямбдами, map/filter/fold!
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[7]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 16:20
Оценка:
Здравствуйте, konsoletyper, Вы писали:

_>>>В чем заключается зло?

NBN>>Гм. А как у тебя с С++? Зачем нужны конструкторы/деструкторы? А смартпоинтеры?

K>Деструкторы нужны, потому что нет GC. Смартпоинтеры — потому же.


Мы вроде-бы про С++ Кстати, с какого-то момента (когда в проекте не остаётся слова delete) нивелируется разница в программировании с GC и без него. А скорость программы остаётся.
Нужно разобрать угил.
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 31.07.07 16:55
Оценка: +1 -2
Здравствуйте, NikeByNike, Вы писали:

NBN>Мы вроде-бы про С++


А мне казалось — про goto.

NBN> Кстати, с какого-то момента (когда в проекте не остаётся слова delete) нивелируется разница в программировании с GC и без него. А скорость программы остаётся.


Вот я и говорю: смартпоинтеры нужны, потому что нет GC. А выделенное — ложь, т.к. GC гораздо быстрее смартпоинтеров, а managed heap — быстрее unmanaged heap. Да и проблем от этих смартпоинтеров куча. Начиная хотя бы с того, что нужно не забывать использовать именно их, а не воспользоваться сдуру обычным указателем.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 31.07.07 17:07
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Этого не видно из исходного кода


Согласен, хотелось как проще а получилось как всегда, вот оригинал этого метода:

template< class ValueType >
void EstimateContour(
  const TGL::Point< ValueType,2 > *pPoints,
  int nPoints,
  const TGL::Polygon< ValueType,2 > &rPolygon,
  const CirclesCondition &rCirclesCond,
  const PointsCondition &rPointsCond) {

  msg_assert(nPoints>0,"Множество точек пусто");

  std::vector< TGL::Circle< ValueType > > Circles;
  TGL::Point< ValueType,2 > Inv1,Inv2;
  TGL::Circle< ValueType > c;

  Inv1=Inv2=pPoints[0];

  for(int i=0;i<nPoints;++i) {
    // отбрасываем точки вне оболочки
    if(!rPolygon.IsPointIn(pPoints[i])) continue;

    for(int j=i+1;j<nPoints;++j) {
      // первое условие двойственности
      if(!rCirclesCond.CheckFirst(pPoints[i],pPoints[j],rPointsCond)) goto next1;
      rPointsCond.Invert(Inv1,pPoints[j]);

      for(int k=j+1;k<nPoints;++k) {
        // второе условие двойственности
        if(!rCirclesCond.CheckSecond(pPoints[j],pPoints[k],rPointsCond)) goto next2;
        rPointsCond.Invert(Inv2,pPoints[k]);

        c.Estimate(pPoints[i],pPoints[j],pPoints[k]);
        c.Refine(Inv1,Inv2);
        // сохраняем если центр окружности принадлежит оболочке
        // и найденные параметры входят в заданный диапазон
        if(rPolygon.IsPointIn(c.Center())&&
           rCirclesCond.Check(c)) Circles.push_back(c);
      }
      
    }
    next2:;
  }
  next1:;
  EstimateHull(Circles,pPoints,nPoints);
}


NBN>Я??? Где я предлагаю N4??? Я вообще не знаю что это за алгоритм и с какого перепугу это критический участок кода. Это кодек какой-то?

Не совсем, но нечто подобное.

NBN>Это прикидка — какая доля людей дрова пишет (0.05%).

Дрова это теже программы, в которых также как и везде гото может встретится а может и не встретится.

NBN>Гм. А как у тебя с С++? Зачем нужны конструкторы/деструкторы? А смартпоинтеры?

NBN>Когда в последний раз один чел задавал подобный вопрос — выяснилось, что он со строками руками работал (char*, выделение и освобождение памяти ручками). Ты тоже этим страдаешь? Когда это возможно — исключения используешь? Контейнеры?
Нееее, мы ничего такого не используем, все пишем только в машинных кодах
А если серьезно:
boost мы не юзаем, из того что нам требуется там почти ничего нет.
stl используем везде где это возможно, однако до сих пор ни у кого в коде даже не нашлось нормальное применение обычным спискам из стл.
Либо количество элементов очень невелико (порядка 10-20) и можно обойтись обычным вектором или использовать массив указателей,
либо оно велико и можно легко найти верхнюю оценку, других случаев почему-то небыло.
А как только нужно реализовать какой-нибудь специализированный геометрический алгоритм (к примеру),
то для него не подходит ни один из стандартных контейнеров стл, и приходится все писать самим (например N мерный кластер точек).
Исключения не используем вообще, и более того, открою страшный секрет
Мы два года назад отказались от проверок на ошибки выделения памяти
И с тех пор ни разу, ни одна из наших програм не упала по этой причине.
А насчет смартпоинтеров скажу:
COM мы не используем (не та область разработки), хотя иногда бывает, ну например MSXML подключить.
А других применений для него так и не нашлось.
Однажды, очень давно, на старом месте работы (не скажу где) люди шарахались с ужасной гримасой от строчки вида: SomeType *p;
И пихали смартптры везде где только можно их запихнуть, но от этого количество багов почемуто не уменьшалось.
По сути все эти биндеры смартптры итераторы (которые на самом деле вовсе не итераторы) фишки из буста (я не имею ввиду алгоритмы)
и прочая хренотень есть большой набор костылей призванный хоть как-то внести в язык отсутствующую функциональность.
Лично мое мнение таково, если ее там нет, то нечего и рыпаться, а если она нужна, то надо выбирать язык по ее наличию.

NBN>>>Нормальный программист будет использовать автоматику (конструкторы/деструкторы).

А кто их не использует при программировании на С++?

NBN>По твоему это типа так?

NBN>
NBN>for(int i=0;i<n1;++i){for(int j=0;j<n2;++j){if(c1)goto next1;for(int k=0;k<n3;++k){if(c2)goto next2;}}next2:;}next1:;
NBN>

Не надо утрировать, ни я, ни кто-либо из нашей команды такого не писал.
NBN>Судя по отсуствию пробелов в for'ах действительно лаконично написано...
Пробелы в форах это так?: for ( int i = 0; i < n; ++i ) { }
Что я могу тут сказать, в нашем отделе работает 6 человек и многие пишут по разному:
Например так:
for( int i = 0; i < n; ++i )
{
}

Так:
for( int i=0; i<n; ++i ) {
}

Или так:
for(int i=0;i<n;++i)
{
}

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

NBN>Я предпочитаю писать так чтобы хорошо читалось.

Аналогично.

NBN>>>GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции.

NBN>Использую, правда два вложенных — это максимум на одну функцию и в дальнейшем это очень часто подвергается рефакторингу.
Параноидальное разнесение вложенных циклов на функции?

NBN>Функторы?

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

NBN>Ну, тут тебе надо почитать классиков.

Читали мы и классиков и современников.

NBN>названия надо нормальные давать... вполне возможно можно заменить... принципы рефакторинга... отдельные модули...

Это мы все видели и слышали, теперь я привел полную версию метода. Напишите этот метод как считаете нужным. И сравним читабельность

PS Любые, даже самые хорошие советы содержат исключения. Тем же свойством обладают и советы в книгах.
Поэтому если пишут что делать нужно так и сяк, то это вовсе не значит что надо поступать именно так и именно сяк фанатично и всегда.
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 31.07.07 17:15
Оценка:
Здравствуйте, Кодт, Вы писали:

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


К>Дай, пожалуйста, ссылку на описание алгоритма. А то "come_condition" и "//some code" не очень отражают суть. То ли это хитрая отсечка, то ли хитрый поиск.


Оригинальная процедура
Автор: unreg_flex
Дата: 31.07.07
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Нэчер  
Дата: 31.07.07 21:21
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


Не надо их переубеждать. Возможно они считают данный стиль "плохим", потому что сами используют "хороший". Значит нашли удобный лично для себя набор правил, позволяющий минимизировать количество ошибок в коде.
Я вот еще слышал мнение, будто return не из конца метода, а также использование "do{ }while(...);" это тоже плохой стиль... Ну и на здоровье!

Касаемо GOTO:

1)Вот, для примера, ф-ия аналог strstr для поиска одной подстроки внутри другой:

const char* strnstr(const char* pStr,int nStrLength,const char* pSubStr,int nSubStrLength)
{
    nStrLength-=nSubStrLength;
    for(int i=0;i<=nStrLength;++i,++pStr)
    {
        for(int j=0;j<nSubStrLength;++j)
           if(pSubStr[j]!=pStr[j]) goto NEXT;//a)Можно было бы использовать "break"

        //b)А здесь мог бы быть "if(j>=nSubStrLength)"
        return pStr;

        NEXT:;//c)Ну и само собой, этой метки здесь тоже могло бы не быть
    }
    return 0;
}

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

2) Есть один замечательный трюк с метками (помню, что точно работало в VC6.0):

bool add(int a,int b,int& c)
{
  c=a+b;

  //А теперь проверим - было ли переполнение?
  __asm
  {
    jc CarryFlag 
  }

  //no carry
  return 0;

  CarryFlag:;

  //carry
  return 1;
}


Если подойти к вопросу трезво, то можно о-го-го сколько наоптимизировать в разного рода вычислительных алгоритмах =)
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 31.07.07 21:37
Оценка:
Здравствуйте, _pk_sly, Вы писали:

__>1. выход из вложенных if/switch/while на нужный уровень.


__>2. сгенерированные конечные автоматы зачастую этим пользуются для перехода между состояниями

однозначно

pozicionN:
///////
switch()
{  case 1: goto pozicion1;
///////////////////////
}

__>3.
__>
__>for (...) {
__>  if (...) break;
__>}
__>// а тут надо что-то сделать в случае, если выход из цикла был не по break
__>


вообщето можно так
for(... ;; ...)
{  if(end())
   { /* а тут надо что-то сделать в случае, если выход из цикла был не по */      break;
   }
   .................
   if (...) break;
   ..............
}

насчет читабельности но метку ставить не нужно

__>4. выполнение cleanup-кода перед выходом из функции



__>disclaimer: я не призываю всегда в этих случаях пользоваться goto




Теперь про функции, собственно 2 АЛЛ


void foo()
{  DoSDELATb_VSE();
   DoSDELATb_IS4E_RAZ();
   DoZAKON4ITb();
}

Если ктото скажет что этот код нечитабельный, он будет не прав. Но если ктото скажет что он читабельный он тоже будет неправ.

Дело в следующем — тут ровно 2 случая.
Либо этот код работает, тогда он читабельный. Но в этом случае мне не назачем ненужно его читать.
Либо он не работает, тогда нужно лазить досконально во все Do и он ну совсем не читабельный
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Пётр Седов Россия  
Дата: 31.07.07 21:53
Оценка:
Здравствуйте, Vedrus.
Есть два очень разных случая.

1. goto назад. Это плохой способ сделать цикл, например:
Connect:
  ...
  goto Connect;

last shinji привёл ссылку на такой код здесь
Автор: last shinji
Дата: 31.07.07
.

2. goto вперёд. Это нормально, примеры (для C++):
* return в середине функции – досрочно завершить выполнение функции и передать управление на строчку за вызовом функции.
* break в цикле – досрочно завершить выполнение цикла и передать управление на строчку за циклом.
* continue – досрочно завершить выполнение итерации цикла и передать управление на следующую итерацию. А если следующей итерации нет, то передать управление на строчку за циклом.
* throw (и longjmp) – досрочно завершить выполнение кода (обычно из-за аварии) и передать управление обработчику исключения (блок catch).

Например, Фредерик Брукс в книге «Мифический человеко-месяц»
Автор(ы): Фредерик Брукс
Эта книга — юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта. Если вы никогда не слышали об этой книге, вы можете поискать ссылки на нее в Интернете (Frederick P. Brooks, The Mythical Man-Month). Вам все сразу станет понятно.
пишет (здесь):

Глава 13. Целое и части

Проектирование без ошибок

Структурное программирование

В основе, несомненно, лежат здравые мысли. При обсуждении сделано много критических замечаний — в частности, большое удобство представляют дополнительные управляющие структуры, такие как n-вариантный переход (так называемый оператор CASE) для различения среди нескольких случаев и аварийный выход (GO TO ABNORMAL END). Кроме того, некоторые догматически избегают всех GO TO, что представляется чрезмерным.

Пётр Седов (ушёл с RSDN)
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 31.07.07 21:56
Оценка: 1 (1)
Здравствуйте, Нэчер, Вы писали:

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


+1. Вообще, поиск и применение правильных удобных шаблонов — крайне важная часть работы и построения своего опыта, даже если использует столь "нелюбимые" средства.

Н>Я вот еще слышал мнение, будто return не из конца метода, а также использование "do{ }while(...);" это тоже плохой стиль... Ну и на здоровье! :xz:


Это мнение, кстати, основывается на том, что break, continue и return — это те же goto. По сути так и есть, и если уж исходить из позиций "структурного" программирования полностью, то их не должно быть. Одна точка входа — одна точка выхода. Внутри — линейное выполнение, ветвления и циклы. Всё что за пределами этого подхода — уже резко усложняется в доказательстве.

Но есть ещё один момент (известный, но в данном треде вроде не звучал). Дело в том, что break, continue, return, а за компанию и throw — являются формами goto, ограниченными в действии наружу блока (включая тело функции). Поэтому, даже если они влияют на часть доказательности (например, о соблюдении инвариантов в теле цикла) — они не вводят таких грубых ситуаций, как переход внутрь цикла без прохождения пролога цикла. goto же, в отличие от них, в языках типа Си не имеет языковых ограничений подобного рода (ни синтаксически, ни в обязательном или рекомендованном анализе семантики). Поэтому его проблемы не в выходе из вложенных циклов, а в значительно более извращённых применениях, которые я упомянул и которые наверняка не приходят в голову апологетам его отсутствия:)

Единственный компилятор, про который я точно знаю, что он жёстко запрещал такие действия, как переход внутрь цикла или ветки if'а — Microsoft Fortran версии как минимум с 4-й.

Я лично отношусь к goto достаточно лояльно, по крайней мере в пределах определённых шаблонов использования:
1. Завершение работы функции с освобождением занятого и возвратом изменённого, для избежания дублирования кода по освобождению/очистке/возврату (потому что такое дублирование приводит к ошибкам в ~99% написаний).
2. Близко к первому — постепенный откат изменений в том случае, если действий много, откатывать их надо в обратном порядке, а вложенность в случае структурного написания получится чрезмерной.
3. Почти на ту же тему — объединение веток завершения функции, но не с очисткой, а с сообщением об ошибке.
4. Выход из глубокой вложенности циклов или if'ов на выделенную ветку выполнения или сразу за конец внешнего из покинутых циклов.
5. Переход (обычно только вперёд) по длинной линейной последовательности действий, строить которую в виде ветвлений или автомата (while+switch) означает нарушить восприятие кода.
6. Как типичный вариант (5) — backtracking в некоторых исполнениях.

Но при наличии более продвинутых средств, чем голый Си, 1-3 можно перевалить на классы и RAII;
с четвёртым хуже — throw/catch здесь как из пушки по воробьям. В некоторых языках есть средства вроде "break 2" или "break название_цикла" (первое — например, sh, второе — Perl),
а там где их нет — увы, goto или throw.

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

Н> //А теперь проверим — было ли переполнение?

Н> __asm
Н> {
Н> jc CarryFlag
Н> }

Ну это уже совсем спецхак:))
The God is real, unless declared integer.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 31.07.07 22:21
Оценка:
Здравствуйте, netch80, Вы писали:

N>обосновывать и стараться применять пореже — их неудобно поддерживать. А если мы при этом обходим, например, инициализации переменных — такое писать нельзя ни в коем случае.

А и не позволят, если они конечно локальные. Деструкторы же по goto наружу кажется зовутся
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 31.07.07 22:30
Оценка:
Здравствуйте, Нэчер, Вы писали:

Н>
Н>  c=a+b;

Н>  //А теперь проверим - было ли переполнение?
Н>  __asm
Н>  {
Н>    jc CarryFlag 
Н>  }

Н>}
Н>

За это 5 баллов! А если кому не понравится пусть напишет проверку на переполнение в рамках стандарта
Re[7]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 22:48
Оценка: +1
Здравствуйте, unreg_flex, Вы писали:

_>
_>template< class ValueType >
_>void EstimateContour(
_>


1. Глазоломный код. Именно для того чтобы не ломать глаза — люди давно придумали нормальные стандарты форматирования кода.
2. Некоторые переменные стоит инициализировать при создании. Например — Inv1,Inv2 и c.
3. Интересные названия. Например та же самая — с... Над названиями функций стоит поработать. Я бы ещё прибил венгерскую нотацию, но это дело привычки.
4.
_> std::vector< TGL::Circle< ValueType > > Circles;
_> [skip]
_> if(rPolygon.IsPointIn(c.Center())&&
_> rCirclesCond.Check(c)) Circles.push_back(c);
Этот фрагмент показывает, что goto в данной функции — самая что ни есть низкоуровневая и бесполезная оптимизация (если она затеяна с целью оптимизации). Допустим от одного только резервирования Circles скорее всего толку было бы больше. Подозреваю, что покопавшись можно найти ещё много интересных мест и решений.

NBN>>Я??? Где я предлагаю N4??? Я вообще не знаю что это за алгоритм и с какого перепугу это критический участок кода. Это кодек какой-то?

_>Не совсем, но нечто подобное.
Ничего подобного.

NBN>>Это прикидка — какая доля людей дрова пишет (0.05%).

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

_>stl используем везде где это возможно, однако до сих пор ни у кого в коде даже не нашлось нормальное применение обычным спискам из стл.

Бывает такое дело

_>Исключения не используем вообще, и более того, открою страшный секрет

_>Мы два года назад отказались от проверок на ошибки выделения памяти
_>И с тех пор ни разу, ни одна из наших програм не упала по этой причине.
Может вы просто не засекли? Впрочем это сильно зависит от программы, если бы они были достаточно сложными — такие проблемы были-бы навернякая (либо срок разработки в 2 больше).

_>А насчет смартпоинтеров скажу:

_>А других применений для него так и не нашлось.
Пожизненная узкая специализация?

_>Однажды, очень давно, на старом месте работы (не скажу где) люди шарахались с ужасной гримасой от строчки вида: SomeType *p;

_>И пихали смартптры везде где только можно их запихнуть, но от этого количество багов почемуто не уменьшалось.
_>По сути все эти биндеры смартптры итераторы (которые на самом деле вовсе не итераторы) фишки из буста (я не имею ввиду алгоритмы)
_>и прочая хренотень есть большой набор костылей призванный хоть как-то внести в язык отсутствующую функциональность.
_>Лично мое мнение таково, если ее там нет, то нечего и рыпаться, а если она нужна, то надо выбирать язык по ее наличию.
Обычно бывает наоборот, подтверждалось неоднократно и множеством людей, а именно — переход на автоматическое управление памятью снижало количество ошибок в разы. Ошибаются все, даже супер гуру. Опять же автоматическое управление памятью — существенно ускоряет разработку и чистоту кода. Допустим позволяет отказаться от деструкторов.
Вы видимо исключение

NBN>>По твоему это типа так?

NBN>>
NBN>>for(int i=0;i<n1;++i){for(int j=0;j<n2;++j){if(c1)goto next1;for(int k=0;k<n3;++k){if(c2)goto next2;}}next2:;}next1:;
NBN>>

_>Не надо утрировать, ни я, ни кто-либо из нашей команды такого не писал.
Ты что то подобное привёл в качестве примера.

NBN>>Судя по отсуствию пробелов в for'ах действительно лаконично написано...

_>Пробелы в форах это так?: for ( int i = 0; i < n; ++i ) { }
_>Что я могу тут сказать, в нашем отделе работает 6 человек и многие пишут по разному:
_>Например так:
_>
_>

_>И никто никому не парит моск о том как надо расставлять пробелы, переносить строчки делать отступы
_>и заниматься прочей ерундой, все пишут так как привыкли.
_>И знаешь что удивительно? Никто никогда не жаловался на плохую читабельность
Маловероятно. Более того — не очень хорошо характеризует менеджмент.
Имхо самый лучший подход — либо чёткая спецификация всех нюансов кода (для больших контор) или правило: один проект — один стиль (для маленьких). По моим наблюдениям такой разброд в коде говорит о том, что когда человек его написавший уйдет — код выкинут.

NBN>>>>GOTO для выхода из вложенных циклов? По хорошему эти циклы должны разноситься на отдельные функции.

NBN>>Использую, правда два вложенных — это максимум на одну функцию и в дальнейшем это очень часто подвергается рефакторингу.
_>Параноидальное разнесение вложенных циклов на функции?
Нет, требование читабельности и поддерживаемости. См. Фаулера. Прикинь что будет, если другой человек, незнакомый с кодом — попытается в нём что то исправить.

_>PS Любые, даже самые хорошие советы содержат исключения. Тем же свойством обладают и советы в книгах.

Кто бы спорил Только это не тот случай.

_>Поэтому если пишут что делать нужно так и сяк, то это вовсе не значит что надо поступать именно так и именно сяк фанатично и всегда.

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

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

template< class ValueType >
class ContourEstimator
{
    typedef TGL::Point< ValueType, 2 >  TPoint;
    typedef TGL::Polygon< ValueType, 2 >TPolygon;
    typedef TGL::Circle< ValueType >    TCircle;
    typedef std::vector<TCircle>        TCircles;
public:

    ContourEstimator(
        const TPoint* points,
        int count_of_points,
        const TPolygon& polygon,
        const CirclesCondition& circlesCond,
        const PointsCondition& pointsCond
        )
        : points(points)
        , count_of_points(count_of_points)
        , polygon(polygon)
        , circlesCond(circlesCond)
        , pointsCond(pointsCond)
        , inv1(points[0])
        , inv2(points[0])
    {
        circles.reserve( count_of_points );
    }

    void EstimateContour()
    {
        for(int i = 0; i < count_of_points; ++i)
        {
            // отбрасываем точки вне оболочки
            if( !polygon.IsPointIn( points[i] ) )
                continue;
            if ( !EstimateContourDim2( i ) )
                break;
        }
        EstimateHull( circles, points, count_of_points );
    }

private:
    TCircles        circles;
    TPoint          inv1, inv2;
    const TPoint*   points;
    size_t          count_of_points;
    const TPolygon& polygon;

    const CirclesCondition& circlesCond;
    const PointsCondition&  pointsCond;


    bool EstimateContourDim2(int i)
    {
        for(int j = i + 1; j < count_of_points; ++j)
        {
            // первое условие двойственности
            if( !circlesCond.CheckFirst( points[i], points[j], pointsCond ) )
                return false;

            if( !EstimateContourDim3( i, j ) )
                return false;
        }
        return true;
    }

    bool EstimateContourDim3(int i, int j)
    {
        pointsCond.Invert( inv1, points[j] );

        for(int k = j + 1; k < count_of_points; ++k)
        {
            // второе условие двойственности
            if( !circlesCond.CheckSecond( points[j], points[k], pointsCond ) )
                return false;
            pointsCond.Invert( inv2, points[k] );

            TCircle circle;
            circle.Estimate( points[i], points[j], points[k] );
            circle.Refine( inv1, inv2 );
            // сохраняем если центр окружности принадлежит оболочке
            // и найденные параметры входят в заданный диапазон
            if( polygon.IsPointIn( circle.Center() ) && circlesCond.Check( circle ) )
                circles.push_back( c );
        }
        return true;
    }
};
Нужно разобрать угил.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 22:59
Оценка:
Здравствуйте, Пётр Седов, Вы писали:

ПС>2. goto вперёд. Это нормально, примеры (для C++):

ПС>* return в середине функции – досрочно завершить выполнение функции и передать управление на строчку за вызовом функции.
ПС>* break в цикле – досрочно завершить выполнение цикла и передать управление на строчку за циклом.
ПС>* continue – досрочно завершить выполнение итерации цикла и передать управление на следующую итерацию. А если следующей итерации нет, то передать управление на строчку за циклом.
ПС>* throw (и longjmp) – досрочно завершить выполнение кода (обычно из-за аварии) и передать управление обработчику исключения (блок catch).

А при чём тут goto?
Нужно разобрать угил.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 23:04
Оценка:
Здравствуйте, netch80, Вы писали:

N>1. Завершение работы функции с освобождением занятого и возвратом изменённого, для избежания дублирования кода по освобождению/очистке/возврату (потому что такое дублирование приводит к ошибкам в ~99% написаний).

Такие вещи необходимо вешать на автоматическое уничтожение. Неоднократно находил у людей ошибки связанные с таким подходом.

N>2. Близко к первому — постепенный откат изменений в том случае, если действий много, откатывать их надо в обратном порядке, а вложенность в случае структурного написания получится чрезмерной.

Автоматика

N>3. Почти на ту же тему — объединение веток завершения функции, но не с очисткой, а с сообщением об ошибке.

Вынос в функцию?

N>4. Выход из глубокой вложенности циклов или if'ов на выделенную ветку выполнения или сразу за конец внешнего из покинутых циклов.

Плохой стиль, тут нужно не готу, а рефакторинг.

N>5. Переход (обычно только вперёд) по длинной линейной последовательности действий, строить которую в виде ветвлений или автомата (while+switch) означает нарушить восприятие кода.

Разбивать на функции.

N>Но при наличии более продвинутых средств, чем голый Си, 1-3 можно перевалить на классы и RAII;

О, точно. Мне казалось что мы говорим про С++
Нужно разобрать угил.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 23:08
Оценка: -1
Здравствуйте, Programador, Вы писали:

N>>обосновывать и стараться применять пореже — их неудобно поддерживать. А если мы при этом обходим, например, инициализации переменных — такое писать нельзя ни в коем случае.

P>А и не позволят, если они конечно локальные. Деструкторы же по goto наружу кажется зовутся
Вроде бы микрософт специфик.
Нужно разобрать угил.
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 31.07.07 23:14
Оценка: -2
Здравствуйте, NikeByNike, Вы писали:
NBN>
NBN>template< class ValueType >
NBN>class ContourEstimator



NBN>};
NBN>

Этот код не эквивалентен исходному. Вы лихо перенесли автоматические объекты в приватную часть класса. А время жизни?

Если даже на это не смотреть, то область видимости расширилась на другие методы. И потом исходный код на экран помещался а этот 2 раза перелистывать нужно В общем ф топку
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 31.07.07 23:18
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


N>>>обосновывать и стараться применять пореже — их неудобно поддерживать. А если мы при этом обходим, например, инициализации переменных — такое писать нельзя ни в коем случае.

P>>А и не позволят, если они конечно локальные. Деструкторы же по goto наружу кажется зовутся
NBN>Вроде бы микрософт специфик.
А вооще вопрос занятный
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 31.07.07 23:47
Оценка:
Здравствуйте, Programador, Вы писали:

P>Этот код не эквивалентен исходному. Вы лихо перенесли автоматические объекты в приватную часть класса. А время жизни?


Я постарался его учесть. Если ты про TGL::Circle< ValueType > c; то я сделал допущение, что на функцию c.Estimate( points[i], points[j], points[k] ); не влияет предыдущее состояние объекта с.
Остальное вроде правильно, с поправкой на то, что состояние аргументов функции не изменится между вызовами конструктора и EstimateContour. Кстати, на таком подходе иногда удаётся ускорить функции в разы. Допустим, если есть проверка пересечения луча с большим количеством боксов — замена функции на функтор — даёт приличное ускорение.

P>Если даже на это не смотреть, то область видимости расширилась на другие методы. И потом исходный код на экран помещался а этот 2 раза перелистывать нужно В общем ф топку


Отдельные функции стали меньше. То что код был в виде кирпича — не означало его лучшей читабельности. Вот тебе другой пример
Даже чуть короче исходного, видимо — чуть читабельнее?

template< class ValueType >
struct ContourEstimator {
 typedef TGL::Point< ValueType, 2 >TPt;
 typedef TGL::Polygon< ValueType, 2 >TPn;
 ContourEstimator(const TPt* p,size_t cp,const TPn& pn,const CirclesCondition& cc,const PointsCondition& pc)
 : points(p), cpoint(cp), polygon(pn), circlesCond(cc), pointsCond(pc), inv1(p[0]), inv2(p[0]) {}
 void EstimateContour(){
  for(size_t i=0; i<cpoint; ++i){
   // отбрасываем точки вне оболочки
   if( !polygon.IsPointIn( points[i] ) )continue;
   if( !EstimateContourDim2( i ) )break;
  }
  EstimateHull( circles, points, cpoint );
 }
 std::vector<TGL::Circle< ValueType >> circles;
 TPt inv1, inv2;
 const TPt* points;
 size_t cpoint;
 const TPn& polygon;
 const CirclesCondition& circlesCond;
 const PointsCondition&  pointsCond;
 bool EstimateContourDim2(size_t i){
  for(size_t j=i+1; j<cpoint; ++j){
   // первое условие двойственности
   if(!circlesCond.CheckFirst(points[i],points[j],pointsCond)||!EstimateContourDim3(i,j))return false;
  }
  return true;
 }
 bool EstimateContourDim3(size_t i, size_t j){
  pointsCond.Invert( inv1, points[j] );
  for(size_t k=j + 1; k<cpoint; ++k){
   // второе условие двойственности
   if( !circlesCond.CheckSecond( points[j], points[k], pointsCond ) )return false;
   pointsCond.Invert( inv2, points[k] );
   TGL::Circle< ValueType > c;
   c.Estimate( points[i], points[j], points[k] );
   c.Refine( inv1, inv2 );
   // сохраняем если центр окружности принадлежит оболочке
   // и найденные параметры входят в заданный диапазон
   if( polygon.IsPointIn( c.Center() ) && circlesCond.Check( c ) )circles.push_back( c );
  }
  return true;
 }
};
Нужно разобрать угил.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: NikeByNike Россия  
Дата: 31.07.07 23:48
Оценка:
Здравствуйте, NikeByNike, Вы писали:

P>>Этот код не эквивалентен исходному. Вы лихо перенесли автоматические объекты в приватную часть класса. А время жизни?


NBN>Я постарался его учесть.


В смысле — время жизни учесть...
Нужно разобрать угил.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.08.07 05:59
Оценка: +1
Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Пётр Седов, Вы писали:


ПС>>2. goto вперёд. Это нормально, примеры (для C++):

ПС>>* return в середине функции – досрочно завершить выполнение функции и передать управление на строчку за вызовом функции.
ПС>>* break в цикле – досрочно завершить выполнение цикла и передать управление на строчку за циклом.
ПС>>* continue – досрочно завершить выполнение итерации цикла и передать управление на следующую итерацию. А если следующей итерации нет, то передать управление на строчку за циклом.
ПС>>* throw (и longjmp) – досрочно завершить выполнение кода (обычно из-за аварии) и передать управление обработчику исключения (блок catch).

NBN>А при чём тут goto?


При том, что всё это тоже формы goto, но ограниченные в направлении перехода, и потому допускаемые большинством разработчиков как "меньшее зло".
The God is real, unless declared integer.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.08.07 06:02
Оценка:
Здравствуйте, NikeByNike, Вы писали:

N>>3. Почти на ту же тему — объединение веток завершения функции, но не с очисткой, а с сообщением об ошибке.

NBN>Вынос в функцию?

Неудобно. Макрос ещё как-то годится, но не это.

N>>4. Выход из глубокой вложенности циклов или if'ов на выделенную ветку выполнения или сразу за конец внешнего из покинутых циклов.

NBN>Плохой стиль, тут нужно не готу, а рефакторинг.

Аргументы?

N>>5. Переход (обычно только вперёд) по длинной линейной последовательности действий, строить которую в виде ветвлений или автомата (while+switch) означает нарушить восприятие кода.

NBN>Разбивать на функции.

Крайне неудобно поддерживать результат (в тех случаях, когда видел подобное в применении).
The God is real, unless declared integer.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.08.07 06:50
Оценка: +3
Здравствуйте, Programador, Вы писали:

P>Здравствуйте, Нэчер, Вы писали:


Н>>
Н>>  c=a+b;

Н>>  //А теперь проверим - было ли переполнение?
Н>>  __asm
Н>>  {
Н>>    jc CarryFlag 
Н>>  }

Н>>}
Н>>

P>За это 5 баллов! А если кому не понравится пусть напишет проверку на переполнение в рамках стандарта

jIMHO — не 5, а максимум 3, и то сомнительно. Потому что 1) код всё равно платформенно-зависим, 2) нет достаточных причин предполагать, что сложение будет вообще выполнено именно таким методом, как нужен для последующего применения jc, 3) нет гарантии, что это сложение вообще не будет убрано или переоптимизировано. Например, имея код вида

d = a + b + c;
leftfunc(d);
c = a + b;
__asm { jc... }


второе присваивание будет выброшено, как повторяющее часть первого, а в CF останется то, что туда попало от leftfunc(). MS явно пишет в документации: "In general, you should not assume that a register will have a given value when an __asm block begins. Register values are not guaranteed to be preserved across separate __asm blocks." Flags — это тоже регистр.

Так что автор того кода ходит по верёвке над пропастью, причём в шторм. Частично это объясняется (не оправдывается) тупизной встроенного ассемблера MS, который, в отличие от gcc или Watcom, не даёт внятно объяснить "сюда загрузить a, сюда b, регистры модифицированы eax и Flags". Но даже в этом случае лучше было бы записать примерно так:

__asm {
  mov eax,[a]
  add eax,[b]
  jc CarryFlag
}


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

Если бы такая задача (складывать с проверкой на переполнение) стояла у меня, я бы
1) взял (если есть возможность) компилятор пограмотнее (типа gcc)
2) сделал бы inline-функцию, в которой ассемблером бы нарисовал код, соответствующий предыдущему (хотя, может быть, не jc, а что-то типа mov eax,0; rol eax,1 — чтобы выбрать CF в регистр без ветвления, которое замедляет процессор), и расставил бы ей адекватные constraint'ы (что куда загрузить, что модифицируется), получив бы примерно следующее:

inline
bool // 0 - нет переполнения, 1 - переполнение
unsigned_check_add(unsigned a, unsigned b)
{
  unsigned r;
  asm(
    "mov eax,%1\n"
    "add eax,%2\n"
    "mov eax,0\n"
    "rol eax,1"
    : "=a"(r) // результат брать из eax
    : "m"(a), "m"(b) // входные данные могут быть в памяти или в стеке, не важно
    : "cc" // побочный эффект - модификация Flags
  );
  return r;
}


Вот если у кого-то только MSVC — ну что ж, придётся извращаться потяжелее:(
The God is real, unless declared integer.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: ionicman  
Дата: 01.08.07 07:33
Оценка: 9 (1) +1
Хорошая тема для обсуждения — это типа HolyWars-а почти
Я вот не понимал никогда, какого черта люди так говорят типа goto — плохой код и все такое.
По очень простой пречине — язык — это инструмент. Вам его дали, Вы им пользуетесь.
Если Вы находите удобным воспользоваться goto — пользуйтесь, если Вам удобно сделать функцию, либо же break — делайте.

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

Примеров полно — я не раз всречал умопомрачительные конструкции для перепрыгивания в циклах — когда есть несколько вложенных циклов и надо скажем из внутреннего 3-го прыгнуть в 1. Там и смарты использовались, и функции хиьтрые которые внутри себя эти циклы по частям крутили — а смысл? Использовать указатель за место goto — это же конечно более "гладкий" код :D

Апогеем маразма я видел когда переход осуществлялся программирование указателя и вызовом его как фии — мужик точно на асме раньше писал... полиморфы...

Вобщем, никого же не возмущает наличие в инструментах молотка? Ни кто ж не говорит что молоток — это не гуманно, лучше использовать отвертку ) Вам дали инструменты — пользуйтесь так как считаете нужным. А то началось — плохооо, когд не читаемый. Вот с Венгенрской нотацией код более читаемый — а че ее так мло используют? :D

ИМХО — goto очень удобный инструмент при переходе внутри вложенных циклов. Ибо стандартно в C нет continue метка или break метка. А использовать флажки, как предлагалось выше — это кончено верх изящества ))))
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 01.08.07 07:53
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>1. Глазоломный код. Именно для того чтобы не ломать глаза — люди давно придумали нормальные стандарты форматирования кода.

Повторюсь, "нормальные стандарты форматирования кода" у всех свои.

NBN>2. Некоторые переменные стоит инициализировать при создании. Например — Inv1,Inv2 и c.

NBN>3. Интересные названия. Например та же самая — с... Над названиями функций стоит поработать. Я бы ещё прибил венгерскую нотацию, но NBN>это дело привычки.
Ага, ведь люди давно придумали нормальные стандарты именования переменных .
"Например та же самая — с", интересно, вы переменную в цикле называете i, n, или nVeryGoodCycleCounter?

NBN>Этот фрагмент показывает, что goto в данной функции — самая что ни есть низкоуровневая и бесполезная оптимизация (если она затеяна с целью NBN>оптимизации).

Кто вам сказал что гото тут для оптимизации?

NBN>Допустим от одного только резервирования Circles скорее всего толку было бы больше.

От резервирования Circles толку небудет, поскольку их общее количество редко бывает >8.

NBN>Подозреваю, что покопавшись можно найти ещё много интересных мест и решений.

Подозреваю что нет, ничего интересного вы пока не нашли.

_>>Не совсем, но нечто подобное.

NBN>Ничего подобного.
oO, вы в курсе чем я занимаюсь?

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

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

NBN>Пожизненная узкая специализация?

Угу, неговорите

NBN>Обычно бывает наоборот, подтверждалось неоднократно и множеством людей, а именно — переход на автоматическое управление памятью NBN>снижало количество ошибок в разы. Ошибаются все, даже супер гуру. Опять же автоматическое управление памятью — существенно ускоряет NBN>разработку и чистоту кода. Допустим позволяет отказаться от деструкторов.

Полностью со всем согласен, но только не "автоматическое" управление памятью на C++
NBN>Вы видимо исключение
Я так не думаю.

NBN>>>По твоему это типа так?

NBN>>>
NBN>>>for(int i=0;i<n1;++i){for(int j=0;j<n2;++j){if(c1)goto next1;for(int k=0;k<n3;++k){if(c2)goto next2;}}next2:;}next1:;
NBN>>>

_>>Не надо утрировать, ни я, ни кто-либо из нашей команды такого не писал.
NBN>Ты что то подобное привёл в качестве примера.
Да вы мастер цитирования


NBN>>>Судя по отсуствию пробелов в for'ах действительно лаконично написано...

NBN>Маловероятно. Более того — не очень хорошо характеризует менеджмент.
NBN>Имхо самый лучший подход — либо чёткая спецификация всех нюансов кода (для больших контор) или правило: один проект — один стиль (для NBN>маленьких). По моим наблюдениям такой разброд в коде говорит о том, что когда человек его написавший уйдет — код выкинут.
Выкинут код или не выкинут зависит не от того как его автор расставлял пробельчики и скобочки.
А по моим наблюдениям для вас это первый критерий качества кода.

NBN>Фанатично не надо, но надо всегда следовать определённым правилам, особенно работая в коллективе. По крайней мере исключения должны NBN>чётко обосновываться. goto в данном случае — не является оптимизирующим явлением.

Нет слов, где я писал что "гото здесь является оптимизирующим явлением"?

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


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

NBN>
NBN>template< class ValueType >
NBN>class ContourEstimator
NBN>{
NBN>    typedef TGL::Point< ValueType, 2 >  TPoint;
NBN>    typedef TGL::Polygon< ValueType, 2 >TPolygon;
NBN>    typedef TGL::Circle< ValueType >    TCircle;
NBN>    typedef std::vector<TCircle>        TCircles;
NBN>public:

// а это зачем? Чтобы запутать получше?  тому кто читает привычней видеть стандартные записи std::vector< TGL::Circle< ValueType > >

NBN>    ContourEstimator(
NBN>        const TPoint* points,
NBN>        int count_of_points,
NBN>        const TPolygon& polygon,
NBN>        const CirclesCondition& circlesCond,
NBN>        const PointsCondition& pointsCond
NBN>        )
NBN>        : points(points)
NBN>        , count_of_points(count_of_points)
NBN>        , polygon(polygon)
NBN>        , circlesCond(circlesCond)
NBN>        , pointsCond(pointsCond)
NBN>        , inv1(points[0])
NBN>        , inv2(points[0])
NBN>    {
NBN>        circles.reserve( count_of_points );
NBN>    }

// точек может быть миллионы, а окружностей 5-8.

NBN>    void EstimateContour()
NBN>    {
NBN>        for(int i = 0; i < count_of_points; ++i)
NBN>        {
NBN>            // отбрасываем точки вне оболочки
NBN>            if( !polygon.IsPointIn( points[i] ) )
NBN>                continue;
NBN>            if ( !EstimateContourDim2( i ) )
NBN>                break;
NBN>        }
NBN>        EstimateHull( circles, points, count_of_points );
NBN>    }

NBN>private:
NBN>    TCircles        circles;
NBN>    TPoint          inv1, inv2;
NBN>    const TPoint*   points;
NBN>    size_t          count_of_points;
NBN>    const TPolygon& polygon;

NBN>    const CirclesCondition& circlesCond;
NBN>    const PointsCondition&  pointsCond;


NBN>    bool EstimateContourDim2(int i)
NBN>    {
NBN>        for(int j = i + 1; j < count_of_points; ++j)
NBN>        {
NBN>            // первое условие двойственности
NBN>            if( !circlesCond.CheckFirst( points[i], points[j], pointsCond ) )
NBN>                return false;

NBN>            if( !EstimateContourDim3( i, j ) )
NBN>                return false;
NBN>        }
NBN>        return true;
NBN>    }

NBN>    bool EstimateContourDim3(int i, int j)
NBN>    {
NBN>        pointsCond.Invert( inv1, points[j] );

NBN>        for(int k = j + 1; k < count_of_points; ++k)
NBN>        {
NBN>            // второе условие двойственности
NBN>            if( !circlesCond.CheckSecond( points[j], points[k], pointsCond ) )
NBN>                return false;
NBN>            pointsCond.Invert( inv2, points[k] );

NBN>            TCircle circle;
NBN>            circle.Estimate( points[i], points[j], points[k] );
NBN>            circle.Refine( inv1, inv2 );
NBN>            // сохраняем если центр окружности принадлежит оболочке
NBN>            // и найденные параметры входят в заданный диапазон
NBN>            if( polygon.IsPointIn( circle.Center() ) && circlesCond.Check( circle ) )
NBN>                circles.push_back( c );
NBN>        }
NBN>        return true;
NBN>    }
NBN>};
NBN>


И чем теперь код стал лучше?
Тем что увеличился в 2 раза?
Увеличилась читабельность? o_O (ах да, пробельчики добавились, только не везде почему-то)
А может тем что напихали в класс кучу ненужных переменных имеющих смысл только в момент вызова этого метода?
Или новыми ненужными копированиями, кстати не малого объема данных?
А после отработки этого метода, скопированные данные останутся висеть в памяти?
Особенно весело копирование указателя
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: AndrewJD США  
Дата: 01.08.07 08:33
Оценка: :))
Здравствуйте, Нэчер, Вы писали:


Н>2) Есть один замечательный трюк с метками (помню, что точно работало в VC6.0):

Н>
Н>bool add(int a,int b,int& c)
Н>{
Н>  c=a+b;

Н>  //А теперь проверим - было ли переполнение?
Н>  __asm
Н>  {
Н>    jc CarryFlag 
Н>  }

Н>  //no carry
Н>  return 0;

Н>  CarryFlag:;

Н>  //carry
Н>  return 1;
Н>}
Н>


Н>Если подойти к вопросу трезво, то можно о-го-го сколько наоптимизировать в разного рода вычислительных алгоритмах =)


А не боишься, что потом коллега, который будет это сопровождать, подкараулит тебя где-нибудь в темном месте с тяжелым предметом?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.08.07 09:21
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Я благодарен Страуструпу что он не пошел на поводу вот у таких "правильных" молодцев, которые считают, что "так правильней". Все зависит от конкретной задачи — для каждой из них — свой инструмет. Можно ведь и гаечным ключом гвоздь то забить.


Страуструп сильно непоследователен. goto он разрешил, у которого есть значительные проблемы в реализации (например, та же тема с конструкторами объектов, когда переход происходит в середину блока, или чуть попроще — при выходе по goto из блока) — тут уже проблемы с этим обсуждали. А вот значительно менее проблемное try-finally он принципиально не разрешает, потому что, видите ли, есть RAII и всё что надо делать — можно сделать на нём.

Я бы согласился с его позицией, если бы он, аналогично современному managed/unmanaged коду, сделал метки "этот код написан в таком вот стиле, goto разрешить, сложные объекты и исключения запретить" (условно говоря). Но ведь он этого не сделал.

I>ИМХО — goto очень удобный инструмент при переходе внутри вложенных циклов. Ибо стандартно в C нет continue метка или break метка. А использовать флажки, как предлагалось выше — это кончено верх изящества ))))


Флажки нужны там, где код надо строго доказать.
Но я лично очень "за" помеченные циклы, аналогично перлу. Проблем от этого минимум, польза — огромная.
The God is real, unless declared integer.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Programador  
Дата: 01.08.07 09:40
Оценка:
Здравствуйте, ionicman, Вы писали:

I> А то началось — плохооо, когд не читаемый. Вот с Венгенрской нотацией код более читаемый — а че ее так мло используют? :D

Гдето я про это слышал. Тут ответ простой число скобок посчитать легче чем число пушей попов, хот и здесь после третьего уровня не совсем комфортно
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 01.08.07 09:43
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Хорошая тема для обсуждения — это типа HolyWars-а почти

I>Я вот не понимал никогда, какого черта люди так говорят типа goto — плохой код и все такое.

Не, ты не понял Тут говорится что не готу плохой код, а готу — признак плохого кода. Это разные вещи.
Посмоти сколько готу встречается в stl или бусте
Нужно разобрать угил.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: ionicman  
Дата: 01.08.07 09:45
Оценка: 1 (1)
N>Страуструп сильно непоследователен. goto он разрешил, у которого есть значительные проблемы в реализации (например, та же тема с конструкторами объектов, когда переход происходит в середину блока, или чуть попроще — при выходе по goto из блока) — тут уже проблемы с этим обсуждали. А вот значительно менее проблемное try-finally он принципиально не разрешает, потому что, видите ли, есть RAII и всё что надо делать — можно сделать на нём.
Ну во первых то что он был "непоследователен" :D И сделало язык C++ таким богатым
Во вторых действительно RAII вполне это решает, а вот использование таких хитрые решения с конструкторами объектов и goto — это отдельная тема, считаю что это действительно не шибко хорошее использвание для данного оператора.

N>Я бы согласился с его позицией, если бы он, аналогично современному managed/unmanaged коду, сделал метки "этот код написан в таком вот стиле, goto разрешить, сложные объекты и исключения запретить" (условно говоря). Но ведь он этого не сделал.

А зачем? есть goto нфрфду с исключениями — используй то что считаешь нужным. Стили и разрешения и запрещения на них — это придумали люди, использующие C++ ) Как он мог сказать за всех? У него есть рекомендации по написанию, есть еще тысячи вариантов как это делать. Выбери свое и придерживайся этого. Я за это его и уважаю что он не седлал так "Это неправильно — делайте так". За это мне и нравится C++ — свобода — ты сам Бог и Творец, и никто тебя не тыкает. Выберешь неудачную концепцию — виноват сам )

I>>ИМХО — goto очень удобный инструмент при переходе внутри вложенных циклов. Ибо стандартно в C нет continue метка или break метка. А использовать флажки, как предлагалось выше — это кончено верх изящества ))))


N>Флажки нужны там, где код надо строго доказать.

Они кроме того что замедляют исполнение абсолютно не нужныю Кроме того читать код с кучей симафоров гораздо хуже чем м темже goto. пример — для бэк трэкинга в 3 вложенных циклах при условии трекинга в пределах самого высокого требуется 2 флага — как Вам такое?
N>Но я лично очень "за" помеченные циклы, аналогично перлу. Проблем от этого минимум, польза — огромная.
Не, ну вариантов много. Я уже приводил пример выше про continue / break + label. Ну на самом деле goto не только в циклах удобен. Этим полностью решить все неудастся.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: Programador  
Дата: 01.08.07 09:52
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Остальное вроде правильно, с поправкой на то, что состояние аргументов функции не изменится между вызовами конструктора и EstimateContour. Кстати, на таком подходе иногда удаётся ускорить функции в разы. Допустим, если есть проверка пересечения луча с большим количеством боксов — замена функции на функтор — даёт приличное ускорение.


Замена функции на функтор, тоесть сокрытие объекта, который модифицируется между вызовами? В принципе локальные классы уже появились. Если в функциях разрешить третий тип памяти, в дополнение к статической и авто, то можно унифицировать функции с классами. Ну и както еще поднапрячься и namespace туда
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: ionicman  
Дата: 01.08.07 10:00
Оценка:
NBN>Не, ты не понял Тут говорится что не готу плохой код, а готу — признак плохого кода. Это разные вещи.
NBN>Посмоти сколько готу встречается в stl или бусте

Ну вопервых кто те сказал что это истина в последних инситанциях? :D Достаточно удобные библиотеки предлагающие в обмен тормоза за удобство. Их пишут люди. А люди, как я уже писал, обычно придерживаются некоего стиля — вот и все. На самом деле goto достаточно редкий гость в программах, НО внекоторых ситуциях он гораздо более удобен как по скрости так и по прозрачности листинга. И он не является признаком "плохого" кода абсолютно. Вы же не называете признаком плохого кода функции или классы? А на них огого нагородить можно. Вы никогда не встречали исходники, создатели которых были больны ООП насмерть? Там в каждом месте по классику, пусть маленькому — но классику. Это ужас просто. Не читаемо и медленно вообще.
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 01.08.07 10:06
Оценка:
Здравствуйте, unreg_flex, Вы писали:

NBN>>1. Глазоломный код. Именно для того чтобы не ломать глаза — люди давно придумали нормальные стандарты форматирования кода.

_>Повторюсь, "нормальные стандарты форматирования кода" у всех свои.
Расскажи это яваистам

_>"Например та же самая — с", интересно, вы переменную в цикле называете i, n, или nVeryGoodCycleCounter?

Обати внимание на то что конкретно к этим переменным я не пристал

NBN>разработку и чистоту кода. Допустим позволяет отказаться от деструкторов.

_>Полностью со всем согласен, но только не "автоматическое" управление памятью на C++
Не понял

_>Выкинут код или не выкинут зависит не от того как его автор расставлял пробельчики и скобочки.

_>А по моим наблюдениям для вас это первый критерий качества кода.
Это первый критерий поскольку это первое что бросается в глаза. Во-вторую очередь форматирование, в-третью именования, грамотные комментарии. Паралельно идёт безопасность кода, переносимость кода, признаки отсуствия необходимости рефакторить код.
Скорость кода — анализируется после этих критериев, восновном по выбранному алгоритму. И т.д.

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

В том то и дело, что если это критическое место — имеет смысл сделать предобработку.

NBN>> typedef TGL::Point< ValueType, 2 > TPoint;

NBN>> typedef TGL::Polygon< ValueType, 2 >TPolygon;
NBN>> typedef TGL::Circle< ValueType > TCircle;
NBN>> typedef std::vector<TCircle> TCircles;

_>// а это зачем? Чтобы запутать получше? тому кто читает привычней видеть стандартные записи std::vector< TGL::Circle< ValueType > >

Как правило так удобнее работать. Кроме того есть такая штука — ассистент. На счёт вектора — это вобщем на вкус, а TGL::Circle< ValueType > я бы всётаки определил, для читабельности.

NBN>> {

NBN>> circles.reserve( count_of_points );
NBN>> }

_>// точек может быть миллионы, а окружностей 5-8.

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

NBN>>
NBN>>    void EstimateContour()
NBN>>};
NBN>>


_>И чем теперь код стал лучше?

_>Тем что увеличился в 2 раза?
Ну я кажется показал пример как сделать его меньше твоей функции Код стал как минимум читабельнее, без изменения функциональности и быстродействия.

_>А может тем что напихали в класс кучу ненужных переменных имеющих смысл только в момент вызова этого метода?

Это не самостоятельный ООП класс, скорее функтор. Этот класс может находиться в cpp файле. Чем хорош такой подход — я объяснял. Если какие-то исходные данные функции не меняются в течении нескольких вызовов — становится просто сделать кеширование. Опять же, если в дальнейшем потребуется модификация алгоритма, особенно посторонним человеком — это будет сделать проще.
_>Или новыми ненужными копированиями, кстати не малого объема данных?
Какого копирования?

_>А после отработки этого метода, скопированные данные останутся висеть в памяти?

Это описывается в комментариях или при необходимости заворачивается в функцию с оригинальным интерфейсом.
Нужно разобрать угил.
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: hell citizen Россия  
Дата: 01.08.07 11:52
Оценка:
Здравствуйте, unreg_flex, Вы писали:

_>Это критический участок кода, сложность N^3, предлагаете сделать за N^4?

_>Тут обычный перебор всех троек точек заданного множества с перестановками (алгоритм RANSAC для подбора кривой).
_>Ума не приложу, как это можно сделать по другому.

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

input:
    data - a set of observed data points
    model - a model that can be fitted to data points
    n - the minimum number of data values required to fit the model
    k - the maximum number of iterations allowed in the algorithm
    t - a threshold value for determining when a data point fits a model
    d - the number of close data values required to assert that a model fits well to data
output:
    bestfit - model parameters which best fit the data (or nil if no good model is found)

iterations := 0
bestfit := nil
besterr := infinity
while iterations < k 
    maybeinliers := n randomly selected values from data
    maybemodel := model parameters fitted to maybeinliers
    alsoinliers := empty set

    for every point in data not in maybeinliers 
        if point fits maybemodel with an error smaller than t
             add point to alsoinliers
    
        if the number of elements in alsoinliers is > d 
        (this implies that we may have found a good model now test
        how good it is)
        bettermodel := model parameters fitted to all points in maybeinliers and alsoinliers
        thiserr := a measure of how well model fits these points
        if thiserr < besterr 
            bestfit := bettermodel
            besterr := thiserr
     
    increment iterations

return bestfit
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 01.08.07 12:04
Оценка:
Здравствуйте, hell citizen, Вы писали:

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


_>>Это критический участок кода, сложность N^3, предлагаете сделать за N^4?

_>>Тут обычный перебор всех троек точек заданного множества с перестановками (алгоритм RANSAC для подбора кривой).
_>>Ума не приложу, как это можно сделать по другому.

HC>Я возможно чего-то не понимаю, но в вики этот алгоритм приведён в псевдокоде в несколько другом виде и без гото вполне обошлось:


Насколько я понял в вики — 2Д вариант, а здесь — 3Д
Нужно разобрать угил.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 01.08.07 12:26
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>>>1. Глазоломный код. Именно для того чтобы не ломать глаза — люди давно придумали нормальные стандарты форматирования кода.

_>>Повторюсь, "нормальные стандарты форматирования кода" у всех свои.
NBN>Расскажи это яваистам
Мне плевать, как и что форматируют яваисты. Я на сях пишу.

_>>"Например та же самая — с", интересно, вы переменную в цикле называете i, n, или nVeryGoodCycleCounter?

NBN>Обати внимание на то что конкретно к этим переменным я не пристал
Вы пристали к c но тем не менее не пристали к i,j,k. Вот мне и интересно стало, чам же c так плоха и как ее надо было назвать?

_>>Выкинут код или не выкинут зависит не от того как его автор расставлял пробельчики и скобочки.

_>>А по моим наблюдениям для вас это первый критерий качества кода.
NBN>Это первый критерий поскольку это первое что бросается в глаза. Во-вторую очередь форматирование, в-третью именования, грамотные комментарии. Паралельно идёт безопасность NBN>кода, переносимость кода, признаки отсуствия необходимости рефакторить код.
А я то думаю, как сделать нашу работу идеальной? Оказывается надо просто скачать форматтер кода.
EstimateContourDim2 — очень грамотное имя.
В случае с эллипсами было бы так:
EstimateContourDim2(int i)
EstimateContourDim3(int i,int j)
EstimateContourDim4(int i,int j,int k)
EstimateContourDim5(int i,int j,int k,int p)
Явно отсутствуют признаки необходимости рефакторинга

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

NBN>В том то и дело, что если это критическое место — имеет смысл сделать предобработку.
Если бы любое уменьшение сложности можно было сделать предобработкой, то все алгоритмы бы реализовывались за линейное время
Вопрос только в одном, сколько времени займет предобработка

_>>// точек может быть миллионы, а окружностей 5-8.

NBN>Ну я же не знаю алгоритм, цифру от балды задал. Значит забить константу — допустим 8 или 16 и всё.
Забить ничего не выйдет, теоретически может быть сколько угодно, просто вероятность плохого случая очень мала.

_>>И чем теперь код стал лучше?

_>>Тем что увеличился в 2 раза?
NBN>Ну я кажется показал пример как сделать его меньше твоей функции Код стал как минимум читабельнее, без изменения функциональности и быстродействия.
Меньше???
Два экрана несомненно лучше читаются чем половина одного

_>>А может тем что напихали в класс кучу ненужных переменных имеющих смысл только в момент вызова этого метода?

NBN>Это не самостоятельный ООП класс, скорее функтор. Этот класс может находиться в cpp файле. Чем хорош такой подход — я объяснял. Если какие-то исходные данные функции не NBN>меняются в течении нескольких вызовов — становится просто сделать кеширование. Опять же, если в дальнейшем потребуется модификация алгоритма, особенно посторонним человеком NBN>- это будет сделать проще.
За счет чего проще? За счет необходимости изменения 3-х методов и 2-х классов, вместо одного метода?
Какое млин кэширование? Зачем оно тут надо?
А если данные меняются но не все? или все? Как кстати их изменить?

_>>Или новыми ненужными копированиями, кстати не малого объема данных?

NBN>Какого копирования?
ммм... Предлагаете оставить копирование указателя points?

_>>А после отработки этого метода, скопированные данные останутся висеть в памяти?

NBN>Это описывается в комментариях или при необходимости заворачивается в функцию с оригинальным интерфейсом.
В какую функцию? FreeSomeData(/* оригинальный интерфейс */)?
А комментарии наверно будут примерно такими:
/// При создании объекта ContourEstimator существует только одна возможность
/// передать исходные данные в конструкторе, если данные потребуется изменить необходимо удалить исходный объект и создать заново
/// Указатель на массив точек также передается в конструкторе и будет сохранен в объекте в течении его жизни.
/// Поэтому ни в коем случае нельзя удалять или изменять данные после создания объекта.
ппц, это и есть безопасный понятный код?

PS. Была одна маленькая простая функция...
Re[7]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 01.08.07 12:40
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, hell citizen, Вы писали:


HC>>Я возможно чего-то не понимаю, но в вики этот алгоритм приведён в псевдокоде в несколько другом виде и без гото вполне обошлось:


NBN>Насколько я понял в вики — 2Д вариант, а здесь — 3Д


Здесь 2Д вариант, а вообще RANSAC никак не зависит от размерности, понятия размерности там вообще нет.
В вики приведен вариант когда подбор происходит случайно (не учитывая всевозможные сочетания, хотя могут попасть и все).
В моем случае перебираются все сочетания, количество вложенных циклов будет зависеть не от размерности исходных точек,
а от минимального количества точек по которым можно однозначно построить кривую.
Например для окружности 3, для эллипса 5.
Прыжки между циклами вызваны необходимостью отсечения при переборе определенных сочетаний точек которые не должны попасть в подбор,
в оригинальном алгоритме естественно этого нет.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 01.08.07 13:00
Оценка:
Здравствуйте, ionicman, Вы писали:

I>У него есть рекомендации по написанию, есть еще тысячи вариантов как это делать. Выбери свое и придерживайся этого.

I>Я за это его и уважаю что он не седлал так "Это неправильно — делайте так". За это мне и нравится C++ — свобода — ты сам Бог и Творец, и никто тебя не тыкает. Выберешь неудачную концепцию — виноват сам )

+1
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: NikeByNike Россия  
Дата: 01.08.07 13:04
Оценка:
Здравствуйте, unreg_flex, Вы писали:

NBN>>>>1. Глазоломный код. Именно для того чтобы не ломать глаза — люди давно придумали нормальные стандарты форматирования кода.

_>>>Повторюсь, "нормальные стандарты форматирования кода" у всех свои.
NBN>>Расскажи это яваистам
_>Мне плевать, как и что форматируют яваисты. Я на сях пишу.
А я на с++. Я просто контуженный раньше занимался разработкой мидлеваре для огромной компании, за такой код который ты показал — меня бы растреляли.

_>>>"Например та же самая — с", интересно, вы переменную в цикле называете i, n, или nVeryGoodCycleCounter?

NBN>>Обати внимание на то что конкретно к этим переменным я не пристал
_>Вы пристали к c но тем не менее не пристали к i,j,k. Вот мне и интересно стало, чам же c так плоха и как ее надо было назвать?
Обычно в правилах для подобных переменных специально пишется исключение У меня была идея переименовать их в x, y, z. Но я решил что эти названия не подходят.

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

_>А я то думаю, как сделать нашу работу идеальной? Оказывается надо просто скачать форматтер кода.
_>EstimateContourDim2 — очень грамотное имя.
Поскольку я не представляю, что это за алгоритм — я не пытался подобрать грамотных названий.

_>Вопрос только в одном, сколько времени займет предобработка



NBN>>Ну я же не знаю алгоритм, цифру от балды задал. Значит забить константу — допустим 8 или 16 и всё.

_>Забить ничего не выйдет, теоретически может быть сколько угодно, просто вероятность плохого случая очень мала.
Я не знаю, сколько раз выполняется эта функция. Резервировать всёравно бы стал, условно говоря на 1.5 среднеожидаемого количества вставок.

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

_>Меньше???
_>Два экрана несомненно лучше читаются чем половина одного
Два экрана кода, разбитого на несколько функций, с приличным форматированием, читаются конечно гораздо легче, чем кирпич кода.
Вот тот пример
Автор: NikeByNike
Дата: 01.08.07
, более короткий чем твой Читабельнее?

NBN>>Это не самостоятельный ООП класс, скорее функтор. Этот класс может находиться в cpp файле. Чем хорош такой подход — я объяснял. Если какие-то исходные данные функции не NBN>меняются в течении нескольких вызовов — становится просто сделать кеширование. Опять же, если в дальнейшем потребуется модификация алгоритма, особенно посторонним человеком NBN>- это будет сделать проще.

_>За счет чего проще? За счет необходимости изменения 3-х методов и 2-х классов, вместо одного метода?
Скорее одного одного маленького метода, чем большой сильносвязанной функции.

_>Какое млин кэширование? Зачем оно тут надо?

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

_>А если данные меняются но не все? или все? Как кстати их изменить?

Я просто стиль показывал, не меняя функциональности. Естественно если предполагается расширение — можно изменить типы на более подходящие.

NBN>>Какого копирования?

_>ммм... Предлагаете оставить копирование указателя points?
А в чём проблема?
Тот же самый std::string::c_str. Даёт тебе указатель на буфер. В документации написано, что он валиден до первого вызова неконстантного мембера. Тут то же самое. Опять же, можно завернуть этот класс в функцию и всё будет типтоп.

_>PS. Была одна маленькая простая функция...

В том то и дело что функция — не маленькая и не простая.

P.S.
От готу далеко ушли
Нужно разобрать угил.
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: игппук Беларусь  
Дата: 01.08.07 13:31
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Вопрос не в том, что препод лох. Он мне аргументированно объяснил. Препод математик, и очень хорошо разбирается в структурном программировании. Бывает объективная необходимость во включении GOTO, для увеличения быстродействия. Мне бы хотелось услышать ответы от тех, кто считает, что GOTO имеет право на жизнь с конкретными примерами. Остальные не обижайтесь, но не надо писать сюда.


здесь пример кода с xml парсером, где GOTO оператор имеет право на жизнь (см. функцию ExtractXMLFragmentFromStream). если в двух словах, то в цикле while крутится логика, которая анализирует текущее состояние парсера, и при помощи GOTO значительно увеличивается скорость парсинга.
проклятый антисутенерский закон
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: hell citizen Россия  
Дата: 01.08.07 13:35
Оценка:
Здравствуйте, unreg_flex, Вы писали:

_>Здесь 2Д вариант, а вообще RANSAC никак не зависит от размерности, понятия размерности там вообще нет.

_>В вики приведен вариант когда подбор происходит случайно (не учитывая всевозможные сочетания, хотя могут попасть и все).
_>В моем случае перебираются все сочетания, количество вложенных циклов будет зависеть не от размерности исходных точек,
_>а от минимального количества точек по которым можно однозначно построить кривую.
_>Например для окружности 3, для эллипса 5.
_>Прыжки между циклами вызваны необходимостью отсечения при переборе определенных сочетаний точек которые не должны попасть в подбор,
_>в оригинальном алгоритме естественно этого нет.

Вот теперь я кажется понял в чем дело. В одной функции перемешались два алгоритма — подбор троек и этот самый ransac. Если сначала составить список троек и отсечь ненужные сочетания, а затем проверять тройки на похожесть кривойЮ, то должно получится близко к тому, что в вики, и без готу.
Re[12]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 01.08.07 13:35
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>А я на с++. Я просто контуженный раньше занимался разработкой мидлеваре для огромной компании, за такой код который ты показал — меня бы растреляли.

Я тоже был в подобной компании, ушел оттуда и ни капли не жалею.

_>>Вы пристали к c но тем не менее не пристали к i,j,k. Вот мне и интересно стало, чам же c так плоха и как ее надо было назвать?

NBN>Обычно в правилах для подобных переменных специально пишется исключение У меня была идея переименовать их в x, y, z. Но я решил что эти названия не подходят.
По смыслу они действительно неподходят, но если бы и было x, y, z или i1,i2,i3 то хуже от этого никому бы не стало.

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

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

NBN>Вот тот пример
Автор: NikeByNike
Дата: 01.08.07
, более короткий чем твой Читабельнее?

А почему на этот раз пробелы отступы и переносы оставили?

NBN>>>Какого копирования?

_>>ммм... Предлагаете оставить копирование указателя points?
NBN>А в чём проблема?
NBN>Тот же самый std::string::c_str. Даёт тебе указатель на буфер. В документации написано, что он валиден до первого вызова неконстантного мембера. Тут то же самое. Опять же, можно завернуть этот класс в функцию и всё будет типтоп.
Это далеко не тоже самое, std::string::c_str дает указатель на свой собственный буфер,
а тут копируют чужой указатель в переменную объекта во время его сборки,
юзер босле сборки объекта может удалить указатель (в конце концов это его собственный указатель),
а невалидный указатель останется торчать в классе.

NBN>P.S.

NBN>От готу далеко ушли
Скоро до палитеки дойдем
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 01.08.07 13:43
Оценка:
Здравствуйте, hell citizen, Вы писали:

HC>Вот теперь я кажется понял в чем дело. В одной функции перемешались два алгоритма — подбор троек и этот самый ransac. Если сначала составить список троек и отсечь ненужные сочетания, а затем проверять тройки на похожесть кривойЮ, то должно получится близко к тому, что в вики, и без готу.


Оо, а вы знаете какой будет размер списка троек???
Для 10000 точек может быть ~1Gb
Для 20000 ~7,5Gb и растет кубично

Хороший способ избавиться от готу
Re[13]: Существуют ли задачи, где использование GOTO оправда
От: NikeByNike Россия  
Дата: 01.08.07 14:02
Оценка:
Здравствуйте, unreg_flex, Вы писали:

NBN>>Вот тот пример
Автор: NikeByNike
Дата: 01.08.07
, более короткий чем твой Читабельнее?

_>А почему на этот раз пробелы отступы и переносы оставили?

Чтобы небыло обвинений в том, что впадаю в крайности

_>Это далеко не тоже самое, std::string::c_str дает указатель на свой собственный буфер,

_>а тут копируют чужой указатель в переменную объекта во время его сборки,
_>юзер босле сборки объекта может удалить указатель (в конце концов это его собственный указатель),
_>а невалидный указатель останется торчать в классе.
Не, это просто объект-поведение. В принципе он идеологически похож на какой-нибудь binder2nd.

NBN>>От готу далеко ушли

_>Скоро до палитеки дойдем
Уже близко Предлагаю закончить.
Нужно разобрать угил.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: chooch  
Дата: 01.08.07 14:04
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


Это все черный пиар !
Большинство людей которые кричат что "goto — корень зла" сами не знают почему так...
Это, блин, какя то массовая параноя
Меня просто бесят такие рассуждения типа:

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


Конструкция goto ничем не хуже всех остальных ! (Это не значит что ее следует пихать куда попало)
Но иногда она хорошо помогает
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: hell citizen Россия  
Дата: 01.08.07 14:04
Оценка: +1
Здравствуйте, unreg_flex, Вы писали:

_>Оо, а вы знаете какой будет размер списка троек???

_>Хороший способ избавиться от готу

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

То, что имеется сейчас — хороший способ усложнить себе жизнь, когда кроме окружностей программа должна будет работать с эллипсами или другими кривыми и группами из N точек. Даже если в данном случае этого никогда не произойдёт, это не означает, что подобная функциональность не понадобится вам в некоторой другой вашей программе.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: hell citizen Россия  
Дата: 01.08.07 14:34
Оценка: 1 (1)
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


VB6: On Error Goto ERR — стандартная конструкция языка.
SQL: if @@error != 0 goto ERR — тоже самое.

В обоих случаях без готу не обойтись, если хочется иметь один обработчик ошибок на всю функцию или процедуру. Правда, здесь это скорее свидетельство кривости языка чем архитектуры вашего приложения
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 01.08.07 14:50
Оценка:
Здравствуйте, hell citizen, Вы писали:

HC>А разве обязательно хранить полный список троек для работы этого алгоритма? Я думаю, нет. Можно написать функции получение_следующей_группы_точек() и проверка_группы_точек() — тогда будет практически один-в-один оригинал.


В таком случае придется в классе хранить еще и состояния всех циклов.
А также все локальные переменные.
Затем сделать функции типа GetFirstPointsGroup(...) и GetNextPointsGroup(...).
Добавить кучу ненужных операторов.
А еще лучше создать класс PointsGroupIterator, перегрузить для него хз сколько операторов.
Всей этой хренью конечно можно позаниматься, только вот зачем???

HC>То, что имеется сейчас — хороший способ усложнить себе жизнь, когда кроме окружностей программа должна будет работать с эллипсами или другими кривыми и группами из N точек. Даже если в данном случае этого никогда не произойдёт, это не означает, что подобная функциональность не понадобится вам в некоторой другой вашей программе.


Сейчас программы работают и с эллипсами и окружностями и прямыми и даже с трехмерными полиномиальными объектами.
То что я тут привел это старый код, в новом построен N раз вложенный цикл на шаблонах,
По сути, можно вписывать произвольные K-мерные объекты в N мерные данные (можно набор столов в стулья вписать),
но goto там все равно остался
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: hell citizen Россия  
Дата: 01.08.07 14:56
Оценка: :))) :))
Здравствуйте, konsoletyper, Вы писали:

K>Goto — признак не кривизны кода, а кривизны языков, в которых без него порой никак (C, C++, C#, Pascal, Java, etc) и кривизны профанации под названием "структурное программирование" с его т.н. "циклами с предусловиями", "циклами с постусловиями" и "ветвлениями", которые являются не элементарными конструкциями, а типовыми паттернами, в которые задача не всегда удобно ложится.


K>Правда, пока для всяких Haskell не понаписали мегаоптимизаторов, Goto будет актульно для кодогенераторов в другие, более "низкоуровневые" языки.


K>Так что если кто-то пишет на C++ и вынужден юзать goto, пусть не стесняется, и посылает своих знакомых на 3 весёлых буквы. В конце концов, это не его вина. Кстати, виной K&R и Бьярни это тоже не является, т.к. это не они призывают в наш просвещённый XXI век всё и вся писать на C++ и (о боже!) на C.


C++ — Труъ.
Asm — Древний Язык Могучих Богов.
Всё остальное — для жалких виклингов, не способных осознать и применить всю мощщщ арифметики с указателями, dynamic_cast и частичной специализации шаблонов.

А джедаев для фортран есть вот ещё
Re[12]: Существуют ли задачи, где использование GOTO оправда
От: hell citizen Россия  
Дата: 01.08.07 15:00
Оценка:
Здравствуйте, unreg_flex, Вы писали:

_>Сейчас программы работают и с эллипсами и окружностями и прямыми и даже с трехмерными полиномиальными объектами.

_>То что я тут привел это старый код, в новом построен N раз вложенный цикл на шаблонах,
_>По сути, можно вписывать произвольные K-мерные объекты в N мерные данные (можно набор столов в стулья вписать),
_>но goto там все равно остался

Ну тогда это вопрос уже личных предпочтений, мне больше нравится итератор, чем N раз вложенный цикл на шаблонах Нравится он мне в основном тем, что реализуемый алгоритм будет похож на его описания в открытых источниках и тем, что его использование будет похоже на STL. Не то что бы я её фанат, но стандартно — это хорошо, особенно если код передавать надо.
Re[13]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 01.08.07 15:12
Оценка:
Здравствуйте, hell citizen, Вы писали:

HC>Ну тогда это вопрос уже личных предпочтений, мне больше нравится итератор, чем N раз вложенный цикл на шаблонах Нравится он мне в основном тем, что реализуемый алгоритм будет похож на его описания в открытых источниках и тем, что его использование будет похоже на STL. Не то что бы я её фанат, но стандартно — это хорошо, особенно если код передавать надо.


Без передачи кода все равно не обойтись, иначе для каждого нового объекта тебе придется реализовывать весь RANSAC заново.
А так все гораздо проще, шаблон параметризуется только функцииями расстояния от точки до объекта и функцией пересечения объектов.
На выходе сразу массив распознанных объектов.
А итераторы тут не причем.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.08.07 19:08
Оценка:
Здравствуйте, ionicman, Вы писали:

N>>Страуструп сильно непоследователен. goto он разрешил, у которого есть значительные проблемы в реализации (например, та же тема с конструкторами объектов, когда переход происходит в середину блока, или чуть попроще — при выходе по goto из блока) — тут уже проблемы с этим обсуждали. А вот значительно менее проблемное try-finally он принципиально не разрешает, потому что, видите ли, есть RAII и всё что надо делать — можно сделать на нём.

I>Ну во первых то что он был "непоследователен" :D И сделало язык C++ таким богатым ;)

Гм? Вся эпоха где-то до начала шаблонов относительно рациональна, прямолинейна и последовательна. Только на шаблонах начинается существенная развилка. К тому же это немного не та "непоследовательность".

N>>Я бы согласился с его позицией, если бы он, аналогично современному managed/unmanaged коду, сделал метки "этот код написан в таком вот стиле, goto разрешить, сложные объекты и исключения запретить" (условно говоря). Но ведь он этого не сделал.

I>А зачем? есть goto нфрфду с исключениями — используй то что считаешь нужным. Стили и разрешения и запрещения на них — это придумали люди, использующие C++ ) Как он мог сказать за всех? У него есть рекомендации по написанию, есть еще тысячи вариантов как это делать. Выбери свое и придерживайся этого. Я за это его и уважаю что он не седлал так "Это неправильно — делайте так".

Ну да, не сделал. Различных стилевых ограничивающих решений в языке сотни. С ходу:
— тот же отказ от try/finally
— принудительная инициализация полей класса до начала работы конструктора
— принудительный вызов конструктора предка до конструктора потомка
— VMT при работе конструктора — VMT этого класса, а не создаваемого
— отказ от явного property

вечер, надоело думать:) причём это те, которые пришли с ходу в результате сравнения с другими ООП языками всех достаточно близких стилей. Второе и третье, например, часто мешают, вплоть до того, что конструктор превращается в создателя корректного, но "мёртвого" объекта, а реальная работа по созданию идёт отдельным вызовом. И это всё случаи, что ради некоторых достаточно абстрактных соображений меня лишили возможности сделать так, как мне нужно, без извращений.

I>>>ИМХО — goto очень удобный инструмент при переходе внутри вложенных циклов. Ибо стандартно в C нет continue метка или break метка. А использовать флажки, как предлагалось выше — это кончено верх изящества ))))

N>>Флажки нужны там, где код надо строго доказать.
I>Они кроме того что замедляют исполнение абсолютно не нужныю Кроме того читать код с кучей симафоров гораздо хуже чем м темже goto. пример — для бэк трэкинга в 3 вложенных циклах при условии трекинга в пределах самого высокого требуется 2 флага — как Вам такое?

Нормально. Там, где нужно полное соответствие структурному стилю — там эти затраты оправдываются.:) В остальных местах можно и goto применить.:)

N>>Но я лично очень "за" помеченные циклы, аналогично перлу. Проблем от этого минимум, польза — огромная.

I>Не, ну вариантов много. Я уже приводил пример выше про continue / break + label.

А я про что? Это они же.

I> Ну на самом деле goto не только в циклах удобен. Этим полностью решить все неудастся.


Ну не всё, ну процентов 50, наверно, таки решится.
The God is real, unless declared integer.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: elmal  
Дата: 02.08.07 08:07
Оценка:
Здравствуйте, hell citizen, Вы писали:

HC>VB6: On Error Goto ERR — стандартная конструкция языка.

HC>SQL: if @@error != 0 goto ERR — тоже самое.

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

ИМХО лучше делать по другому. Использовать on error resume next, после которого идет вызов ОДНОЙ функции (за 2 функции нужно расстреливать ). Затем сразу проверять код возврата и обрабатывать ошибки, на этом функцию лучше закончить, в редких случаях поставить on error goto 0 (главное не забыть поставить ) и продолжить. В результате имеем тоже самое, что try catch, только с другим синтаксисом и не можем к сожалению в объект err добавить объект, содержащий всю информацию о месте ошибки. А On Error Goto ERR в топку.
К такому стилю пришел через полтора года мучений с VB, дальше к счастью этот язык успешно забыл . Но вроде успел понять, как на нем нужно нормально писать, думаю, что опыт пригодился .
Re[14]: Существуют ли задачи, где использование GOTO оправда
От: hell citizen Россия  
Дата: 02.08.07 13:01
Оценка:
Здравствуйте, unreg_flex, Вы писали:

_>Без передачи кода все равно не обойтись, иначе для каждого нового объекта тебе придется реализовывать весь RANSAC заново.


Я говорил о той передаче, когда ты передаёшь код другому человеку для поддержки
Re[15]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 02.08.07 14:07
Оценка:
Здравствуйте, hell citizen, Вы писали:

HC>Я говорил о той передаче, когда ты передаёшь код другому человеку для поддержки


Re: Существуют ли задачи, где использование GOTO оправдано?
От: Awaken Украина  
Дата: 02.08.07 19:37
Оценка: +1
V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.

есть разные парадигмы программирования. использование GOTO плохо в структурном ("виртовском") программировании.
но вполне естественно для модели программы построенной по типу конечного автомата, т.к. переходы между стейтами в КА это и есть по сути GOTO.
Re[5]: Существуют ли задачи, где использование GOTO оправдан
От: ionicman  
Дата: 03.08.07 06:56
Оценка: 2 (1)
N>Ну да, не сделал. Различных стилевых ограничивающих решений в языке сотни. С ходу:
N>- тот же отказ от try/finally
так эту конструкцию можно сэмулировать если надо? или я ошибаюсь?
N>- принудительная инициализация полей класса до начала работы конструктора
эээ.... не понял... а чем мешает то? ну надо тебе в конструкторе проинитить — проинить в нем — ну будет 2 инициализации — чего страшного?
N>- принудительный вызов конструктора предка до конструктора потомка
эээ.... ну это очень спорный аргумент ибо есть извечная борьба курицы с яйцом.
N>- VMT при работе конструктора — VMT этого класса, а не создаваемого
ну это концепция языка, кстати достаточно существенно ускоряющая выборку и затраты для VMT
N>- отказ от явного property
Вот про последнее не понял, что хотел сказать.

N>вечер, надоело думать причём это те, которые пришли с ходу в результате сравнения с другими ООП языками всех достаточно близких стилей. Второе и третье, например, часто мешают, вплоть до того, что конструктор превращается в создателя корректного, но "мёртвого" объекта, а реальная работа по созданию идёт отдельным вызовом. И это всё случаи, что ради некоторых достаточно абстрактных соображений меня лишили возможности сделать так, как мне нужно, без извращений.


Ну во первых если это мешает — то скорей всего не очень хорошо продумана модель. Приведи пример чтобы понять.

N>Нормально. Там, где нужно полное соответствие структурному стилю — там эти затраты оправдываются. В остальных местах можно и goto применить.

:D вариант конечно, но goto лучше ) ибо семафоры — лишние условия достаточно накладные расходы если цикл большой, либо обширная вложенность

N>>>Но я лично очень "за" помеченные циклы, аналогично перлу. Проблем от этого минимум, польза — огромная.

I>>Не, ну вариантов много. Я уже приводил пример выше про continue / break + label.
N>Ну не всё, ну процентов 50, наверно, таки решится.
Быть может, по % спорить не буду )
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.08.07 08:25
Оценка:
Здравствуйте, ionicman, Вы писали:

N>>Ну да, не сделал. Различных стилевых ограничивающих решений в языке сотни. С ходу:

N>>- тот же отказ от try/finally
I>так эту конструкцию можно сэмулировать если надо? или я ошибаюсь?

Блин. Мы про богатство языка и наличие альтернатив, или про что?
При чём тут возможность эмуляции??? Классы тоже сэмулировать можно. И все прочие возможности выше Си.
И половину возможностей Си тоже можно сэмулировать. Кстати, программы станут понятнее.:)

N>>- принудительная инициализация полей класса до начала работы конструктора

I>эээ.... не понял... а чем мешает то? ну надо тебе в конструкторе проинитить — проинить в нем — ну будет 2 инициализации — чего страшного?

При том, что бывают ситуации, когда необходимо, например,
— вызвать некоторую сложную функцию для обработки входных данных конструктора
— использовать её ответ для инициализации _нескольких_ полей

N>>- принудительный вызов конструктора предка до конструктора потомка

I>эээ.... ну это очень спорный аргумент ибо есть извечная борьба курицы с яйцом.

Аргумент о чём? Я и говорю, что было выбрано решение, жёстко ограничивающее возможности программиста.

N>>- VMT при работе конструктора — VMT этого класса, а не создаваемого

I>ну это концепция языка, кстати достаточно существенно ускоряющая выборку и затраты для VMT

Что она ускоряет, если каждому конструктору надо менять VMT на свою?

N>>- отказ от явного property

I>Вот про последнее не понял, что хотел сказать.

Во многих языках property — это нечто выглядящее как переменная, но реально вызывающее методы _класса_ (а не этого поля) для чтения и присвоения. Хорошая замена традиционным для C++ getXxx(), setXxx().

I>Ну во первых если это мешает — то скорей всего не очень хорошо продумана модель. Приведи пример чтобы понять.


Ага, ага. Как только говорится о том, что чего-то нет — мне сразу "на сегодня потребности в колбасе нет". Не надоело?
Наконец, я не понимаю, к чему это всё, если предшествующая дискуссия шла в духе
— C++ необычайно гибок, в нём нет искусственных ограничений
— да вот же они: (1) (2) (3) (4)

Или Вы считаете, что эти все ограничения, которые я перечислил — "естественны"? Ну тогда посмотрите ещё несколько ООП языков, где решения совсем иные — и подумайте, почему там эти вещи сделаны совсем иначе.:)
The God is real, unless declared integer.
Re[7]: Существуют ли задачи, где использование GOTO оправдан
От: ionicman  
Дата: 03.08.07 09:04
Оценка:
N>Блин. Мы про богатство языка и наличие альтернатив, или про что?
N>При чём тут возможность эмуляции??? Классы тоже сэмулировать можно. И все прочие возможности выше Си.
N>И половину возможностей Си тоже можно сэмулировать. Кстати, программы станут понятнее.
хехе ну та то конструкцмя действительно просто эмулится.

N>>>- принудительная инициализация полей класса до начала работы конструктора

I>>эээ.... не понял... а чем мешает то? ну надо тебе в конструкторе проинитить — проинить в нем — ну будет 2 инициализации — чего страшного?
N>При том, что бывают ситуации, когда необходимо, например,
N>- вызвать некоторую сложную функцию для обработки входных данных конструктора
N>- использовать её ответ для инициализации _нескольких_ полей
эээ:

somthing( a,b,c ) {
bigCount( &a,&b, &c );
this->prop1 = a;
this->prop2 = b;
...
}

это не канает?

N>>>- принудительный вызов конструктора предка до конструктора потомка

I>>эээ.... ну это очень спорный аргумент ибо есть извечная борьба курицы с яйцом.

N>Аргумент о чём? Я и говорю, что было выбрано решение, жёстко ограничивающее возможности программиста.

как можно создать потомка без конструктора предка в НИЗКОУРОВНЕВОМ языке?

N>>>- VMT при работе конструктора — VMT этого класса, а не создаваемого

I>>ну это концепция языка, кстати достаточно существенно ускоряющая выборку и затраты для VMT
N>Что она ускоряет, если каждому конструктору надо менять VMT на свою?
Выборку она ускоряет — для того чтобы определить нужный вектор не требуется бегать и собирать данные по наледышам

N>>>- отказ от явного property

I>>Вот про последнее не понял, что хотел сказать.

N>Во многих языках property — это нечто выглядящее как переменная, но реально вызывающее методы _класса_ (а не этого поля) для чтения и присвоения. Хорошая замена традиционным для C++ getXxx(), setXxx().


это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз и два — она не согласуется с прницпом что у класа есть methods & properties. т.к. она является средним между ними.

Хотя да, достаточно удобно, согласен. албтернативы есть — тотже поток ввода, хотя так красиво конечно не будет.

I>>Ну во первых если это мешает — то скорей всего не очень хорошо продумана модель. Приведи пример чтобы понять.


N>Ага, ага. Как только говорится о том, что чего-то нет — мне сразу "на сегодня потребности в колбасе нет". Не надоело?

N>Наконец, я не понимаю, к чему это всё, если предшествующая дискуссия шла в духе
N>- C++ необычайно гибок, в нём нет искусственных ограничений
N>- да вот же они: (1) (2) (3) (4)

Хехе. Видишь присуща языкам более высокого уровня. тебяж не смущает что в СИ именованых массивов нет? Единственное с чем могу согласится это по поводу getters & setters. но мож и будет в след. стандартах.

Ну и не забывай — абсолютно универсального и свободного нет ничего. Просто в СИ всего n пунктов тебя не устраивающих — в жругих языках гораздо больше будет, только сравнивай языки одного уровня.

N>Или Вы считаете, что эти все ограничения, которые я перечислил — "естественны"? Ну тогда посмотрите ещё несколько ООП языков, где решения совсем иные — и подумайте, почему там эти вещи сделаны совсем иначе.


Конечно. Приведи пример таких языков? я таких не знаю.
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: AndrewJD США  
Дата: 03.08.07 09:11
Оценка:
Здравствуйте, ionicman, Вы писали:

I>это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз

Какие расходы? Это всего лишь синтаксический сахр.

I>и два — она не согласуется с прницпом что у класа есть methods & properties. т.к. она является средним между ними.

Принцип methods & properties & variables не хуже
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: ionicman  
Дата: 03.08.07 09:15
Оценка:
Здравствуйте, AndrewJD, Вы писали:

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


I>>это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз

AJD>Какие расходы? Это всего лишь синтаксический сахр.

I>>и два — она не согласуется с прницпом что у класа есть methods & properties. т.к. она является средним между ними.

AJD>Принцип methods & properties & variables не хуже

Почитай плиз про низкоуровневые язык и реализацию в них классов — как таблицы строятся как выборка проискходит — ибо
создание сеттеров и геетеров придется запихивать изза неоднозначностив таблицы — и поймешь почему.

Хм... а есть низкоуровневый язык с реализацией такого принципа methods & properties & variables?
Я просто не встречал ни разу такое.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: AndrewJD США  
Дата: 03.08.07 11:09
Оценка:
Здравствуйте, ionicman, Вы писали:

I>>>это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз

AJD>>Какие расходы? Это всего лишь синтаксический сахр.


I>Почитай плиз про низкоуровневые язык и реализацию в них классов — как таблицы строятся как выборка проискходит — ибо

I>создание сеттеров и геетеров придется запихивать изза неоднозначностив таблицы — и поймешь почему.

Какие таблицы? Речь идет про свойства, котрые преобразуются в вызов сеттеров и геетеров.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: ionicman  
Дата: 03.08.07 11:20
Оценка:
I>>Почитай плиз про низкоуровневые язык и реализацию в них классов — как таблицы строятся как выборка проискходит — ибо
I>>создание сеттеров и геетеров придется запихивать изза неоднозначностив таблицы — и поймешь почему.

AJD>Какие таблицы? Речь идет про свойства, котрые преобразуются в вызов сеттеров и геетеров.


ЭЭЭ.... т.е. ты предлагаешь при компиляции просто подставлять там где читается/пишется вызов фии? :D

Не так все просто — ибо есть полиморфизм и все остальное. Надо гдето хранить что это есть сеттер, это есть фя, а это есть вариабля. Т.е. придется добавлять еще один тип. Короче — погляди как организуется хранение классов в памяти в Си — поймешь меня. Добавление еще одного типа достаточно сложнО + требует дополнительных накладных расходов.
Re[12]: Существуют ли задачи, где использование GOTO оправда
От: AndrewJD США  
Дата: 03.08.07 11:28
Оценка: +2
Здравствуйте, ionicman, Вы писали:

AJD>>Какие таблицы? Речь идет про свойства, котрые преобразуются в вызов сеттеров и геетеров.


I>ЭЭЭ.... т.е. ты предлагаешь при компиляции просто подставлять там где читается/пишется вызов фии? :D

Типа того.

I>Не так все просто — ибо есть полиморфизм и все остальное. Надо гдето хранить что это есть сеттер, это есть фя, а это есть вариабля. Т.е. придется добавлять еще один тип. Короче — погляди как организуется хранение классов в памяти в Си — поймешь меня. Добавление еще одного типа достаточно сложнО + требует дополнительных накладных расходов.

Ничего не надо. На структуру класса это никак не влияет. Это просто синтаксическое удобство, не более.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[13]: Существуют ли задачи, где использование GOTO оправда
От: ionicman  
Дата: 06.08.07 03:11
Оценка:
AJD>Ничего не надо. На структуру класса это никак не влияет. Это просто синтаксическое удобство, не более.

Здрасьте, а если getter / setter перегружен? и выяснить это невозможно на этапе компилляции а только при выполнении ( наследование )?
Re[14]: Существуют ли задачи, где использование GOTO оправда
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.08.07 05:18
Оценка:
Здравствуйте, ionicman, Вы писали:

AJD>>Ничего не надо. На структуру класса это никак не влияет. Это просто синтаксическое удобство, не более.


I>Здрасьте, а если getter / setter перегружен? и выяснить это невозможно на этапе компилляции а только при выполнении ( наследование )?

Поясняю:
1. На этапе компиляции обращение к свойству банально заменяется на вызов соответствующих методов.
2. Во время JIT (или во время всё той же компиляции) для геттеров/сеттеров применяются все те же оптимизации, что и для обычных методов.
В том числе инлайнинг для невиртуальных свойств, а это покрывает практически все тривиальные свойства. Виртуальными обычно делают нетривиальные свойства, а код доступа к нетривиальным свойствам обычно достаточно сложен, чтобы накладные расходы на косвенный вызов были на его фоне слабо заметны.
Кроме того, хороший оптимизирующий компилятор или JIT способен устранять избыточную виртуальность за счет хотспот-анализа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Существуют ли задачи, где использование GOTO оправда
От: AndrewJD США  
Дата: 06.08.07 08:09
Оценка:
Здравствуйте, ionicman, Вы писали:

AJD>>Ничего не надо. На структуру класса это никак не влияет. Это просто синтаксическое удобство, не более.

I>Здрасьте, а если getter / setter перегружен? и выяснить это невозможно на этапе компилляции а только при выполнении ( наследование )?

Если вызов getter / setter сводится к вызову функции, какая разница перегружена эта функция или нет?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: Eugeny__ Украина  
Дата: 06.08.07 12:18
Оценка:
Здравствуйте, Programador, Вы писали:

P>Если даже на это не смотреть, то область видимости расширилась на другие методы. И потом исходный код на экран помещался а этот 2 раза перелистывать нужно В общем ф топку


Хз. По мне, исходный кусок отвратительно читабелен. То, что в нем меньше символов, не говорит в его пользу. Приведенный NBN код куда более структурирован, и не вызывает головной боли при прочтении, по крайней мере.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[15]: Существуют ли задачи, где использование GOTO оправда
От: ionicman  
Дата: 09.08.07 04:16
Оценка:
I>>Здрасьте, а если getter / setter перегружен? и выяснить это невозможно на этапе компилляции а только при выполнении ( наследование )?
S>Поясняю:
S>1. На этапе компиляции обращение к свойству банально заменяется на вызов соответствующих методов.
S>2. Во время JIT (или во время всё той же компиляции) для геттеров/сеттеров применяются все те же оптимизации, что и для обычных методов.
S>В том числе инлайнинг для невиртуальных свойств, а это покрывает практически все тривиальные свойства. Виртуальными обычно делают нетривиальные свойства, а код доступа к нетривиальным свойствам обычно достаточно сложен, чтобы накладные расходы на косвенный вызов были на его фоне слабо заметны.
S>Кроме того, хороший оптимизирующий компилятор или JIT способен устранять избыточную виртуальность за счет хотспот-анализа.

Достаточно просто, согласен. Поскольку если руководствоваться тем, что getter / setter на этапе компиляции есть просто замена .s=5; на некую .method( 5 ), а для нее использовать теже алгоритмы что и для стандартного метода.
Накладные расходы в этом случае будут только у компиллятора :D Возможно действительно сделают в следующем стандарте СИ. Ибо удобно и просто ( если нет каких либо подводных камней, которые при поверхостном обсуждении мы не учли )
Re[15]: Существуют ли задачи, где использование GOTO оправда
От: ionicman  
Дата: 09.08.07 04:24
Оценка:
Вот тут жавный народ сразу же оживился и вопрошает — не может ли понадобиться на этапе выполнения знать что данный метод есть геттер / сеттер? Типа например если они одного имени — то должно както это разруливаться ибо два метода с одинаковыми названиями перекрывают друг друга. Хотя, даже в этом случае, можно определить это на этапе компилляции и добавить префикс...
Re[16]: Существуют ли задачи, где использование GOTO оправда
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.08.07 04:39
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Достаточно просто, согласен. Поскольку если руководствоваться тем, что getter / setter на этапе компиляции есть просто замена .s=5; на некую .method( 5 ), а для нее использовать теже алгоритмы что и для стандартного метода.

I>Накладные расходы в этом случае будут только у компиллятора :D
I>Возможно действительно сделают в следующем стандарте СИ.
Очень вряд ли. Во-первых, в СИ ничего подобного не предвидится по той простой причине, что в нем пока нет даже классов.
Во-вторых, в C++ ввести что-нибудь крайне тяжело.
I>Ибо удобно и просто ( если нет каких либо подводных камней, которые при поверхостном обсуждении мы не учли )
У С++ таки есть подводные камни. Это и так уже язык с чрезмерно сложной семантикой. Внесение туда свойств добавит неопределенности.
Как, к примеру, должен интерпретироваться вот такой код:
class A
{
  private:
      int _i;
    public:
      int& I { 
          get { return _i; }
            set { _i = value * 2;}
        }
}


A a;
a.I = 1; // что здесь будет выполнено? Присваивание по ссылке или вызов метода?
int k = 2;
a.I = k; // а здесь?

Я не сомневаюсь, что существует некоторый способ зарулить такие вещи. Но его поиск и обсуждение займет годы. Была такая популярная компания — разработчик компиляторов. Вот на такие штуки они напоролись в полный рост в своем Borland C++ Builder.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Существуют ли задачи, где использование GOTO оправда
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.08.07 04:46
Оценка:
Здравствуйте, ionicman, Вы писали:

I>Вот тут жавный народ сразу же оживился и вопрошает — не может ли понадобиться на этапе выполнения знать что данный метод есть геттер / сеттер?

Зачем?
I>Типа например если они одного имени
Кто "они"?
I>- то должно както это разруливаться ибо два метода с одинаковыми названиями перекрывают друг друга. Хотя, даже в этом случае, можно определить это на этапе компилляции и добавить префикс...
Бр-р. Не очень понятен вопрос.
Лично мне известны ровно две реализации property в коммерческих ЯП.
В Delphi property отображается на аксессор, и можно делать примерно так:
Type 
  A = class
    private
      _i: Integer;
        procedure SetI(aValue: Integer);
    public
      property I read _i write SetI;
    end;

Так что при чтении из I будет автоматически осуществляться чтение из _i, а при записи в I автоматически будет вызван нужный метод.
Один и тот же метод может использоваться для нескольких свойств и т.п. Методы подчиняются обычным правилам разрешения неоднозначностей, так что два метода с одинаковой сигнатурой ты не создашь.
Другая реализация применена в C# — там нет никаких отдельных методов, на которые отображается свойство:
public class A
{
  private int _i;
    public int I
    {
      get { _i = value; }
        set { return _i; }
    }
}

Компилятор сгенерирует пару методов, но получить к ним доступ нормальным способом не получится. Нельзя написать a.SetI(2), потому что никакого SetI нету. Увидеть эти методы можно только копаясь в байт-коде. Имена им придумывает компилятор, и конфликт с пользовательским методом получить тоже не удастся.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Существуют ли задачи, где использование GOTO оправда
От: romangr Россия  
Дата: 09.08.07 05:39
Оценка: 4 (2) :)
Здравствуйте, Sinclair, Вы писали:

...

S>Другая реализация применена в C# — там нет никаких отдельных методов, на которые отображается свойство:

S>
S>public class A
S>{
S>  private int _i;
S>    public int I
S>    {
S>      get { _i = value; }
S>        set { return _i; }
S>    }
S>}
S>

S>Компилятор сгенерирует пару методов, но получить к ним доступ нормальным способом не получится. Нельзя написать a.SetI(2), потому что никакого SetI нету. Увидеть эти методы можно только копаясь в байт-коде. Имена им придумывает компилятор, и конфликт с пользовательским методом получить тоже не удастся.


    public class Conflict
    {
        private int m_IntValue;

        public int IntValue
        {
            get { return m_IntValue; }
            set { m_IntValue = value; }
        }

        public int get_IntValue()
        {
            return 0;
        }
    }


?
... << RSDN@Home 1.2.0 alpha rev. 693>>
Re[18]: Существуют ли задачи, где использование GOTO оправда
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.08.07 06:05
Оценка:
Здравствуйте, romangr, Вы писали:
Прикольно, не знал.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: unreg_flex  
Дата: 12.08.07 08:22
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>Хз. По мне, исходный кусок отвратительно читабелен. То, что в нем меньше символов, не говорит в его пользу. Приведенный NBN код куда более структурирован, и не вызывает головной боли при прочтении, по крайней мере.


Исходный кусок написан корректно, в отличии от приведенного NBN, который теперь содержит ошибку и не эквивалентен исходному
Сможете указать где баг в этом "читабельном" коде и исправить ее?
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 12.08.07 08:26
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Лично я бы записал бы примерно в таком стиле ...


Как говорил наш препод, главное при оптимизации кода, не изменить результат его работы
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 12.08.07 11:38
Оценка:
Здравствуйте, unreg_flex, Вы писали:

NBN>>Лично я бы записал бы примерно в таком стиле ...


_>Как говорил наш препод, главное при оптимизации кода, не изменить результат его работы


Возрадуйся:
if( !EstimateContourDim3( i, j ) )
    break;

А какое это имеет отношение к стилю?
Нужно разобрать угил.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: alexeiz  
Дата: 16.08.07 04:25
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.




здесь
Re[18]: Существуют ли задачи, где использование GOTO оправда
От: ionicman  
Дата: 16.08.07 04:43
Оценка:
R> public class Conflict
Нда... прикольно. тоже не знал такого
Re[6]: Существуют ли задачи, где использование GOTO оправдан
От: Sergey Россия  
Дата: 16.08.07 08:20
Оценка:
> V>Вопрос не в том, что препод лох. Он мне аргументированно объяснил. Препод математик, и очень хорошо разбирается в структурном программировании. Бывает объективная необходимость во включении GOTO, для увеличения быстродействия. Мне бы хотелось услышать ответы от тех, кто считает, что GOTO имеет право на жизнь с конкретными примерами. Остальные не обижайтесь, но не надо писать сюда.
>
> здесь пример кода с xml парсером, где GOTO оператор имеет право на жизнь (см. функцию ExtractXMLFragmentFromStream). если в двух словах, то в цикле while крутится логика, которая анализирует текущее состояние парсера, и при помощи GOTO значительно увеличивается скорость парсинга.

И насколько оно будет медленнее, если вместо goto там написать просто break?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Cyberax Марс  
Дата: 16.08.07 13:11
Оценка: :)
Здравствуйте, alexeiz, Вы писали:

A>

A>здесь
Ага, вот так выглядит Gotozilla.
Sapienti sat!
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: Пётр Седов Россия  
Дата: 16.08.07 18:10
Оценка:
Здравствуйте, alexeiz, Вы писали:
A>(комикс с goto и динозавром)
Странно, я иногда использую goto, со мной такого не случалось . Наверное, не стоит делать goto JurassicPark .
Пётр Седов (ушёл с RSDN)
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Eugeny__ Украина  
Дата: 16.08.07 18:43
Оценка: +1
Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, alexeiz, Вы писали:

A>>(комикс с goto и динозавром)
ПС>Странно, я иногда использую goto, со мной такого не случалось . Наверное, не стоит делать goto JurassicPark .

Странно, я уже сколько лет программирую, и ни разу не было ситуации, где бы я хотел применить goto. Разве что правда, в мат алгоритме, который, по совместительству еще и узкое место... Но таких вещей не попадалось, обычно узкое место было сооовсем другое...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Cyberax Марс  
Дата: 16.08.07 21:28
Оценка:
Здравствуйте, Пётр Седов, Вы писали:

ПС>Здравствуйте, alexeiz, Вы писали:

A>>(комикс с goto и динозавром)
ПС>Странно, я иногда использую goto, со мной такого не случалось . Наверное, не стоит делать goto JurassicPark .
Твои дни сочтены! Я бы на твоем месте немедленно начал защищать дом от рапторов.

Говорят, что виноградный сок может помочь: http://www.seopher.com/articles/velociraptors_are_jaded_by_grape_juice_xkcd_com_
Sapienti sat!
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: unreg_flex  
Дата: 18.08.07 11:03
Оценка:
Здравствуйте, Eugeny__, Вы писали:

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


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

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

...

Это так, к слову.
Все зависит от области в которой вы работаете, и именно эта область зачастую определяет
возникновение или не возникновение определенных ситуаций.
Я тоже много лет программирую, и на целую огромную библиотеку у меня возникло всего 2-3 участка кода где есть гото.
Но это вовсе не значит, что нужно бросаться и вырезать их оттуда любой ценой.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: Bigger Российская Империя  
Дата: 18.08.07 14:14
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


V>Сейчас практически все мои знакомые программисты считают, что использование GOTO – это признак кривизны кода. Хотелось бы их разубедить.


Приходиться использовать в T-SQL

Программист — это шаман..., подарите бубен!
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: NikeByNike Россия  
Дата: 18.08.07 16:24
Оценка:
Здравствуйте, Bigger, Вы писали:

B>Приходиться использовать в T-SQL


Мне казалось разговор шёл в контексте С++'а.
Нужно разобрать угил.
Re: Существуют ли задачи, где использование GOTO оправдано?
От: x-code  
Дата: 19.08.07 21:18
Оценка:
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано? Я знаю, что существуют такие задачи, но слабо представляю, как это в живую выглядит. Вроде в синтаксических анализаторах используется, и в очень сложных математических расчётах.


Если нужно например передать управление на адрес, например, 0x98140923, то однозначно оправдано.
Жалко в С++ так не прокатит

Я видел куски кода, где операторов goto больше чем всех остальных операторов вместе взятых. Если добавить к этому, что практически все переменные там были глобальные, их имена — сокращения на невероятной смеси транслита и английского, в которой от каждого слова вставлено 1-2 буквы, выравнивания кода нет в принципе, а комментарии используются исключительно для комментирования неработающих почему-то кусков кода... то после 10 минут работы с этим хотелось запретить не только goto, но и все не-ООП возможности С++, а ООП сделать в 100 раз строже.

Однако, здравый смысл учит нас — запрещать возможности все-же не стоит. goto не такая уж мощная и распространенная возможность языка, чтобы из-за нее спорить. К тому же, по сравнению с ассемблером операцию безусловного перехода сильно урезали, и в существующем урезанном виде goto в общем никому особо не нужен. Ведь метка — это ни что иное как константный указатель на код программы, и если бы ее можно было использовать именно в этом качестве... В С++ это уже затруднительно, не говоря уже о C# и Java; но в Си никаких препятствий не было... можно было ввести тип label и создавать переменные-метки и массивы меток.
L1:
 // code1
L2: 
 // code2
label Labels[2] = {L1, L2}; // тип label, массив меток
goto Labels[i]; // использование переменных меток

Хотя и это лишь возможность, востребованность которой все-же под вопросом. Возможно, какие-то сложные автоматы?
Насколько часто используются в современных программах массивы указателей на функции? Думаю, что не часто.
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Bigger Российская Империя  
Дата: 21.08.07 06:09
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


B>>Приходиться использовать в T-SQL


NBN>Мне казалось разговор шёл в контексте С++'а.


Сорри, но из первого поста это не было видно
Автор: Vedrus
Дата: 31.07.07

Программист — это шаман..., подарите бубен!
Re[7]: Существуют ли задачи, где использование GOTO оправдан
От: игппук Беларусь  
Дата: 21.08.07 06:57
Оценка:
Здравствуйте, Sergey, Вы писали:

S>И насколько оно будет медленнее, если вместо goto там написать просто break?


break там ни к месту, если вы смотрели код внимательно.
проклятый антисутенерский закон
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: Sergey Россия  
Дата: 21.08.07 07:43
Оценка:
> S>И насколько оно будет медленнее, если вместо goto там написать просто break?
>
> break там ни к месту, если вы смотрели код внимательно.

Может я конечно что-то и проглядел, но все goto там только и делают, что осуществляют выход из switch. При этом я не обнаружил ни одного места, где goto были бы во вложенных в switch циклах. Так что лучше просто скажите, где конкретно break там не подходит?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: игппук Беларусь  
Дата: 22.08.07 14:21
Оценка:
Здравствуйте, Sergey, Вы писали:

пардон, вы правы. я думал, что вы имели ввиду по брейку выход из while...
проклятый антисутенерский закон
Re: Существуют ли задачи, где использование GOTO оправдано?
От: nikov США http://www.linkedin.com/in/nikov
Дата: 27.08.07 12:33
Оценка: 4 (2) :)
Здравствуйте, Vedrus, Вы писали:

V>Люди, кто-нибудь может привести пример, где использование GOTO оправдано?


Спецификация языка C#, Ecma-334, 15.9.1 The break statement

When multiple switch, while, do, for, or foreach statements are nested within each other, a break statement applies only to the innermost statement. To transfer control across multiple nesting levels, a goto statement (§15.9.3) shall be used.

Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: SP_ Украина  
Дата: 27.08.07 13:47
Оценка: +1
Здравствуйте, konsoletyper, Вы писали:

K>Вот я и говорю: смартпоинтеры нужны, потому что нет GC. А выделенное — ложь, т.к. GC гораздо быстрее смартпоинтеров, а managed heap — быстрее unmanaged heap. Да и проблем от этих смартпоинтеров куча. Начиная хотя бы с того, что нужно не забывать использовать именно их, а не воспользоваться сдуру обычным указателем.


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

НО самое забавное получается когда несколько разных менеджеров памяти интенсивно работают одновременно. К примеру, запускаю явовский FireFox и дотнетовскую студию. Через некоторое время работы каждый из них подгреб к себе в кеш изрядное кол-во ОЗУ. И потом при переключении между задачами наблюдаем как он эти пулы на диск — с диска ворочает(с первым фаерфоксом вообще весело было, он кажется при сворачивании в таск бар себя полностью на диск высвапливал). А возможности сказать "родной освободи кеш, поерь мне что он тебе не понадобиться в ближайшее время" у юзверя нету
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: fefelov Россия  
Дата: 27.08.07 14:25
Оценка:
Здравствуйте, SP_, Вы писали:

SP_>НО самое забавное ... запускаю явовский FireFox


FF на яве написан???
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: SP_ Украина  
Дата: 27.08.07 14:35
Оценка:
Здравствуйте, fefelov, Вы писали:

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


SP_>>НО самое забавное ... запускаю явовский FireFox


F>FF на яве написан???

Никогда не интересоваля специально, но почему то всю жизнь думал так с Ну если нет — заменить слвоо "явовский" на "с самописным менеджером памяти" :-D
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: Eugeny__ Украина  
Дата: 28.08.07 07:58
Оценка:
Здравствуйте, fefelov, Вы писали:

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


SP_>>НО самое забавное ... запускаю явовский FireFox


F>FF на яве написан???


Существует порт FF для java(WebRenderer), но сам он, конечно, не жавовский
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.08.07 08:43
Оценка: 1 (1)
Здравствуйте, SP_, Вы писали:

SP_>НО самое забавное получается когда несколько разных менеджеров памяти интенсивно работают одновременно. :) К примеру, запускаю явовский FireFox и дотнетовскую студию. Через некоторое время работы каждый из них подгреб к себе в кеш изрядное кол-во ОЗУ. И потом при переключении между задачами наблюдаем как он эти пулы на диск — с диска ворочает(с первым фаерфоксом вообще весело было, он кажется при сворачивании в таск бар себя полностью на диск высвапливал). А возможности сказать "родной освободи кеш, поерь мне что он тебе не понадобиться в ближайшее время" у юзверя нету :)


А это общая проблема всего GC — оно не очень адекватно сочетается с виртуальной памятью, особенно с её "резиновой" реализацией в случае Mach-styled VM (это все юниксы и в заметной степени Windows). Единственный полностью адекватный этому вариант (но неудобный по другим параметрам) я видел в Lua: сборка полная (инкрементальной там нет) запускается когда сумма размеров объектов превысила удвоенную такую сумму сразу после предыдущей сборки. Противоположным примером была ранняя ява. Сейчас с распространением схем с поколениями, инкрементальностью и т.д. вообще непонятно, как оно себя будет вести;) а осознавать проблему на должном уровне и позволять настройки типа "приближаясь к границе 2*last_known, мы резко форсируем сборку" явовцы не хотят — видимо, им общность с нишей типа "мобилки" важнее:)

Вообще (отклоняясь в сторону) переделка VM под новые требования — давно назревшая проблема. В частности, в случае активного свопинга надо было бы раздавать процессам сообщения типа "урежьте осетра". В Win16 это было (WM_COMPACT). В Win32 похерили. Сейчас даже MSDN его не знает. Другой аспект — особенно важный для Mach-styled VM — что показатели затраты памяти процессами — это показатели примерно такого уровня, как средняя температура по больнице включая морг и крематорий: например, память процесса может состоять из
1) отображённых заведомо неизменяемых данных с диска (бОльшая часть кода и библиотек)
2) отображённых данных диска, которые могут быть локально изменены и будут наследоваться (в unix) потомками
3) отображённых данных диска, которые могут быть изменены и на диске
4) локальных данных процесса (например, стек) не порождённых как отображение диска
и при этом каждое (кроме первого) может быть общее на несколько процессов и создавать локальную копию по copy-on-write.
В этих условиях увидев, например, что пять одноимённых процессов съели по 100M памяти, нельзя сказать, сколько они съели в сумме — может, те же 100M, а может, 500M. Может быть реальной любая промежуточная цифра.
Но тут проблема даже не в учёте, а в неопределённости момента, когда переполнится память (неважно, вся системы, одного процесса или группы процессов) и как на это реагировать, учитывая, что очистительные действия тоже могут менять память и вызывать вследствие commit'а или copy-on-write новые выделения!
Лечения обсуждались, но на сейчас воз и ныне там.
The God is real, unless declared integer.
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.08.07 09:01
Оценка:
Здравствуйте, ionicman, Вы писали:

I>>>это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз

AJD>>Какие расходы? Это всего лишь синтаксический сахр.
I>>>и два — она не согласуется с прницпом что у класа есть methods & properties. т.к. она является средним между ними.
AJD>>Принцип methods & properties & variables не хуже :)
I>Почитай плиз про низкоуровневые язык и реализацию в них классов — как таблицы строятся как выборка проискходит — ибо
I>создание сеттеров и геетеров придется запихивать изза неоднозначностив таблицы — и поймешь почему.

Не понял. В чём неоднозначность-то? Компилятор ловит синтаксическое присвоение полю (переменной-члену) класса и переводит его в вызов метода (функции-члена). Где тут создавать неоднозначность? И при чём тут низкоуровневость?

I>Хм... а есть низкоуровневый язык с реализацией такого принципа methods & properties & variables?

I>Я просто не встречал ни разу такое.

А мы разве говорим про низкоуровневые языки? Уже C++ как минимум среднего уровня.
The God is real, unless declared integer.
Re[8]: Существуют ли задачи, где использование GOTO оправдан
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.08.07 09:04
Оценка:
Здравствуйте, ionicman, Вы писали:

N>>>>- принудительная инициализация полей класса до начала работы конструктора

I>>>эээ.... не понял... а чем мешает то? ну надо тебе в конструкторе проинитить — проинить в нем — ну будет 2 инициализации — чего страшного?
N>>При том, что бывают ситуации, когда необходимо, например,
N>>- вызвать некоторую сложную функцию для обработки входных данных конструктора
N>>- использовать её ответ для инициализации _нескольких_ полей
I>эээ:

I>somthing( a,b,c ) {

I> bigCount( &a,&b, &c );
this->>prop1 = a;
this->>prop2 = b;
I>...
I>}

I>это не канает?


Нет. Потому что к моменту, когда были вызваны данные действия, уже прошла какая-то инициализация, на которую были затрачены ресурсы (по минимуму, просто записать константу, или по максимуму, включая сложные внешние операции — ситуации могут быть самыми разными). Представьте себе, например, что один из инициализируемых в объекте параметров — логгер, который надо выбрать на основании специфики объекта, а решение может быть получено на основании входных данных конструктора. Что, вынести его генерацию куда-то отдельно? Делать вспомогательные функции типа createX()?

N>>>>- принудительный вызов конструктора предка до конструктора потомка

I>>>эээ.... ну это очень спорный аргумент ибо есть извечная борьба курицы с яйцом.
N>>Аргумент о чём? Я и говорю, что было выбрано решение, жёстко ограничивающее возможности программиста.
I>как можно создать потомка без конструктора предка в НИЗКОУРОВНЕВОМ языке?

А при чём тут собственно уровень языка? Я уж не говорю, что низкоуровневым сейчас лучше назвать что-то вроде Си, а в нём есть полная свобода — вызывай, не вызывай:)
Но я не против вызова конструктора предка как такового. Я против того, чтобы это было так жёстко ограничено, как сейчас. Сейчас исключаются любые сложные подсчёты, что именно вызвать у предка (какой конструктор и с какими параметрами). При том, что компилятор в состоянии проверить, например, что код написан так, что конструктор зовётся во всех возможных ветках исполнения (это уже лет 20 не проблема проверить).

N>>>>- VMT при работе конструктора — VMT этого класса, а не создаваемого

I>>>ну это концепция языка, кстати достаточно существенно ускоряющая выборку и затраты для VMT
N>>Что она ускоряет, если каждому конструктору надо менять VMT на свою?
I>Выборку она ускоряет — для того чтобы определить нужный вектор не требуется бегать и собирать данные по наледышам

Здрасти. А кто сейчас "бегает"? Вы, видимо, не представляете себе, как строится VMT. Если, например, в A определены f() и g(), обе виртуальные, а в B переопределена f(), то VMT для A будет содержать указатели на A.f() и A.g(), а VMT для B — для B.f() и A.g(). Обе VMT сидят в неизменяемой памяти (скорее даже в .code), и всё "бегание" отработано во время компиляции, таблицы составлены и конструкторы просто ставят соответствующий указатель.

N>>>>- отказ от явного property

I>>>Вот про последнее не понял, что хотел сказать.
N>>Во многих языках property — это нечто выглядящее как переменная, но реально вызывающее методы _класса_ (а не этого поля) для чтения и присвоения. Хорошая замена традиционным для C++ getXxx(), setXxx().
I>это называется getter & setter насколько я понимаю? В моделях класса СИ не сделана изза больших накладных расходов — раз и два — она не согласуется с прницпом что у класа есть methods & properties. т.к. она является средним между ними.

Нет, это называется property:) А вот уже у property есть getter и setter. И, возможно, не только они (в идеале это может быть полноценный класс). А последней Вашей фразы я совсем не понял. У класса есть methods & fields (в терминологии object pascal), или member functions и member variables (в терминологии принятой в C++ среде). Properties там нет.

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

I>Хотя да, достаточно удобно, согласен. албтернативы есть — тотже поток ввода, хотя так красиво конечно не будет.


/me совсем не понял, при чём тут поток ввода (istream?)

N>>Ага, ага. Как только говорится о том, что чего-то нет — мне сразу "на сегодня потребности в колбасе нет". Не надоело?

N>>Наконец, я не понимаю, к чему это всё, если предшествующая дискуссия шла в духе
N>>- C++ необычайно гибок, в нём нет искусственных ограничений
N>>- да вот же они: (1) (2) (3) (4)
I>Хехе. Видишь присуща языкам более высокого уровня. тебяж не смущает что в СИ именованых массивов нет?

Кто такой именованный массив? Хэш, он же словарь? Так неудивительно — уровень не тот.

I> Единственное с чем могу согласится это по поводу getters & setters. но мож и будет в след. стандартах.


А с тем, что ограничения искусственны — согласен или нет?

I>Ну и не забывай — абсолютно универсального и свободного нет ничего. Просто в СИ всего n пунктов тебя не устраивающих — в жругих языках гораздо больше будет, только сравнивай языки одного уровня.

Дык и не забываю.

N>>Или Вы считаете, что эти все ограничения, которые я перечислил — "естественны"? Ну тогда посмотрите ещё несколько ООП языков, где решения совсем иные — и подумайте, почему там эти вещи сделаны совсем иначе.:)

I>Конечно. Приведи пример таких языков? я таких не знаю.

Object Pascal, включая наиболее известный диалект от Борланда и диалект принятый на Маках. Крупное принципиальное отличие — работа с VMT в конструкторах/деструкторах — там всегда используется VMT "конечного" класса. Из-за этого переписка Trubo Vision на C++ дала множество извратов.

Python. Да, уже другой мир (динамический). В частности, есть properties (как минимум в двух разных реализациях). Ну и вообще поведение класса меняется очень жестоко хотя бы из-за __getattr__, __setaddr__ и аналогичных методов. Про метаклассы вообще не вспоминаю:)

Perl. В общем близко к Питону. За счёт основы на tied переменной вместо традиционного хэша можно вытворять много чего (те же properties — влёгкую).

Не будем растекаться в сторону например Smalltalk, чтобы не засорять тему:)
The God is real, unless declared integer.
Re[11]: Существуют ли задачи, где использование GOTO оправда
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.08.07 12:05
Оценка:
Здравствуйте, netch80, Вы писали:
N>Вообще (отклоняясь в сторону) переделка VM под новые требования — давно назревшая проблема. В частности, в случае активного свопинга надо было бы раздавать процессам сообщения типа "урежьте осетра". В Win16 это было (WM_COMPACT). В Win32 похерили. Сейчас даже MSDN его не знает.
Может, потому что он назывался WM_COMPACTING?
http://msdn2.microsoft.com/en-us/library/ms632618.aspx
Кстати, о нем до сих пор помнят: http://msdn2.microsoft.com/en-us/library/microsoft.win32.systemevents.lowmemory.aspx

N>Другой аспект — особенно важный для Mach-styled VM — что показатели затраты памяти процессами — это показатели примерно такого уровня, как средняя температура по больнице включая морг и крематорий: например, память процесса может состоять из

N>1) отображённых заведомо неизменяемых данных с диска (бОльшая часть кода и библиотек)
N>2) отображённых данных диска, которые могут быть локально изменены и будут наследоваться (в unix) потомками
N>3) отображённых данных диска, которые могут быть изменены и на диске
N>4) локальных данных процесса (например, стек) не порождённых как отображение диска
N>и при этом каждое (кроме первого) может быть общее на несколько процессов и создавать локальную копию по copy-on-write.
N>В этих условиях увидев, например, что пять одноимённых процессов съели по 100M памяти, нельзя сказать, сколько они съели в сумме — может, те же 100M, а может, 500M. Может быть реальной любая промежуточная цифра.
N>Но тут проблема даже не в учёте, а в неопределённости момента, когда переполнится память (неважно, вся системы, одного процесса или группы процессов) и как на это реагировать, учитывая, что очистительные действия тоже могут менять память и вызывать вследствие commit'а или copy-on-write новые выделения!
N>Лечения обсуждались, но на сейчас воз и ныне там.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Существуют ли задачи, где использование GOTO оправдан
От: vnp  
Дата: 28.08.07 22:18
Оценка: :)
Здравствуйте, x-code, Вы писали:

XC>Я видел куски кода, где операторов goto больше чем всех остальных операторов вместе взятых. Если добавить к этому, что практически все переменные там были глобальные, их имена — сокращения на невероятной смеси транслита и английского, в которой от каждого слова вставлено 1-2 буквы, выравнивания кода нет в принципе, а комментарии используются исключительно для комментирования неработающих почему-то кусков кода... то после 10 минут работы с этим хотелось запретить не только goto, но и все не-ООП возможности С++, а ООП сделать в 100 раз строже.


Кажется, я догадываюсь о происхождении таких кусков.

Страшилка:
Досталась мне в переделку системка. Все было написано на асме, без операционки и т.д. и т.п. Частью ее был умеренно сложная процедура; алгоритм известен только понаслышке. Поручил сотруднику неназываемой национальности переписать на Ц. Он переписал:

unsigned int AX, BX, CX, DX;
...


Угадайте, какой оператор там использовался чаще всего?
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: alexeiz  
Дата: 29.08.07 05:50
Оценка:
Здравствуйте, vnp, Вы писали:

vnp>
vnp>unsigned int AX, BX, CX, DX;
vnp>


Нестандартное мышление, однако.
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: Sni4ok  
Дата: 29.08.07 05:55
Оценка: :)
Здравствуйте, alexeiz, Вы писали:

vnp>>
vnp>>unsigned int AX, BX, CX, DX;
vnp>>


A>Нестандартное мышление, однако.


согласен, стандартно было бы

unsigned int Rax, Rbx, Rcx, Rdx;
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Erop Россия  
Дата: 03.09.07 19:12
Оценка:
Здравствуйте, vnp, Вы писали:

vnp>
vnp>unsigned int AX, BX, CX, DX;
vnp>...
vnp>


vnp>Угадайте, какой оператор там использовался чаще всего?

А как он, например, витвлся. Вообще имел доступ к слову флагов?
Как делал pop и push?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Существуют ли задачи, где использование GOTO оправда
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.09.07 19:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

N>>Вообще (отклоняясь в сторону) переделка VM под новые требования — давно назревшая проблема. В частности, в случае активного свопинга надо было бы раздавать процессам сообщения типа "урежьте осетра". В Win16 это было (WM_COMPACT). В Win32 похерили. Сейчас даже MSDN его не знает.
S>Может, потому что он назывался WM_COMPACTING?
S>http://msdn2.microsoft.com/en-us/library/ms632618.aspx

Я искал по WM_COMPACT, не нашёл в MSDN, нашёл пару упоминаний в гугле и решил, что этого доставточно. OK, название было неправильное. Но в текущих статьях чётко написано, что он только для совместимости с Win16. То есть потом таки похерили. Это основное моё утверждение здесь, название для меня несущественно.
The God is real, unless declared integer.
Re[9]: Существуют ли задачи, где использование GOTO оправдан
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 05.09.07 16:03
Оценка:
Здравствуйте, Sergey, Вы писали:

>> S>И насколько оно будет медленнее, если вместо goto там написать просто break?

>>
>> break там ни к месту, если вы смотрели код внимательно.

S>Может я конечно что-то и проглядел, но все goto там только и делают, что осуществляют выход из switch. При этом я не обнаружил ни одного места, где goto были бы во вложенных в switch циклах. Так что лучше просто скажите, где конкретно break там не подходит?


Теоретически, любой код с использованием goto можно заменить на соответствующий switch внутри цикла, и осуществлять переход на как goto label, а как { new_state = label; break; }. Только это (1) две строчки вместо одной (2) дополнительный lookup по таблице вместо jump (3) дополнительная нагрузка для мозгов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Существуют ли задачи, где использование GOTO оправдан
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 05.09.07 16:27
Оценка: +1
Здравствуйте, Vedrus, Вы писали:

V>ЗЫ. Может у кого ещё примеры есть


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

e2-e4
Ng1 — f3
e5 : d4
e5 x d4
e4
Nf3
Nxf3
Ngf3
Ngxf3
N1d2
N1xd2
Qa1b2
Qa1xb2
exd4
ed
ed4

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

  state = START;
    while (state != FINISH)
      switch(state)
        {
          case START:
              /* ... */
                state = AFTER_FIGURE;
                break;
            case AFTER_FIGURE:
      ............
           case AFTER_FILE:    
      ............
           case AFTER_RANK:    
      ............
           case DEST_FILE:    
        }
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Существуют ли задачи, где использование GOTO оправдан
От: vnp  
Дата: 05.09.07 17:47
Оценка:
Здравствуйте, Erop, Вы писали:

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


vnp>>
vnp>>unsigned int AX, BX, CX, DX;
vnp>>...
vnp>>


vnp>>Угадайте, какой оператор там использовался чаще всего?

E>А как он, например, витвлся. Вообще имел доступ к слову флагов?
E>Как делал pop и push?

Вручную!
Re[10]: Существуют ли задачи, где использование GOTO оправда
От: Sergey Россия  
Дата: 06.09.07 07:14
Оценка:
>>> S>И насколько оно будет медленнее, если вместо goto там написать просто break?
>>>
>>> break там ни к месту, если вы смотрели код внимательно.
>
> S>Может я конечно что-то и проглядел, но все goto там только и делают, что осуществляют выход из switch. При этом я не обнаружил ни одного места, где goto были бы во вложенных в switch циклах. Так что лучше просто скажите, где конкретно break там не подходит?
>
> Теоретически, любой код с использованием goto можно заменить на соответствующий switch внутри цикла, и осуществлять переход на как goto label, а как { new_state = label; break; }. Только это (1) две строчки вместо одной (2) дополнительный lookup по таблице вместо jump (3) дополнительная нагрузка для мозгов.

В данном конкретном случае ситуация обратная — два слова goto label можно поменять на один break. Впрочем, вы меня не поняли — я вовсе не критикую само решение использовать в этом коде goto. Как ни странно, применение там break только ухудшит читаемость. Просто аргументация насчет производительности мне показалась не соответствующей действительности.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.