Поковырял восьмёрку, надыбал всех книжек в эл. виде, ЕСИС также. Поставил все типовые конфигурации. Потом взял и самописную семёрошную конфу переписал на 1с8 сохраняя примерно алгоритмы и структуру регистров. Ну добавил уж всякие табличные части в справочники, дополнительные табличные части в документы для удобств. Получилась отличная программа работающая и решающая все проблемы, которые было сложно реализовать в 7.7. Вроде как язык восьмёрки сильно захватывал и оказался более приятным для усвоения, также как и среда разработки. Единственная проблема, которую я видел - это то, что на Мисте по вопросам 1с8 помогали менее интенсивно, чем по 7.7, но это понятно почему.
Сегодня получил пару заданий по 1с8 для УТ и понял какое я в этом деле ламо. Хоть так то запрограммировать могу, конструктором отчетик спаять, но быть спосбным редактировать типовую конфу, редактировать запросы, и вобще внедрять 1с8 - это гораздо серьёзнее задача, чем казалось. Столько всего оказывается нужно изучить. Язык запросов особенно - это отдельная тема даже. Сами типовые ещё учить да учить. Вывод сделал такой, что на 7.7 порой бывает легче сделать конфигурацию для мелкого учатска учёта самому и потом её постепенно наращивать, когда как на 1с8 сколько сколько ни пиши, аналог УТ не говоря уж о УПП или ЗУП делать безсмысленно. тут лучше хорошо изучить типовые, платформу и компоненту и начинать переделывать под клиента типовую, где требуется высокое усердие и труд. Семёрка - это детские игрушки ИМХО в плане внедрения и доработки по сравнению с 1с8. Ещё дали объект где буха 1с8 и её надо сильно переделать. хорошо ещё что ТЗ буду не я составлять и сам объект не требует коротких сроков, а готов на год заключить догово о дорабокте их конфы. Будем теперь с головой в восьмёрку погружаться и ничего не трогать пока тема не закреплена ))). КАк вобще программисты 1с8 в УПП разруливают? там же такие гигантские запросы..

Поэтому счас франи налаживают работу заказчика чтобы он вперся в логику УПП :)

(0)В УПП такой большой функционал, что удается большинство проблем решить без доработок.
Только, в УПП, по сравнению с 7.7, огромное количество регистров и виртуальных таблиц, к которым в отчетах запросы делают. Причем, в аналогичных типовых отчетах используют разные таблицы.
Часто приходится отладчиком логику вылавливать, чтобы запустить типовую конфу, в описании очень мало, общие слова.
Ты прав,в любой конфигурации 7.7 разобраться на несколько порядков проще, чем в УПП.

так это не 8-ка сложнее, а конфигурации такие :)

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

любите кататься любите и саночки возить (с).....

(4) Типовую переписать?

(6) иногда возникает такое желание... но я еще в своем уме

(0) Гыгыгы. Батенька, не с вашей нацинальностью ;-) писать на 80 конфы с нуля.
Писать конфы с нуля на 80 проще чем на 77. ;-) Это я вам как чел, знающий 77 и 80 говорю.
Просто вы не знаете 80, потому и боитесь!

Типовые конфы 1С 80 портит то, что аффторы из кожи вон лезут в борьбе за производительность, но страдает прозрачность кода.

Запросы на 10 листов - это можно увидеть в типовых, да.

Но тем не менее, в конечном итоге, все состоит из доков и регистров, так что не стоит паниковать.

(5) вам с шашечками или ехать? ;-)

(0) Типичный пример, когда человек, не разбираясь в теме, сразу выносит вердикт...
Звучит примерно, как "Да смотрел я на этот процессор - что они - из ламп не могли его сделать? Ведь руками могли бы тогда собрать! А тут надо технику подключать!"

Честно, у меня от кода в типовой начинает голова болеть :)

правильно заданный вопрос уже несет в себе большую часть ответа

(8) "...аффторы из кожи вон лезут в борьбе за производительность..." Что-то это я не заметил. Борьба за производительность все больше на словах происходит. То есть, что-то, конечно, делается, но через пень-колоду. А на днях возникла ситуевина с релизами УПП 1.2.5 и 1.2.6 которая меня вообще убила.
Клиенту обновили до 1.2.6 (нафига я не очень понял, но вроде как по договору мы обязаны обновлять всегда до актуального релиза). В результате закрытие 25го счет вместо получаса не завершилось и в течение суток. Спеца направили ко мне за помощью. Стал разбираться, оказывается, в этом релизе был впервые использован некий итерационный способ расчета ОПР (что это за зверь такой я понятия не имею). В результате по предварительным прикидам закрытие 25го счета должно выполняться только за 4-5 суток.
Ну и пришлось просто вытащить из старого релиза куски, отвечающие за закрытие ОПР. Вот тебе и борьба за производительность.

(8)Я и не спорю. НА 8.0 гораздо проще. Но вот если смотреть типовые, то там сложнее разобраться. По крайней мере на первых порах.
(10)Разьве я не правильно сказал? Типовые на восьмёрках гораздо навороченнее и не так просто врубаться в код. Вон (2) Подтвердит.

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

(15) Рома, о каком ООП речь? народ тупо не понимает базовых принципов программирования, как передача параметров по ссылке  или по значению. Какое им ООП. Много ты знаешь программистов 1С, использующих классы 1С++?

(0) Не сложнее чем Визуал Бесик. В типовых ковырятся канечно сложновато, но только для ленивых ламеров

(17) знаток :))) Думаешь, в VB все так просто?

(18) Хм. вроде слово "просто" не звучало

(14) смотри (17) - совершенно точно сказано!
(18) К слову - в VB достачно многие вещи сложны именно из-за УПРОЩЕНИЯ, т.е. большой код очень тяжело поддерживать.

PS. Мое имхо - так встроенный язык должен прийти в объектному принципу программирования - так то же УПП сложно для восприятия именно из-за процедурного подхода. Такой большой код ОЧЕНЬ и ОЧЕНЬ тяжело поддерживать без ОПП.
Обратите внимание, как часто лично вы - прогеры - используете глобальные переменные, например - попробуйте обойтись без них. Это усложнит РАЗРАБОТКУ, но значительно упростит отладку. Еще, часто встречаю такой код:

Функция ЛЯЛЯ()
[код на 10 строк]
если то-то тогда ВОЗВРАТ 1;
[код на 10 строк]
если то-то тогда ВОЗВРАТ 2;
[код на 10 строк]
если то-то тогда ВОЗВРАТ 3;
КонецФункции;

За такое расстреливать надо....

(20)Сложности это только по началу. Я вобще из С++ пришёл в 1с, а мой любимый язык - это ассемблер, но поскольку 1с штатными средствами не реализовало ООП, то и я не использую 1с++.

(21) После С++ и сложно понять восьмерку?????
НЕВЕРЮ!(С)

"но поскольку 1с штатными средствами не реализовало ООП, то и я не использую 1с++." +1

(21) Т.е в принципе ООП не нужен

(20) по большому счету большинство конф на 8 используют такой стиль программирования...

Объем кода в УПП исключает его освоение одним человеком...

(0) научиться играть в шахматы легко, научиться играть в шахматы хорошо - трудно.

(24) Именно такой стиль и не позволяет освоить в сжатые сроки код УПП
Откройте любой учебник даже не ООП, а процедурного - популярно разъяснено, почему так делать не стоит и почему это считается одним и самых плохих стилей программирования, наряду с:

Пока...Цикл
  прервать;
КонецЦикла;

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

В массе своей - суперпроизводительности от кода нет смысла - соответственно выступает требование ЧИТАЕМОСТИ кода, а какая тут читаемость с такими конструкциями...

В том же УПП - будь там код более читаем и документирован - намного, в разы, облегчило бы отладку и поддержку. Непонятно, почему в конторе это не понимают :(

ЗЫ. К слову - лично по мне, УПП сложен не в коде, а плохом знании БУ. А объем его не столь значителен - любой более менее приличный проект так и выглядит. Там много лишнего кода из-за того, процедурный подход на таких объемах уже не способен содержаться одним человеком. В случае ООП - код значительно бы сократился.

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

И не пофиг 1С-ке что в дерево метаданных помещать, ну поместили бы Классы.
А там только текстовички с процедурами и переменными, ничего более.

а= Новый Объект.ИмяКласса;
а.Процедура();
х=а.Функция();
а.Переменная=10;

Что тут сложного-то? Помогает просто упорядочивать код (процедуры, использующие общие переменные, кладутся в одно место), а не лепить  100-километровый глобальник, в котором черт ногу сломит...

(16) Передача параметров по ссылке (когда процедура меняет параметр) - зло. Я в Дельфи использую поля класса, так гораздо нагляднее.

(20) ну и что плохова в таком коде? объясни.

(28) Возможно этот запрет писался до изобретения оператора Raise Exception.

(0)Существует негласное правило в ИТ: во всех разработках\настройках может разобраться человек с квалификацией выше или такой же как и автор.

(13) Да, а ведь могли бы опционально оставить (простой алгоритм и быстрый )... Ггыгыгы

(14) дык когда инструмент проще, им можно больше навернуть. Сравни лопату и экскаватор. Лопатой ты разве окоп выкопаешь, а вот экскаватором можно такое навертеть, гыгыгыгы. Главное умеючи! ;-) Потому типовые и сложные. ;-) Хотя конечно же, 1су не мешало бы нанять специалистов по грамотному написанию кода и особенно по автоматическому тестированию! ;-)

(15) согласен, но еще долго будем жрать кактусы и радоваться.
(16) 1С++ не используют, потому что это не типовое. В 1С 80 все используют объекты - например прикладные. Еще немножко - и наследование пойдет. Да хотя бы дали ссылку на функцию, остальное сами бы приписали. Меня вот удивляет, почему не сделают ссылку на фунцкию.... Кто знает? Банальнейшая вещь. Боятся, что запутаются программисты, гыггы?

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

(20) Я бы предпочел не объектное, а аспектное программирование. ;-) Ну да это дело далекого будущего.

(26) насчет конторы, мда.... Лично мое имхо, что 1С не победит Аксапту, пока они не сделают ООП, в Аксапте-то оно давно есть. Т.е. по ходу предел сложности конф на 1С 80 - это УПП. Дальше невозможно идти. При нормальном УПП и динамическом отключении ненужных реквизитов БД УПП равнялось бы ЗУП+УТ+БП!

(28) Такой код пишется в ИСКЛЮЧИТЕЛЬНЫХ случаях - кога требуется такая же ИСКЛЮЧИТЕЛЬНАЯ производительность, которую в 8 не достичь. В данном случае должна быть ЧИТАЕМОСТЬ, т.е. такой код выглядит так:

Функция ЛЯЛЯ()
[код на 10 строк]
если то-то тогда мояПерем=1;
[код на 10 строк]
если то-то тогда мояПерем=2;
[код на 10 строк]
если то-то тогда мояПерем=3;
возврат мояПерем;
КонецФункции;

Естественно - это самый упрощенный вариант, бывают и доппроверки. Общее правило кода - функция должна дойти до конца - т.е. до КонецФункции.

(29) Исключение само по себе яв-ся исключением. И то стараются обработать ошибку и определять по результату обработки, а не тупое прерывание. Иначе придеться лазать по коду (в случае УПП - 1000 и боле строк) и искать - а в каком же месте мы вышли из функции?

(27) Передача параметров по значению - это зло, так как накладных расходы на копирование объекта. Для передачи по ссылке и указателю без изменения применяютья константные ссылки и указатели. Типовая практика на С++

(33) Ну соотвественно типовые баги в программах на С++ тоже от этого. Особенно когда функции пишут разные программисты, а ХЗ что там за переменная по ссылке и какая у нее длина.

(34) Когда пишут УПП - это вообще звиздец :)
За один день наткнулся на несколько перлов:

Если ПостроительОтчета.ВыбранныеПоля.Количество() = 0 И ПостроительОтчета.ИзмеренияКолонки.Количество() = 0 И ПостроительОтчета.ИзмеренияСтроки.Количество() = 0 Тогда
         // Выводить нечего, да еще и валится при этом, ругаясь на отсутствие SELECT
         Возврат;
КонецЕсли;

и вот это меня вообще убило:

Попытка
  // Здесь мы можем завалиться при
  // исходно совсем плохом тексте запроса Построителя
  КопияПостроителя.Текст = ПостроительОтчета.Текст;
Исключение
   Возврат; //лучше пусть завалится в другом месте
КонецПопытки;

(32) Если ты пошел в магазин за определенным товаром, и находишь его где-то в начале зала (рядом с кассой), ты все равно проходишь весь магазин до конца?

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

А чтобы пользователя не беспокоить - ставят обработчики исключения (но и они должны именно обрабатывать проблемы (например писать в лог), а не маскировать их наличие.

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

Среда .NET при исключении показывает еще стек функций (что из чего было вызвано в момент ошибки).

(35) специально поискал в УПП - нет такого в коде (1.2.5)

(35) Тебя смущают комментарии?

(39) Есть:

Основная конфигурация Отчет.ОтчетОстаткиИОбороты.Модуль объекта(2028, 7)
Основная конфигурация Отчет.ОтчетСписокКроссТаблица.Модуль объекта(2420, 7)

(35) Замечательный пример маскировки проблемы. У Микрософта есть стандарты работы с исключениями - интересно когда 1С раскачается на такие стандарты. Это же не шутки, а проблемный код.

(+42) Я про второй пример.

(39) 1.1.6.8 - древняя у меня :)

(36) Я же не прохожу мимо кассы?

По твоему:

Функция Купить()
  Пока Истина Цикл
     Если Продукт = ИскомыйПродукт Тогда
        Возврат Истина;
     КонецЕсли;
  КонецЦикла;
  Возврат ложь;
КонецФункции;

а вот так должно быть;

Функция Купить()
  Купил = Ложь;

  Пока Не Купил Цикл
     Если Продукт = ИскомыйПродукт Тогда
        Купил = Истина;
     КонецЕсли;
  КонецЦикла;
  Возврат Купил;
КонецФункции;

Мой вариант же намного легче отлаживать - ведь в первом варианте ощущение, что всегда Ложь возвращается!

(37) Есть несколько видов исключений - и они сделаны для возможности ОБРАБОТКИ ошибки, а не обхода её. По примеру, чтение данных плана обмена - в случае старой мессаги можно перехватить ошибку и продолжить программу в зависимости от нашего обработчика, но никак же не выходить напрямую.

(38) Кстати, в 1С тоже есть стек вызовов :)

(42) А что в этом коде проблемного?

(44) В твоем варианте было бы еще неплохо Прервать заюзать, а то твой покупатель будет вдвое дольше обходить магазин в среднем.

(45) Маскировка ошибки. У пользователя что-то не работает, и он не может сказать, что именно не работает (откуда ему знать, если ошибка замаскирована). Разработчик же требует: "скажите мне что у вас не работает". Пользователь посылает такого разработчика найух (иногда это происходит в мягкой форме, а иногда - в грубой, но в любом случае конечный результат - один).

(46) Прервать - есть оператор (фактически) безусловного перехода - что есть не гуд. В любом учебнике это классический пример обхода этого оператора.

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

И то - оправдано при отслеживании уничтожения объектов - а то рискуем нарваться на замусоривание памяти.

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

(46) Это код из специального отчета (ОчетСписокКроссТаблица), который реализует базовые функции для построения отчетов-оберток. Т.е. есть еще отчет "обертка", которая вызывает функции этого отчета, но за взаимодействие с пользователем отвечаем именно этот отчет "обертка" и всю заботу о сигнализировании пользователю тоже должен нести он же.
Все комментарии к коду относятся именно к таким ситуациям, особенно показателен "//лучше пусть завалится в другом месте " - т.е. завал программы будет уже в отчете-"обертке", которую программист должен отловить.

PS: Можно сказать, что отчет-"обертка" наследует некоторые функции из "родительских" -отчетов, очень похоже на ООП.

(45) Вот, нашел как этот код переделали. К слову - это код из общего модуля.
Код из УТ 10.3
// Запрос оказался синтаксически неправильным...
Попытка
КопияПостроителя.Текст = ПостроительОтчета.Текст;// <- Здесь может произойти ошибка при исходно неправильном тексте запроса Построителя
Исключение
Возврат; // Ничего не делать
КонецПопытки;

Согласись - что просто изменения стиля написания комментария тут же решило проблему

(47) Экстремальное программирование (по К.Беку) - это из другой оперы.
В 1С ты предлагаешь совсем убрать операторы Прервать, Возврат и Перейти?
Ну-ну... У тебя все переборные алгоритмы будут работать вдвое дольше...
С Возвратом я может быть и соглашусь, а с Прервать - ну убирай его у себя.
Кстати Продолжить как тебе - тоже вредный оператор?

(50)

Попытка
 Дятел.Долбление();
Исключение
 Возврат; // Ничего не делать
КонецПопытки;


Звонок пользователя: мой дятел не долбит
Ответ оператора: опишите пожалуйста подробно вашу проблему
Пользователь: бе...ме...
Оператор: извините, ничем не можем вам помочь
Пользователь: Но ваша программа не работает


В это время дятел мог
- сломать клюв
- застрять в дупле
- попасть на бетонный столб, долбление которого невозможно

и т.д.

(51) Дык все-таки почему покупатель вдвое больше будет ходить?

Тоже самое Продолжить и Прервать заменяется на Если, скорость в 1С не упадет, а читаемость и отладка повыситься.

В ООП - запрещены под страхом казни :) Плохое наследие - Оператор Switch из С - так без Break делать нечего...

(52)Налицо некорректно использование и проектирование ф-ции Долбление()
Проверять возвращаемое значение, к примеру Если Дятел.Долбление() = Возможно Тогда

(53) От множества вложенных Если ... Тогда. Иначе... код не улучиться.

+(55) Плюс нужно заводить переменные-флажки сигнализирующие о выходе из цикла

Что тоже напряжно для кода

(55)(56)(57)
Пока Истина Цикл - выглядит лучше? :)

Открываем книжку Бьерна Страуструпа ( полагаю - для многих авторитет) и читаем по поводу GoTo и иже с ним Continue..

Не цитатa - но близко к тексту "Continue - аналог Goto"
"GoTo - презираемый всеми оператор, использовани оправдано только в случая вызода из циклов с большим количеством вложений, когда вариант Break и Continue не дадут эффекта (подъем на один уровень), так же используется при автоматическом формировании кода - но рекомендуется к замене при использовании"

+(58) но согласен - лучше уж Продолжить и Прервать, чем Возврат в середине ф-ции в 1000 строк :)

(51) ромикс, видно что ты не изучал структурное программирование
Для ИНд=1 по 10 цикл
Если Инд=5 Тогда
Прервать;
КонецЕсли;
...
КонецЦикла;

Заменяется без всяких прервать:
Инд=1;
Пока Инд<=10 и Условие<>ложь Цикл
Если Инд=5 Тогда
 Условие=ложь;
Иначе
...
КонецЕсли;
КонецЦикла;


Позор, Рома!

(59) Не стоит создавать функции в 1000 строк...

(59) Да, континуе ничего страшного с кодом не делает... ;-)
Да и возврат тоже, если функции все маленькие.

У классиков это нужно, чтобы точно знать, при каких условиях функция или цикл прерываются.

(54) Возвращаемые значения вместо исключений - зло; читай Дж.Рихтера "Windows для профессионалов", глава про Исключения.

(60) Условие Пока действительно можно усложнить...
Все бы ничего, вот только код будет труднее и читать, и отлаживать.
Я всегда стараюсь сложные выражения заменять на более простые.
Между ними хотя бы можно втыкать отладочные сообщения (и доп. проверки кстати), и видеть, что происходит.

(0) я когда начинал читать код типовых в 7.7 тоже так думал а потом спустя несколько месяцев спокойно переносил куски функционала из одной типовой в другую. в 8.0 начинал с УТ, а сейчас когда пишу свои конфигурации на 80 практически фсе тупо сдергиваю из УПП, вопщем это дело привычки, к 1С привыкаешь как к езде на велосипеде :))

(61) Это к программистам УПП обращение и даже мольба!
Хотя и в УТ они умудряются так завернуть, что неделю разгребаешь.

(63) Где тут исключение? Опять-таки читаем Б.С. и выясняем, что не стоит использовать исключения для моделирования пользовательских ситуаций.
Изначальное проектирование ф-ции Долбление неправильное - а так дятел то будет смотреть, что он долбит.
Деление на ноль и т.п. естессно нет смысла так обрабатывать.

(60) Заменяется, то заменяется, а если условий дохрена?
Пока Инд<=10 и Условие<>ложь И Условие1<>ложь И Условие2<>ложь
И Условие3<>ложь Цикл
В сложном коде такое вполне может быть. Так что
(64)+1

Возвращаясь к (0) и сабжу - про любой язык можно так сказать, когда начинаешь его изучение :) Акромя GWBasic 77 года - там все просто :)

(67) Условие одно - Пока х<1 и Продолжаем Цикл
не надо лепить их много....

(69) Хм... ОК.
А как реализовать прерывании циклов вида:
Для Каждого Строка Из МассивСтрок Цикл
....

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

PS. Да и сам вид оператора Для Каждого подразумевает обработку каждого элемента...

(71) Ну значит ты не со всеми задачами сталкивался.

Мне кажется что вред от Прервать - размером с комара (если он вообще есть).
А отцеживая комара, некоторые люди ухитряются поглощать верблюда (52).

(73) +1

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

(73) полностью согласен +1

(75) Прервать не выходит из вложенных циклов, продолжить тем паче не имеет смысла...

(58)
>> Не цитатa - но близко к тексту "Continue - аналог Goto"
"GoTo - презираемый всеми оператор, использовани оправдано только в случая вызода из циклов с большим количеством вложений, когда вариант Break и Continue не дадут эффекта (подъем на один уровень), так же используется при автоматическом формировании кода - но рекомендуется к замене при использовании"

Открываю книжку Бьерна Страуструпа "The C++ Programming Language" (3 edition), Chapter 6, p.137-138, читаю:

"The goto has few uses in general highlevel programming, but it can be very useful when C++ code is generated by a program rather than written directly by a person; for example, gotos can be used in a parser generated from a grammar by a parser generator. The goto can also be important in the rare cases in which optimal efficiency is essential, for example, in the inner loop of some realtime application.
One of the few sensible uses of goto in ordinary code is to break out from a nested loop or switch-statement (a break breaks out of only the innermost enclosing loop or switch-statement).

...

There is also a continue statement that, in effect, goes to the end of a loop statement, as explained in #6.1.5."

Итак, что мы видим:
1) Словосочетание "презираемый всеми" отсутствует
2) Словосочетание "Continue - аналог Goto" отсутствует
3) Перечень применений несколько шире - помимо выхода из цикла, используется, как было сказано, при автогенерации кода. При автогенерации использование goto названо очень полезным (it can be very useful). Кроме того, использование goto может быть очень важно, если необходима высокая производительность кода в приложениях реального времени.

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

(26)
>> Откройте любой учебник даже не ООП, а процедурного - популярно разъяснено, почему так делать не стоит и почему это считается одним и самых плохих стилей программирования, наряду с:

Пока...Цикл
 прервать;
КонецЦикла;

Страуструп - авторитет, не так ли?
Смотрим в той же главе 6, параграф 6.1 - A Desk Calculator. В частности, в #6.1.5 видим:

With all the pieces of the program in place, we need only a driver to start things. In this simple example, main () can do that:
int main()
{
table ["pi"] = 3.1415926535897932385 ; // insert predefined names
table ["e"] = 2.7182818284590452354 ;

while (cin ) {
 get_token();

 if (curr_tok == END) break;
 if (curr_tok == PRINT) continue;
 cout << expr(false) << ?\ n ?;
 }
return no_of_errors;
}

Сам авторитет использует break? К чему бы это?

(77) "Может быть полезным" - по отношению к автогенерации кода. "gotos can be used in a parser generated from a grammar by a parser generator."

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

Ко второй части: объем кода - читается одним глазом. В данном случае использование дополнительных if(){} привело бы к нечитаемости.
К тому же - это пример для совсем другого случая.

(33) бред.
тебе Ромикс уже ответил почему.

(70)  Вкуриваешь как?

Инд=1;
Пока Инд<МассивСтрок.Количество() и флПродолжать Цикл

(80) и ты хочешь сказать что это лутше чем    Прервать;   ?

(81) зачем там вообще прервать??

Флажки это прикольно.. но когда их много

(78)
>> Могу прислать ту же книгу в переводе - будет сочетание презираемый :)

Зачем? Я вполне допускаю, что в переводе написано именно так... Пусть это останется на совести переводчиков...

>> смотри чуть ниже комментарий после кода, приведенного во второй части

Смотрел, конечно, из этого комментария следует лишь то, что continue можно рассматривать как частный случай оператора goto применительно к циклу... В общем случае называть continue АНАЛОГОМ goto некорректно...

>> И где же шире? Выход из вложенных циклов, экстремальная скорость и автогенерация - всё.

В посте (58) ни слова про экстремальную скорость, поэтому шире... :-)

>> К тому же - это пример для совсем другого случая.

Не совсем понял для какого такого другого... Если нетрудно - поясни...

(84) Данный участок посвящен разработке учебного приложения, если посмотреть на ф-ции Term и Prim, приводимые в начале главы - можно еще и не такое увидеть, в частности выход из функции через return посередине. В главе Комментарии и расположение текста (не знаю, как в ориг называется) в середине сказано "Это одна из многих причин, почему учебная программа отличается от настоящей".

ЗЫ. Небольшой такой итог: Прервать и Продолжить - можно использовать, но в случаях  когда возможно иное построение (не в ущерб читаемости) - стоит изменить архитектуру.
Вызов Возврат из функции - в случае небольшого текста (до 10 строк) - оправдан, но в случае большого количества стоит пересмотреть архитектуру - иначе возникнут сложности с отладкой и пониманием работы в дальнейшем.

ребеночка из (0) с водою выплеснули, эх...

недавно читал Войну и мир.
Без знания франчузского напрягает...