На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (37) « Первая ... 35 36 [37]   ( Перейти к последнему сообщению )  
> C vs C++ , Не опять а снова
    Цитата D_KEY @
    OpenGL, наверное можно было не прямые цитаты давать, а отвечать на посты Кили его же постами

    Я бы так и сделал, если бы нашёл ту тему вовремя :)
      Цитата JoeUser @
      Локально - это естественно, глобально - дичь.
      Т.е. по-твоему в бизнес-логике отказ – неважно, по причине ошибки или какой-либо другой – от исполнения части этой логики не может быть заложен масштабнее, чем на одну, самую малую, единицу декомпозиции? Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке. Среди которых объект интерфейса по UART, имеющий ещё три объекта-нитки приёма-передачи, объект-логгер, связанный ещё с двумя объектами-журналами в файл и консоль, и восемь десятков – приблизительно, хрен их там знает, сколько понадобится – OLE-проксей к внешним приложениям Оффиса, представляющим документы, параграфы, списки, стили, таблицы, книги, листы/ячейки/колонки и сами приложения, а также десяток std::коллекций с инфой оттуда и туда, а ещё сикось-накось связанной с тудой и оттудовой. Очень интересно посмотреть хотя бы на по-Дейкстровски структурные блок-схемки и формальные протоколы взаимодействия отдельных компонент, а уж как это будет реализовано без нелокального управления потоком исполнения я, так и быть, сам попытаюсь представить. Потом сходим в холивар по goto, где я ничего нового уже не напишу.
        Цитата applegame @
        Просто ты тогда спорил с аргументами в точности совпадающими с теми, которые приводишь сейчас. Это и правда смешно.

        Где, покажи где я спорил с аргументами, в точности совпадающими с теми? Там спор был исключения vs коды возврата. Тут я не спорил против исключений, или за коды возврата, я доказывал одну простую вещь: Что понять какие исключения может кидать функция - сложнее, чем понять, какие коды возврата она может возвращать. Вот и все. Я даже для упоротых написал, причем неоднократно:
        Цитата Wound @
        Я нигде не пишу что коды возврата хуже или лучше исключений. Мне вообще фиолетово, я использую и то и другое. Просто OpenGL написал что "ПОмнить какие исключения кидает функция так же просто, как и помнить какие ошибки при кодах возврата она возвращает". Я с ним не согласился. Причем писал он это тебе, на что ты ему вроде тоже возражал. А дальше тема перешла в нечто другое.



        Цитата D_KEY @
        OpenGL, наверное можно было не прямые цитаты давать, а отвечать на посты Кили его же постами :)

        Но вообще если серьезно, то времени не так и мало прошло, человек мог поменять мнение.

        :facepalm:
        https://www.youtube.com/watch?v=WdnEx13C904
        Сообщение отредактировано: Wound -
          Цитата Qraizer @
          Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке.

          Надо сказать "спасибо", что нынешняя реализация в С++ есть! Ты прикинь, что нужно было бы реализовать в плане глобальных откатов. Компилятор должен был бы перечислить и реализовать все состояния в созданных экземпляров классов, и более того организовать оптимальную последовательность их разрушения. Да, разрушить "ветку дерева" подчиненных экземпляров - более-менее понятно и осуществимо. А вот вопрос разрушения ветки в произвольной точке созданной иерархии ... я бы сказал ... неоднозначно. Формально пробежать дерево можно, но на сколько это будет правильно, и функционально осуществимо - большой большой вопрос.

          А теперь ответы:

          Цитата Qraizer @
          Т.е. по-твоему в бизнес-логике отказ – неважно, по причине ошибки или какой-либо другой – от исполнения части этой логики не может быть заложен масштабнее, чем на одну, самую малую, единицу декомпозиции?

          Я так не считаю. Я считаю, что любая программа должна описываться формально состояниями. Если параметров, влияющих на состояния, мало - тупо таблицей. Если параметров заметно много, и мы получаем отчетливую разряженную матрицу - тогда просто вектором состояний. Таким образом, ежели мы говорим о "единице компиляции", мы или ошибаемся в архитектуре, или не ошибаемся и соотносим ошибку в нашу созданную мат.модель создаваемой программы. А вот уже там должны и обязаны быть предусмотрены обработчики "ошибочных" состояний. Это ИМХО.

          Цитата Qraizer @
          Ок, тогда расскажи, как будешь реагировать на ESC пользователя, откатывая рабочий цикл с сотней объектов на стеке.

          Нуууу .... тут нужна детализация ТЗ. Задача задана нечетко! Про написанное я бы наверное - запрограммил сериализацию. Запомнил всю последовательность объектов и их сортировку, запомнил бы текущий элемент. А вот на реакцию на ESC - вопрос отдельный! Это ПАУЗА или ЗАВЕРШЕНИЕ или ПОФИК - это и обрабатываем. Плохой пример, ибо еще варианты и условия есть.

          Цитата Qraizer @
          Среди которых объект интерфейса по UART, имеющий ещё три объекта-нитки приёма-передачи, объект-логгер, связанный ещё с двумя объектами-журналами в файл и консоль, и восемь десятков – приблизительно, хрен их там знает, сколько понадобится – OLE-проксей к внешним приложениям Оффиса, представляющим документы, параграфы, списки, стили, таблицы, книги, листы/ячейки/колонки и сами приложения, а также десяток std::коллекций с инфой оттуда и туда, а ещё сикось-накось связанной с тудой и оттудовой.

          Дружище, теряю нить.
          Ты люто меня запугал структурой, и мне уже страшно!!! Однако ... у нас есть две соперничающие методики постройки систем:
          1) Дерево
          2)Сеть
          С первым - проблем нет вааще, полностью! И пофик твои страшили, ибо они последовательны и в своем ранге практически независимы. А вот со второй архитектурой возможны проблемсы, и я ее боюсь и всеми средствами стараюсь избежать всегда. Даже в ущерб усложнения! Там сложность состояний задирается на порядки порядков.

          Цитата Qraizer @
          Очень интересно посмотреть хотя бы на по-Дейкстровски структурные блок-схемки и формальные протоколы взаимодействия отдельных компонент, а уж как это будет реализовано без нелокального управления потоком исполнения я, так и быть, сам попытаюсь представить. Потом сходим в холивар по goto, где я ничего нового уже не напишу

          Я сломал моск :'(

          Я много прослушал различных супер-лекций по программному-проектированию, но они все и рядом не стояли с моим, увы покойным, зав.лабом Римским Генадием Васильевичем, профессором, доктором технических наук некогда Академии Наук БССР. А он говорил, что сложные задачи решать просто: декомпозиция-анализ-тесты-композиция ... и вы в шоколаде! Мой же опыт подсказывает - "собирай дерево", влезешь "в сеть" - запаришься кувыркаться в дебаге.

          Qraizer, надеюсь ты меня понял. Ибо все твои вопросы - какие-то эфемерно-нечеткие, хочется поговорить - но надо сперва осознать тему на 100%.
            Цитата JoeUser @
            Ты прикинь, что нужно было бы реализовать в плане глобальных откатов. Компилятор должен был бы перечислить и реализовать все состояния в созданных экземпляров классов, и более того организовать оптимальную последовательность их разрушения. Да, разрушить "ветку дерева" подчиненных экземпляров - более-менее понятно и осуществимо. А вот вопрос разрушения ветки в произвольной точке созданной иерархии ... я бы сказал ... неоднозначно. Формально пробежать дерево можно, но на сколько это будет правильно, и функционально осуществимо - большой большой вопрос.
            Та легко. Во-первых, Стандарт обязывает, и любой компилер это реализует, куда денется. Во-вторых, в рассказе про SEH я показал, как это делается просто с точки зрения ABI и легковесно с точки зрения производительности. При условии отсутствия исключений, конечно, при размотке стека производительность естественно проседает, но не запредельно, руками подобный код ты смог бы оптимизировать, но только если конкретно под каждый случай.
              Цитата 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 минут гонялись тесты) на если бы без автоматизации.
              Теперь самое интересное.
              • Функциональностей – 8. Похожих, но не аналогичных.
              • Процессоров – 4. По два на каждую четвёрку функциональностей. Итого каждая четвёрка функциональностей исполняется на двух процессорах. Часть, очень небольшая, но она есть, элементов функциональностей капельку отличается на своих двух процессорах, соответственно небольшая часть тестов уникальна для процессора, но основная представлены в одном экземпляре. Всё это вносит сумятицу в наименования артефактов и связи между ними.
              • Процессоры не x86. Три разных PPC и один ARM. Они представлены в виде минималистичных плат, которые в "боевом" режиме вставляются в большой модуль, а уже он подключается к интеграционному испытательному стенду. Но у нас они просто лежат на столе и подключаются по UART к ПК, эдакому испытательному мини-стенду. Тесты могут гоняться параллельно сразу на четырёх, но естественно каждый процессор одновременно может исполнять только один тест.
              • Соответственно матрица трассировки оказывается довольно непростой. Трассировка System Level на High Level и обратно. Трассировка High Level на Low Level и обратно с учётом функциональностей. Трассировка Low Level на код и обратно с учётом процессора. Трассировка тестовых примеров на Low Level и обратно с учётом функциональностей и процессора.
              Вот теперь можно легко представить, что творится на RFS. Получаются данные из SVN. Из тестов формируются пакеты RFS сообразно функциональностям и процессорам. Каждый тест компилируется, собирается и отправляется на исполнение на соответствующую железку. Два раза, чтобы получить ещё и покрытие. По RS232-му заливается исполняемый образ теста, взаимодействуя с его начальным загрузчиком, по нему же оттуда обратно получаются репорты. По каждой железке как минимум нужен асинхронный приём + простенький GUI на непредвиденные случаи + управление. Тесты для отчётности нужно ещё нарезать на тестовые примеры и идентификационную инфу, параллельно собирая отчётные документы. Результаты выкладываются в SVN.
              На этом маршруте многое может пойти не так. Например, тест упадёт из-за незамеченного автором/ревьюером UB, документ требований окажется с нарушениями структуры, у теста окажется кривая идентификация, у функциональностей будут неверные TraceID итд итп ипр. Все действия утилиточка логгирует, чтобы в реальном времени был виден прогресс и что/где, если вдруг, не так. На консоль сразу и в файлик для истории. В файлик ещё и логгирование подетальнее. Захотеть нажать ESC может оказаться по разными причинам. Взаимодействие с MSоффисом идёт через OLE Automation, и в случае чего все OLE-объекты останутся висеть, т.к. находятся в другом процессе, а документы останутся занятыми безоконными приложениями Офиса.

              Не устал осмысливать, JoeUser? Теперь инфы достаточно?
              Сообщение отредактировано: Qraizer -
                Цитата Qraizer @
                Теперь инфы достаточно?

                Читаю :wacko:
                  :wall:
                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                  0 пользователей:
                  Страницы: (37) « Первая ... 35 36 [37] 


                  Рейтинг@Mail.ru
                  [ Script execution time: 0,0600 ]   [ 16 queries used ]   [ Generated: 28.03.24, 18:46 GMT ]