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

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

J>>сделал более детальное фильтрование

J>>

J>>nt4 sources

J>>$ grep -r --include=*.c -P 'goto (.+);' "C:/nt4"
J>>result: 42538 goto

J>>$ grep -r --include=*.{cpp,cxx,cc} -P 'goto (.+);' "C:/nt4"
J>>result: 8236 goto
J>>

J>>

J>>win2k sources

J>>$ grep -r --include=*.c -P 'goto (.+);' "C:/win2k"
J>>result: 16523 goto

J>>$ grep -r --include=*.{cpp,cxx,cc} -P 'goto (.+);' "C:/win2k"
J>>result: 23022 goto
J>>

К>Не ожидал. Я еще понимаю в C, но в C++ goto практически бесполезен

Практическое применение при желании можно найти, но это говорит о том, что человек ничего не понимает в ООП.

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

С>Когда я слышу от програмиста подобную фразу, что это "хороший способ подчистки", то делаю однозначный вывод, что этого программиста ни в коем случае нельзя брать в проект, так как оон "понадчистит", что потом придется ночами все исправлять!

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

  /* code */

  r1 = alloc_resource1();
  if (error) 
  {
    return FAIL;
  }

  /* code */

  r2 = alloc_resource2();
  if (error)
  {
    free_resource(r1);
    return FAIL;
  }   
 
  /* code */

  r3 = alloc_resource3();
  if (error)
  {
    free_resource(r2);
    free_resource(r1);
    return FAIL;
  }   

  /* code */

  free_resource(r3);
  free_resource(r2);
  free_resource(r1);
  return OK;

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

С>В жизни можно чего-то добиваться плохими средствами, а можно хорошими. Я предпочитаю хорошими.

как-то вы так хорошо свяазали goto с успехами в жизни, и как успех уже близок?

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

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

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

J>>>вывод ? goto сила

S>>goto средство- как и нож, не более того, а фанатиков с фгм — в топку


С>В жизни можно чего-то добиваться плохими средствами, а можно хорошими. Я предпочитаю хорошими.

Уважаемый, ну может все же снизойдете и дадите хотя бы намек, как же в С (не С++) "изящно" освобождать ресурсы?
А насчет 1-2-3 программист пришел поставил "гоуту не туда" — нефиг катать функции листингом как все исходники Винды. Тогда и goto дам будет адын.

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

M>Здравствуйте, Сыроежка, Вы писали:

С>>Когда я слышу от програмиста подобную фразу, что это "хороший способ подчистки", то делаю однозначный вывод, что этого программиста ни в коем случае нельзя брать в проект, так как оон "понадчистит", что потом придется ночами все исправлять!

M>А как иначе сделать без оверхида? Не скажу, что такой код прямо лучше

M>

M>  /* code */

M>  r1 = alloc_resource1();
M>  if (error) 
M>  {
M>    return FAIL;
M>  }

M>  /* code */

M>  r2 = alloc_resource2();
M>  if (error)
M>  {
M>    free_resource(r1);
M>    return FAIL;
M>  }   
 
M>  /* code */

M>  r3 = alloc_resource3();
M>  if (error)
M>  {
M>    free_resource(r2);
M>    free_resource(r1);
M>    return FAIL;
M>  }   

M>  /* code */

M>  free_resource(r3);
M>  free_resource(r2);
M>  free_resource(r1);
M>  return OK;
M>

В общем случае этот подход значительно лучше. То есть вы знаете. если условие не выполнено, то вам не надо просматривать всю функцию до ее завершения. А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, оон может освободить resurce2. То есть вступает в игру ООП.
Проблема с goto помимо прочих недостатков заключается в том, что другие программисты уже должны подчиняться этому дизайну и вставлять свои goto в тело функции. В противном случае либо надо целиком пересматривать дизайн функции, лиюо начнется дублирование кода, и функция будет разрастаться.

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

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

> ... skip

M>>А как иначе сделать без оверхида? Не скажу, что такой код прямо лучше

M>>

M>>  /* code */

M>>  r1 = alloc_resource1();
M>>  if (error) 
M>>  {
M>>    return FAIL;
M>>  }

M>>  /* code */

M>>  r2 = alloc_resource2();
M>>  if (error)
M>>  {
M>>    free_resource(r1);
M>>    return FAIL;
M>>  }   
 
M>>  /* code */

M>>  r3 = alloc_resource3();
M>>  if (error)
M>>  {
M>>    free_resource(r2);
M>>    free_resource(r1);
M>>    return FAIL;
M>>  }   

M>>  /* code */

M>>  free_resource(r3);
M>>  free_resource(r2);
M>>  free_resource(r1);
M>>  return OK;
M>>

С>В общем случае этот подход значительно лучше. То есть вы знаете. если условие не выполнено, то вам не надо просматривать всю функцию до ее завершения. А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, оон может освободить resurce2. То есть вступает в игру ООП.
Вы знаете, на ... вертеть такой "мощный" выход "ООП" на арену.

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

DT>Здравствуйте, Сыроежка, Вы писали:

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

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

J>>>>вывод ? goto сила

S>>>goto средство- как и нож, не более того, а фанатиков с фгм — в топку


С>>В жизни можно чего-то добиваться плохими средствами, а можно хорошими. Я предпочитаю хорошими.

DT>Уважаемый, ну может все же снизойдете и дадите хотя бы намек, как же в С (не С++) "изящно" освобождать ресурсы?
DT>А насчет 1-2-3 программист пришел поставил "гоуту не туда" — нефиг катать функции листингом как все исходники Винды. Тогда и goto дам будет адын.

Из вашего сообщения можно лишь сделать однозначный вывод, что вы в крупных проектах не работали. Так, пишите какой-то местечковый код, а потому и мировоззрение в программировании у вас крайне ограниченное.
Чтобы вам было понятно насчет "катать функции", то я вам скажу, что в проектах бывает около тысячи модулей. Проект с общим числом около 400-500 модуллей считается маленьким для софтверных компаний. проектам обычно десять а то и более лет. За это время выпустилось уже с десяток релизов проекта. Одну и ту же функцию могут писать и модифицировать за время существования проекта человек тридцать. причем даже одна строчка в функции может меняться по десять раз. Более того многие из программистов, которые модифицировали функцию даже толком сказать не в состоянии, что она делает. Чтобы было понятно, то, допустим, заказчик присылает сообщение об ошибке, а вмесет с ним либо журнал ошибок, либо дамп памяти. Начинается анализ дампа. Находится место ошибки на уровне ассемблерного кода. находите функцию, которой принадлежит этот ассемблерный код. И начинаете анализировать тот фрагмент кода, а не всю функцию, которое стало причиной ошибки. исправляете его. В итоге получается код, в котором заплата нашита на заплату, так как нет средств и возможностей переписать функцию заново. Это можно сделать лишь в плановом порядке, когда будет делаться следующий релиз, и так повезет, что эта функция войдет в перечень тех функций, которые нужно модифицировать. Многие программисты увольняются, многие поступают на работу и, практически, ни один человек не значет всех тонкостей проекта. Есть лишь отдельные люди, которые отвечают за некоторую логику проекта и проектировщики, которые код не знают, но зато знают структуру проекта и взаимосвязи между частями на логическом уровне.

Что касается примеров, как исправить код с goto, то таких примеров у меня много. Но это надо проводить целую лекцию: брать из проекта примеры кода с goto, показывать их недостатки, и как они теперь выглядят без gotо.
онимание этого как раз и определяет квалификацию программиста. А если возникают вопросы, то значит вам следует набираться опыта и повышать свою квалификацию.

Что касается языка С, то вы наверное даже и не догадываетесь, что на нем можно и не только можно, а просто нужно писать объектно-ориентированные программы. Потому что объектно-оирентированное программирование — это стиль программирования, а не технические средства. Технические средства лишь помогают вам более наглядно выразить этот стиль.
Что такое объектно-ориентированное программирование? Оно базируется на двух принципах. Первое — на построение абстракций, то есть от перехода от частного к общему и обобщеннному. Второе — каждый код должен отвечать за то, в чем ему предоставлены полномочия и компетенция.
На С это легко нарушить, так как средства инкапусляции, средства доступа, средства полиморфизма крайне ограничены. И многие программисты на С, которые не встречают преград со стороны языка часто не просто нарушают эти принципы, а даже не догадываются о них. Поэтому очень часто клиентский код лезет в реализацию серверного кода, удаляет ресурсы тот код, который не имеет компетенции это делать, реализация одной абстракции размазана по различным частям кода, что эхту абстракцию трудно выделить и увидеть. В том числе и используют goto, так как так "проще". Все это оборачивается плохим плохочитаемым кодом с многочисленными багами и непонятной логикой.

Мой вам совет: пишите на С в объектно-ориентированном стиле, и тогда у вас подобных вопросов даже не возникнет!

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

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

M>>Здравствуйте, Сыроежка, Вы писали:

С>>>Когда я слышу от програмиста подобную фразу, что это "хороший способ подчистки", то делаю однозначный вывод, что этого программиста ни в коем случае нельзя брать в проект, так как оон "понадчистит", что потом придется ночами все исправлять!

M>>А как иначе сделать без оверхида? Не скажу, что такой код прямо лучше

С>В общем случае этот подход значительно лучше. То есть вы знаете. если условие не выполнено, то вам не надо просматривать всю функцию до ее завершения. А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, оон может освободить resurce2. То есть вступает в игру ООП.

При последовательном применении идиомы 'goto cleanup' просматривать всю функцию точно также нет необходимости. А где Вы увидели зависимости между ресурсами вообще непонятно, во всяком случае, в приведенном фрагменте кода их нет, также как и ООП.

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

феерично. Добавил выделение, для тех, кто в танке не заметил дублирования кода в варианте без goto.

	Скрытый текст
	M>> M>> /* code */ M>> r1 = alloc_resource1(); M>> if (error) M>> { M>> return FAIL; M>> } M>> /* code */ M>> r2 = alloc_resource2(); M>> if (error) M>> { M>> free_resource(r1); M>> return FAIL; M>> } M>> /* code */ M>> r3 = alloc_resource3(); M>> if (error) M>> { M>> free_resource(r2); M>> free_resource(r1); M>> return FAIL; M>> } M>> /* code */ M>> free_resource(r3); M>> free_resource(r2); M>> free_resource(r1); M>> return OK; M>>

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

	Скрытый текст
	/* code */ r1 = alloc_resource1(); if (error) { result = FAIL; goto cleanup; } /* code */ r2 = alloc_resource2(); if (error) { result = FAIL; goto cleanup; } /* code */ r3 = alloc_resource3(); if (error) { free_resource(r2); free_resource(r1); return FAIL; } /* code */ result = OK; cleanup: free_resource(r3); free_resource(r2); free_resource(r1); return result;

Итого, чуть менее чем всё Вами сказанное, действительности не соответствует.

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

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

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

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

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

а потому и мировоззрение в программировании у вас крайне ограниченное.

"Критикуя, критикуй мнение, а не его автора." Леонардо да Винчи

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

С>Здравствуйте, Mr.Cat, Вы писали:

MC>>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>>вывод ? goto сила
MC>>А то. Очень хороший способ подчищать за собой в отсутствии try/finally или raii. Вот типа того:

С>Теперь представим, что ошибке в вашем коде не возникло, коогда вы делали something. значит вы продолжаете делать уже что-то другое. Получается код втда

С>do something
С>if error goto release

С>do something_another
С>if error goro // Куда goto&!!!

С>Так как вы уже успели затребовать новые ресурсы, то возникает вопрос, куда теперь надо передать управление в случае ошибки?

Туда же куда и раньше: goto release. Соответственно, последующий вывод и всё остальное неверно.

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

С>А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, он может освободить resurce2. То есть вступает в игру ООП.

Не приведи господь работать с таким кодом

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

E>Здравствуйте, Сыроежка, Вы писали:

С>>Как здесь правильно было замечано, старый код меняют лишь в крайнекй необходимости, коогда это вынуждено. То есть либо когда надо внести изменения в код в связи с новой функциональностью, либо когда найден баг. Кроме того, как я уже заметил, это могут быть комментарии. То есть у каждой функции стоит преамбула в виде ее описания, где могут использоваться для простоты работы алгоритма слова goto.
E>Как интересно, в описании алгоритма, значит, слово goto упрощает, а в коде нет?

Описание алгоритма — это несколько иное. Там нет деталей. Там может быть просто фраза, "если что-то не выполнилось, то переходим (или идем, или вообще просто goto to #3) к другому пункту". Или "если это не выполнилсоь, то идем на начало". Но "идием на начало" — это совершенно не означает, что используемп goto. Для программиста это может означать, что используется while, for или do-while.


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

E>Винда -- это весьма успешный проект, с очень многолетней историей развития и успешной историей поддержки. И goto им не помешал... А есть просто куча мегаверно написанного кода, который умер не родившись...
E>И это таки повод задуматься о верности своих идеалов

У вас с логикой проблемы. То, что проект успешный, еще не означает, что goto им не мешал! Может быть как раз очень даже мешал! Возьмите для примера MS VC++ 2010. Там столько багов, что мало не покажется. И почему вы так уверенно считаете, что причиной этих багов не является goto, если там таковые имеются?!

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

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

KO>Здравствуйте, Сыроежка, Вы писали:

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

M>>>Здравствуйте, Сыроежка, Вы писали:

С>>>>Когда я слышу от програмиста подобную фразу, что это "хороший способ подчистки", то делаю однозначный вывод, что этого программиста ни в коем случае нельзя брать в проект, так как оон "понадчистит", что потом придется ночами все исправлять!

M>>>А как иначе сделать без оверхида? Не скажу, что такой код прямо лучше

С>>В общем случае этот подход значительно лучше. То есть вы знаете. если условие не выполнено, то вам не надо просматривать всю функцию до ее завершения. А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, оон может освободить resurce2. То есть вступает в игру ООП.

KO>При последовательном применении идиомы 'goto cleanup' просматривать всю функцию точно также нет необходимости. А где Вы увидели зависимости между ресурсами вообще непонятно, во всяком случае, в приведенном фрагменте кода их нет, также как и ООП.

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

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

KO>феерично. Добавил выделение, для тех, кто в танке не заметил дублирования кода в варианте без goto.

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

KO>

	Скрытый текст
	M>>> M>>> /* code */ M>>> r1 = alloc_resource1(); M>>> if (error) M>>> { M>>> return FAIL; M>>> } M>>> /* code */ M>>> r2 = alloc_resource2(); M>>> if (error) M>>> { M>>> free_resource(r1); M>>> return FAIL; M>>> } M>>> /* code */ M>>> r3 = alloc_resource3(); M>>> if (error) M>>> { M>>> free_resource(r2); M>>> free_resource(r1); M>>> return FAIL; M>>> } M>>> /* code */ M>>> free_resource(r3); M>>> free_resource(r2); M>>> free_resource(r1); M>>> return OK; M>>>

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

	Скрытый текст
	KO> KO> /* code */ KO> r1 = alloc_resource1(); KO> if (error) KO> { KO> result = FAIL; KO> goto cleanup; KO> } KO> /* code */ KO> r2 = alloc_resource2(); KO> if (error) KO> { KO> result = FAIL; KO> goto cleanup; KO> } KO> /* code */ KO> r3 = alloc_resource3(); KO> if (error) KO> { KO> free_resource(r2); KO> free_resource(r1); KO> return FAIL; KO> } KO> /* code */ KO> result = OK; KO>cleanup: KO> free_resource(r3); KO> free_resource(r2); KO> free_resource(r1); KO> return result; KO>

KO>Итого, чуть менее чем всё Вами сказанное, действительности не соответствует.

Не смешите. О какой действительности вы говорите? О том, что вы не умете писать программы в объектно-ориентированном стиле?
Вы наивно наверное думаете, что я, когда пишу программу, только тем и озабочен, как искусственно обойтись без goto. Я вас уверяю, что это уже у меня мышление программиста такое, что я себя не насилую, а изначально мысли в идиомах структурного и объектно-ориентированного программирования.

То, что вы тут начинаете заниматься демагогией, это уже давно в истории программирования пройденный этап. Но всегда появляются люди с недостаточной квалификацией, которые начинают этот путь проходить заново. Таков общий путь развития познания. Образно говоря, сначала люди видят, что Солнце встает и закаьтывается, а потому с пеной у рта доказывают, что Солнце вертется вокруг Земли. Нужно еще приобрести много знаний, чтобы понять, что это Земля вертится вокруг Солнца, а не наоборот. То же самое и в программировании. Человек, освоивший оператор goto, и не мыслящий в объектно-ориентированном стиле, будет с пеной у рта доказывать, насколько хорош goto. И ему бесполезно что-то объяснять, пока он не подымется на новую ступень познания. Все приходит с опытом и со знаниемями. Некоторые правда так и остаются на уровне идиомы goto всю свою профессиональную жизнь.

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

KO>Здравствуйте, Сыроежка, Вы писали:

С>>Здравствуйте, Mr.Cat, Вы писали:

MC>>>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>>>вывод ? goto сила
MC>>>А то. Очень хороший способ подчищать за собой в отсутствии try/finally или raii. Вот типа того:

С>>Теперь представим, что ошибке в вашем коде не возникло, коогда вы делали something. значит вы продолжаете делать уже что-то другое. Получается код втда

С>>do something
С>>if error goto release

С>>do something_another
С>>if error goro // Куда goto&!!!

С>>Так как вы уже успели затребовать новые ресурсы, то возникает вопрос, куда теперь надо передать управление в случае ошибки?

KO>Туда же куда и раньше: goto release. Соответственно, последующий вывод и всё остальное неверно.


Забавно! А там снова надо делать теже самые проверки и осуществлять переход. Получается замкнутый круг. То есть вы просто из одного места goto перенесли в другое место.

"Бездельника хлебом не корми, а дай порассуждать, да и в умении очернить других ему не откажешь. Он всегда готов найти оправдание собственной никчёмности." Леонардо да Винчи

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

KO>>Итого, чуть менее чем всё Вами сказанное, действительности не соответствует.
С>Не смешите. О какой действительности вы говорите? О том, что вы не умете писать программы в объектно-ориентированном стиле?

Речь идёт о действительности, в которой существует такая компания как Microsoft. Я вам напомню, село Редмонд с населением 45256 человек, западное побережье одного северного континента. Там пишут вполне местечковый код. Про объектно-ориентированный стиль видимо не знают, так как часто используют goto.

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

С>Описание алгоритма — это несколько иное. Там нет деталей. Там может быть просто фраза, "если что-то не выполнилось, то переходим (или идем, или вообще просто goto to #3) к другому пункту". Или "если это не выполнилсоь, то идем на начало". Но "идием на начало" — это совершенно не означает, что используемп goto. Для программиста это может означать, что используется while, for или do-while.

Я, всё-таки, скромно надеюсь, что в коде винды на английском, а там "идём туда-то" пишут таки с пробелом: "go to tudato"...

С>У вас с логикой проблемы. То, что проект успешный, еще не означает, что goto им не мешал! Может быть как раз очень даже мешал! Возьмите для примера MS VC++ 2010. Там столько багов, что мало не покажется. И почему вы так уверенно считаете, что причиной этих багов не является goto, если там таковые имеются?!

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

С>Что касается хорошего кода, который "умер, не родившись", то это совершенно не связано с тем, что хороший код мешал развитию проекта. Хорошему проекту мешает сомнительная логика, которая имеется в ваших рассуждениях.
Мои проекты пока живут...

Значительная часть винды написана на C. Для C goto — единственный способ обеспечить cleanup.
Для C и C++ goto — единственный способ выйти из вложенного цикла (кроме функций, плодить которые в ряде случаев совсем не хочется).

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

С>>>В общем случае этот подход значительно лучше. То есть вы знаете. если условие не выполнено, то вам не надо просматривать всю функцию до ее завершения. А самое главное — этот код поддается улучшению, так как сами ресурсы могут управлять освобожлением других ресурсов, если им самим не удалось создаться. например, resource3 из вашего примера знает, что его можно выделять лишь при условии, что уже выдеен resource2, а потому при своем неуспехи, оон может освободить resurce2. То есть вступает в игру ООП.

KO>>При последовательном применении идиомы 'goto cleanup' просматривать всю функцию точно также нет необходимости. А где Вы увидели зависимости между ресурсами вообще непонятно, во всяком случае, в приведенном фрагменте кода их нет, также как и ООП.

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

Аргументов мы от Вас не дождёмся? goto использовать плохо потому, что это плохо, да?

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

KO>>феерично. Добавил выделение, для тех, кто в танке не заметил дублирования кода в варианте без goto.

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

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

KO>>

	Скрытый текст
	M>>>> M>>>> /* code */ M>>>> r1 = alloc_resource1(); M>>>> if (error) M>>>> { M>>>> return FAIL; M>>>> } M>>>> /* code */ M>>>> r2 = alloc_resource2(); M>>>> if (error) M>>>> { M>>>> free_resource(r1); M>>>> return FAIL; M>>>> } M>>>> /* code */ M>>>> r3 = alloc_resource3(); M>>>> if (error) M>>>> { M>>>> free_resource(r2); M>>>> free_resource(r1); M>>>> return FAIL; M>>>> } M>>>> /* code */ M>>>> free_resource(r3); M>>>> free_resource(r2); M>>>> free_resource(r1); M>>>> return OK; M>>>>

KO>>Итого, чуть менее чем всё Вами сказанное, действительности не соответствует.

С>Не смешите. О какой действительности вы говорите? О том, что вы не умете писать программы в объектно-ориентированном стиле?

Переходим на личности, сударь? Так бы прямо и написали, что обоснования Вашей точки зрения у Вас нет.

С>Вы наивно наверное думаете, что я, когда пишу программу, только тем и озабочен, как искусственно обойтись без goto. Я вас уверяю, что это уже у меня мышление программиста такое, что я себя не насилую, а изначально мысли в идиомах структурного и объектно-ориентированного программирования.

С>То, что вы тут начинаете заниматься демагогией, это уже давно в истории программирования пройденный этап. Но всегда появляются люди с недостаточной квалификацией, которые начинают этот путь проходить заново. Таков общий путь развития познания. Образно говоря, сначала люди видят, что Солнце встает и закаьтывается, а потому с пеной у рта доказывают, что Солнце вертется вокруг Земли. Нужно еще приобрести много знаний, чтобы понять, что это Земля вертится вокруг Солнца, а не наоборот. То же самое и в программировании. Человек, освоивший оператор goto, и не мыслящий в объектно-ориентированном стиле, будет с пеной у рта доказывать, насколько хорош goto. И ему бесполезно что-то объяснять, пока он не подымется на новую ступень познания. Все приходит с опытом и со знаниемями. Некоторые правда так и остаются на уровне идиомы goto всю свою профессиональную жизнь.

Правильно, не надо с пеной у рта ничего доказывать, просто продемонстрируйте нам как этот код должен выглядеть в "объектно-ориентированном стиле". Меньше слов больше кода.