Про использование оператора goto

[liljon]

Vago, не верно.

else {
            for (int j=0;j<words->Count;j++) {
               string s = words->Strings(j);
               if (Check(s,temp,filter,report) > -1) {
                  if (filter.changeto != "") list->Rewrite(s,i);
                     ret = true;
                  report.out += "with transform " + words->Strings(j) + "\n";
               }
            }

это должно выполниться если слово возможно "hided".

[Vago]

hide - неправильный глагол. hide - hid - hidden
...
Вы хотите сказать, что в этот else Ваша программа попадает после самого первого (самого верхнего) goto EXCEPT; ? Ой ли?...

[liljon]

нет, попадет, если утверждение верно, после всех проверок

[Vago]

Простите, какое утверждение? Скопипастите тот оператор if, о котором Вы сейчас говорите, если Вас не затруднит...

[liljon]

стойте...
Вообщем в цикле "for (int i=0;i<c;i++)", после FindWords, идет анализ каждого слова. А вы выходите из функции если найдено слово исключение (просто вы не до конца разобрались), тоесть последующие слова анализироваться не будут.
Функция CheckHideWord проверяет заэвуалировано ли слово, и если да установит флаг ret в true, что после анализа всех слов будет значит, что нужно изменить строку. Все слова разделяються и ложаться в список list и если необходимо найденное слово заменить другими символами, то это слово в этом же списке, просто перезаписывается. А дальше строка восстанавливаеться из него же в самом конце.

	if (ret)
	{
		//Восстанавливаем строку
		if (filter.changeto != "")
		{
			str = "";
			for (int i=0;i<list->Count;i++)
			{
				str += list->Strings(i) + " ";
			}
			str.erase(str.length()-1,1);
		}
	}

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

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

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

[Vago]

1. По технической стороне вопроса. Этот код включаем в ф-ю:

bool IsExcept( string &str, FILTER filter, LList* list, REPORT& report, string line, int i ) {

   bool ret = false ;

   if ( filter.changeto != "" )
      list->Rewrite(line,i) ;
   if ( report.type != EXCEPT_TRUE ) {
      ret = true ;

      //Восстанавливаем строку
      if ( filter.changeto != "" ) {
         str = "";
         for (int i=0; i<list->Count; i++) {
            str += list->Strings(i) + " " ;
         }
         str.erase( str.length()-1,1 ) ;
      }
   }

   return ret ;

}

а обращения к ней в цикле примут вид:

if ( IsExcept( str, filter, list, report, line, i ) ) continue ;

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

[liljon]

Что до идеологической стороны - абсолютно с Вами не согласен

А я с вами. Почему goto полезен я уже постарался объяснить.
И все-равно употребление goto в разумных колличествах упрощает код. Да ну вас... всегда буду использвать безусловные переходы в парсерах. Одна - две метки это нормально. Может в ассемблере тоже стоит jmp запретить? А то не безопасно как-то и затрудрняет понимание кода.

[Vago]

Сообщение от liljon

всегда буду использвать безусловные переходы в парсерах.

И обязательно почаще передавайте управление внутрь if- else- и for-блоков.

Удачи в профессиональной карьере!

[NiCola999]

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

[Oleg_SK]

Сообщение от wyvern

И то, последнее время все чаще и чаще слышу советы в данной ситуации использовать try-catch блок и просто-напросто из глубины циклов выкидывать простенькое исключеньице...

Нашел на сайте http://insidecpp.ru антиратерн, который как раз относится к использовании механизма исключений для таких целей:

Exception handling
Этот антипаттерн представляет собой реализацию нормальной логики работы программы с помощью механизма исключений. Например, рекурсивный поиск по дереву может в качестве результата поиска кидать исключение. Такая реализация на первый взгляд может выглядеть заманчиво и удобно, но не более чем на первый взгляд.
Исключения должны использоваться с одной единственной целью — проинформировать систему об ошибке. Использование исключений как инструмента для управления логикой программы вносит неоднозначность. Глядя на конструкцию try-throw-catch, программисту совершенно не очевидно, для чего именно эта конструкция используется. Кроме того, управление логикой через исключения и система оповещения об ошибках, построенная на исключениях, могут попросту мешать друг другу, поскольку они построены на одном механизме.
Для обработки ошибок используйте только исключения, а исключения — только для обработки ошибок.