Блокирование функций на моделированиях
Используйте подзапрос, чтобы получить этот результат
select SALES_PERSON,
IFNULL(( select SUM(SALES_TOTAL) from SALES where SALES_DATE = '2019-01-17' and SALES_PERSON = sal.SALES_PERSON ),0) as TODAY_SALES,
IFNULL(( select SUM(SALES_TOTAL) from SALES where MONTH(SALES_DATE)='01' and SALES_PERSON = sal.SALES_PERSON ),0) as MONTH_TO_DATE_SALES
from SALES as sal
group by SALES_PERSON
3 ответа
Я просто делаю два файла ActualDriver.c и StubDriver.c, содержащим точно те же имена функций. Путем создания двух сборок, связывающих производственный код против различных объектов нет никаких конфликтов имен. Таким образом, производственный код не содержит тестирования или условного кода.
Как Gerhard сказал, используйте общий заголовочный файл "driver.h" и файлы реализации слоя отдельного оборудования, содержащие фактические и заблокированные функции.
В затмении у меня есть две цели, и я "исключаю из сборки" driver.c файл, который не должен использоваться и удостовериться, что надлежащий включен в сборку. Eclipse затем генерирует make-файл во время изготовления.
Другая проблема для указания должна гарантировать определение целых чисел фиксированного размера, таким образом, код ведет себя то же с водосливной точки зрения. (Хотя из Вашего примера кода I видят, что Вы делаете это.)
Я соглашаюсь с вышеупомянутым. Стандартное решение этого состоит в том, чтобы определить непрозрачный абстрактный набор вызовов функции, которые являются "драйвером" к hw и затем называют это в основной программе. Затем обеспечьте две различных реализации драйвера, один для hw, один для коротковолнового. Коротковолновый вариант моделирует эффект IO hw некоторым соответствующим способом.
Обратите внимание, что, если цель на более низком уровне, т.е. написание кода, где каждый аппаратный доступ должен быть моделирован, а не целые функции, это могло бы быть немного tricker. Но здесь, различные функции "write_to_memory" и "read_from_memory" (или макросы, если скорость на цели важна) могли бы быть определены.
Нет никакой потребности или в случае, чтобы изменить имена функций, просто иметь два различных пакетных файла, make-файлы или в цели сборки IDE (в зависимости от того, какие инструменты Вы используете).
Наконец, во многих случаях лучшее техническое решение состоит в том, чтобы пойти для полноценного целевого системного средства моделирования, такого как Qemu, Simics, SystemC, Coware, VaST, или подобный. Это позволяет Вам выполнить тот же код все время, и вместо этого Вы создаете модель аппаратных средств, которые работают как фактические аппаратные средства с точки зрения программного обеспечения. Это действительно берет намного большие оплачиваемые авансом инвестиции, но для многих проектов это определенно стоит усилия. Это в основном избавляется от противной проблемы наличия различных сборок для цели и хоста, и удостоверяется, что Вы всегда используете свой кросс-компилятор с опциями сборки развертывания. Обратите внимание, что много встроенных пакетов компилятора идут с некоторыми основными, такая способность к моделированию встроила.