Код завален утверждениями

Question

Код завален утверждениями

0

Привет, я программирую на каком-то устройстве. Существует пример с таким кодом:

Verify(SomeFunc(argc, argv) == SDK_OK);

Verify(SomeOtherFunction(&st_initialData) == SDK_OK);

Verify(SomeOtherFunction2(x,y) == SDK_OK);

В doc Verify определяется как "аналогичный" для утверждения.

Мой вопрос: если я создам свой проект в режиме Release, что произойдет с вышеприведенными утверждениями? Потеряют ли они свою власть? Будет ли Verify иметь эффект?

Чтобы избежать возможных проблем с выше, мне придется заменить выше коды с проверкой возвращаемых значений следующим образом?:

if(SomeFunc(argc, argv) == SDK_OK)
{
// we are fine
}
else
{
// handle error somehow, such that it is also available in Release mode
}

Zdeslav Vojkovic 21 окт. 2013, в 10:55

Источник

Теги:

c++

c

3 ответа

Ещё вопросы

Zdeslav Vojkovic · Answer 1 · 2013-10-21T06-45-00.000Z

1

Невозможно сказать, так как кажется, что именно ваш проект реализует Verify, как макрос или как функцию. Почему бы вам не взглянуть на реализацию?

При этом в MFC-инфраструктуре есть макрос VERIFY, аналогичный ASSERT, с тем отличием, что выражение всегда оценивается даже в сборке релиза, но ничего не делает, если результат выражения ложный. Это может быть аналогичный подход, так как ваши примеры, похоже, вызывают некоторые функции, которые могут повлиять на состояние системы.

Zdeslav Vojkovic 21 окт. 2013, в 06:45

0

Если MFC проверяет версию, которая НИЧЕГО не выполняет при сбое функции, то какая польза от этого? Тогда я думаю, что было бы лучше проверить коды возврата из функций вручную и завершиться с ошибкой, как я уже упоминал в своем вопросе, верно? (Я постараюсь найти больше информации об этом Verify в моем проекте)
user2793162 21 окт. 2013, в 08:47
0

@dmcr_code Причина утверждений (или что-то в этом духе) состоит в том, что код сильно терпит неудачу во время тестирования на малейшее несоответствие, в то время как он пытается продолжать работать в производстве. Смысл этого в том, что тихая ошибка считается лучше, чем сбой в производственной среде. Является ли это хорошим подходом, является материалом для длительной дискуссии. В конце концов, это зависит от того, насколько важно, чтобы приложение работало точно, и насколько оно плохо в случае сбоя. Эти приоритеты должны быть взвешены друг против друга для каждого проекта.
Philipp 21 окт. 2013, в 09:00
0

@dmcr_code Это полезно, когда вам нужно вызвать функцию, сбой которой не должен произойти - вам нужно, чтобы функция всегда выполнялась, и вы хотите утверждать, что она не дает сбоя.
Angew 21 окт. 2013, в 09:01
0

Я вижу, что verify в MFC похоже на то, что он всегда выполняет метод внутри него, но не проверяет коды возврата. Утверждение в выпуске не может выполнить то, что внутри правильно? Как тогда люди проверяют ошибки в сборках Release?
user2793162 21 окт. 2013, в 09:04
0

@dmcr_code С шаблоном verify возможно, что build-build регистрирует любые неудачные проверки, чтобы их можно было проанализировать позже. Пожалуйста, не спрашивайте, если ваша реализация Verify делает это, потому что никто за пределами вашей организации не может ответить на это.
Philipp 21 окт. 2013, в 09:10

Показать ещё 3 комментария

cdoubleplusgood · Answer 2 · 2013-10-21T07-35-00.000Z

Я предполагаю, что вы имеете в виду макрос MFC VERIFY или что-то очень похожее.
Использование этого макроса безопасно для сборки релизов. Аргумент выполняется в любом случае, только сам макрос ничего не делает в выпуске.
В отличие от этого макрос ASSERT полностью пропускается в сборках релизов, поэтому "побочных эффектов" аргумента не происходит. Поэтому VERIFY используется, если аргумент необходим для фактического потока программы, и ASSERT используется, когда аргумент предназначен только для утверждения.

Jens Gustedt · Answer 3 · 2013-10-21T06-05-00.000Z

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