Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.226.222.12] |
|
Страницы: (37) « Первая ... 35 36 [37] ( Перейти к последнему сообщению ) |
Сообщ.
#541
,
|
|
|
Цитата D_KEY @ OpenGL, наверное можно было не прямые цитаты давать, а отвечать на посты Кили его же постами Я бы так и сделал, если бы нашёл ту тему вовремя |
Сообщ.
#542
,
|
|
|
Т.е. по-твоему в бизнес-логике отказ – неважно, по причине ошибки или какой-либо другой – от исполнения части этой логики не может быть заложен масштабнее, чем на одну, самую малую, единицу декомпозиции? Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке. Среди которых объект интерфейса по UART, имеющий ещё три объекта-нитки приёма-передачи, объект-логгер, связанный ещё с двумя объектами-журналами в файл и консоль, и восемь десятков – приблизительно, хрен их там знает, сколько понадобится – OLE-проксей к внешним приложениям Оффиса, представляющим документы, параграфы, списки, стили, таблицы, книги, листы/ячейки/колонки и сами приложения, а также десяток std::коллекций с инфой оттуда и туда, а ещё сикось-накось связанной с тудой и оттудовой. Очень интересно посмотреть хотя бы на по-Дейкстровски структурные блок-схемки и формальные протоколы взаимодействия отдельных компонент, а уж как это будет реализовано без нелокального управления потоком исполнения я, так и быть, сам попытаюсь представить. Потом сходим в холивар по goto, где я ничего нового уже не напишу.
|
Сообщ.
#543
,
|
|
|
Цитата applegame @ Просто ты тогда спорил с аргументами в точности совпадающими с теми, которые приводишь сейчас. Это и правда смешно. Где, покажи где я спорил с аргументами, в точности совпадающими с теми? Там спор был исключения vs коды возврата. Тут я не спорил против исключений, или за коды возврата, я доказывал одну простую вещь: Что понять какие исключения может кидать функция - сложнее, чем понять, какие коды возврата она может возвращать. Вот и все. Я даже для упоротых написал, причем неоднократно: Цитата Wound @ Я нигде не пишу что коды возврата хуже или лучше исключений. Мне вообще фиолетово, я использую и то и другое. Просто OpenGL написал что "ПОмнить какие исключения кидает функция так же просто, как и помнить какие ошибки при кодах возврата она возвращает". Я с ним не согласился. Причем писал он это тебе, на что ты ему вроде тоже возражал. А дальше тема перешла в нечто другое. Цитата D_KEY @ OpenGL, наверное можно было не прямые цитаты давать, а отвечать на посты Кили его же постами Но вообще если серьезно, то времени не так и мало прошло, человек мог поменять мнение. https://www.youtube.com/watch?v=WdnEx13C904 |
Сообщ.
#544
,
|
|
|
Цитата Qraizer @ Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке. Надо сказать "спасибо", что нынешняя реализация в С++ есть! Ты прикинь, что нужно было бы реализовать в плане глобальных откатов. Компилятор должен был бы перечислить и реализовать все состояния в созданных экземпляров классов, и более того организовать оптимальную последовательность их разрушения. Да, разрушить "ветку дерева" подчиненных экземпляров - более-менее понятно и осуществимо. А вот вопрос разрушения ветки в произвольной точке созданной иерархии ... я бы сказал ... неоднозначно. Формально пробежать дерево можно, но на сколько это будет правильно, и функционально осуществимо - большой большой вопрос. А теперь ответы: Цитата Qraizer @ Т.е. по-твоему в бизнес-логике отказ – неважно, по причине ошибки или какой-либо другой – от исполнения части этой логики не может быть заложен масштабнее, чем на одну, самую малую, единицу декомпозиции? Я так не считаю. Я считаю, что любая программа должна описываться формально состояниями. Если параметров, влияющих на состояния, мало - тупо таблицей. Если параметров заметно много, и мы получаем отчетливую разряженную матрицу - тогда просто вектором состояний. Таким образом, ежели мы говорим о "единице компиляции", мы или ошибаемся в архитектуре, или не ошибаемся и соотносим ошибку в нашу созданную мат.модель создаваемой программы. А вот уже там должны и обязаны быть предусмотрены обработчики "ошибочных" состояний. Это ИМХО. Цитата Qraizer @ Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке. Нуууу .... тут нужна детализация ТЗ. Задача задана нечетко! Про написанное я бы наверное - запрограммил сериализацию. Запомнил всю последовательность объектов и их сортировку, запомнил бы текущий элемент. А вот на реакцию на ESC - вопрос отдельный! Это ПАУЗА или ЗАВЕРШЕНИЕ или ПОФИК - это и обрабатываем. Плохой пример, ибо еще варианты и условия есть. Цитата Qraizer @ Среди которых объект интерфейса по UART, имеющий ещё три объекта-нитки приёма-передачи, объект-логгер, связанный ещё с двумя объектами-журналами в файл и консоль, и восемь десятков – приблизительно, хрен их там знает, сколько понадобится – OLE-проксей к внешним приложениям Оффиса, представляющим документы, параграфы, списки, стили, таблицы, книги, листы/ячейки/колонки и сами приложения, а также десяток std::коллекций с инфой оттуда и туда, а ещё сикось-накось связанной с тудой и оттудовой. Дружище, теряю нить. Ты люто меня запугал структурой, и мне уже страшно!!! Однако ... у нас есть две соперничающие методики постройки систем: 1) Дерево 2)Сеть С первым - проблем нет вааще, полностью! И пофик твои страшили, ибо они последовательны и в своем ранге практически независимы. А вот со второй архитектурой возможны проблемсы, и я ее боюсь и всеми средствами стараюсь избежать всегда. Даже в ущерб усложнения! Там сложность состояний задирается на порядки порядков. Цитата Qraizer @ Очень интересно посмотреть хотя бы на по-Дейкстровски структурные блок-схемки и формальные протоколы взаимодействия отдельных компонент, а уж как это будет реализовано без нелокального управления потоком исполнения я, так и быть, сам попытаюсь представить. Потом сходим в холивар по goto, где я ничего нового уже не напишу Я сломал моск Я много прослушал различных супер-лекций по программному-проектированию, но они все и рядом не стояли с моим, увы покойным, зав.лабом Римским Генадием Васильевичем, профессором, доктором технических наук некогда Академии Наук БССР. А он говорил, что сложные задачи решать просто: декомпозиция-анализ-тесты-композиция ... и вы в шоколаде! Мой же опыт подсказывает - "собирай дерево", влезешь "в сеть" - запаришься кувыркаться в дебаге. Qraizer, надеюсь ты меня понял. Ибо все твои вопросы - какие-то эфемерно-нечеткие, хочется поговорить - но надо сперва осознать тему на 100%. |
Сообщ.
#545
,
|
|
|
Цитата JoeUser @ Та легко. Во-первых, Стандарт обязывает, и любой компилер это реализует, куда денется. Во-вторых, в рассказе про SEH я показал, как это делается просто с точки зрения ABI и легковесно с точки зрения производительности. При условии отсутствия исключений, конечно, при размотке стека производительность естественно проседает, но не запредельно, руками подобный код ты смог бы оптимизировать, но только если конкретно под каждый случай. Ты прикинь, что нужно было бы реализовать в плане глобальных откатов. Компилятор должен был бы перечислить и реализовать все состояния в созданных экземпляров классов, и более того организовать оптимальную последовательность их разрушения. Да, разрушить "ветку дерева" подчиненных экземпляров - более-менее понятно и осуществимо. А вот вопрос разрушения ветки в произвольной точке созданной иерархии ... я бы сказал ... неоднозначно. Формально пробежать дерево можно, но на сколько это будет правильно, и функционально осуществимо - большой большой вопрос. |
Сообщ.
#546
,
|
|
|
Цитата JoeUser @ Понял. Не понял, зачем. Систему-то представить можно. Ну раз ты просишь...Qraizer, надеюсь ты меня понял. Ибо все твои вопросы - какие-то эфемерно-нечеткие, хочется поговорить - но надо сперва осознать тему на 100%. Есть функциональность, обладающая определёнными правилами входы=>выходы, полностью алгоритмически формализуемыми. Она полностью описана требованиями в плане её поведения. Представлены в виде документов html и MSWord. Есть код, потенциально реализующий эти требования. Есть тесты, выполняющие разработанные по требованиям тестовые примеры на коде, их реализующем. В них каждый отдельный элемент поведения имеет соответствующий чётко определённый набор тестовых примеров, проверяющие этот элемент. Каждый такой пример имеет описание и реализацию. В каждом тесте тестируемых элементов может быть много, всё зависит от вида самих требований и их декомпозиции в независимые комбинации поведенческих наборов элементов. Каждый тест прошёл процедуру ревью и принят после устранения выявленных в них недостатков. Выполняемые тестовые примеры также могут – и делают это – выявлять несоответствие между описанным поведением и реализованным. На каждый такой случай открывается СП (Сообщение о Проблеме). Тесты исполняются дважды, на "боевом" коде и инструментированном. Последний нужен для сбора структурного покрытия с целью дальнейшего анализа покрытия кода тестами, кодом требований и тестом требований. Уровень MC/DC, но это неважно. Двойное исполнение требуется, чтобы показать отсутствие изменений в поведении инструментированного кода от "боевого", т.е. оба прогона должны выдать строго одинаковые отчёты. По окончанию цикла разработки тестов требуется сформировать файлы исходных данных и результатов процедуры верификации, в которых в удобной форме конспективно будет суммировано всё и оставлены ссылки на полные результаты, со всеми деталями. Для этого выполняется процедура RFS (Ready For SCC — Structural Coverage Collecting; предшествует SCA — Structural Coverage Analyzing). Это значит, что то, что делали авторы и ревьюеры тестов по отдельности для каждого, теперь выполняется всё скопом, для всех тестов по этой конкретной функциональности. При этом собирается итоговое покрытие, теоретически долженствующие быть 100% по всей функциональности, а результаты должны совпадать с ранее полученными авторами этих тестов. По результатам нужно сгенерировать файлы в формате MSWord и MSExcel: Очень много рутинной и хорошо формализуемой работы. Руками она делается в ~200 человеко-часов. Сужу по объёму данных, который был обработан на рубеже июля-августа сего года. Примерно сравнил время, потраченное на аналогичную работу по другому проекту руками, когда никакой автоматизации ещё не было, и с помощью упомянутой всуе утилиточки за авторством Вашего покорного слуги, экстраполировав фактически затраченное время (1 рабочий день, из которых 7 часов и 48 минут гонялись тесты) на если бы без автоматизации. Теперь самое интересное. Вот теперь можно легко представить, что творится на RFS. Получаются данные из SVN. Из тестов формируются пакеты RFS сообразно функциональностям и процессорам. Каждый тест компилируется, собирается и отправляется на исполнение на соответствующую железку. Два раза, чтобы получить ещё и покрытие. По RS232-му заливается исполняемый образ теста, взаимодействуя с его начальным загрузчиком, по нему же оттуда обратно получаются репорты. По каждой железке как минимум нужен асинхронный приём + простенький GUI на непредвиденные случаи + управление. Тесты для отчётности нужно ещё нарезать на тестовые примеры и идентификационную инфу, параллельно собирая отчётные документы. Результаты выкладываются в SVN. На этом маршруте многое может пойти не так. Например, тест упадёт из-за незамеченного автором/ревьюером UB, документ требований окажется с нарушениями структуры, у теста окажется кривая идентификация, у функциональностей будут неверные TraceID итд итп ипр. Все действия утилиточка логгирует, чтобы в реальном времени был виден прогресс и что/где, если вдруг, не так. На консоль сразу и в файлик для истории. В файлик ещё и логгирование подетальнее. Захотеть нажать ESC может оказаться по разными причинам. Взаимодействие с MSоффисом идёт через OLE Automation, и в случае чего все OLE-объекты останутся висеть, т.к. находятся в другом процессе, а документы останутся занятыми безоконными приложениями Офиса. Не устал осмысливать, JoeUser? Теперь инфы достаточно? |
Сообщ.
#547
,
|
|
|
Цитата Qraizer @ Теперь инфы достаточно? Читаю |
Сообщ.
#548
,
|
|
|
|