if или assert - контроль ошибок в программе

[Vladiger]

Тут уже была подобная тема if && assert но она уже закрыта, а вопросы остались.

При написании программы, каждый программист старается учитывать нестандартные ситуации и делает проверки на ошибки. Контролировать возникновение ошибок можно по разному, например так:
1) if (hWnd == NULL) return E_ABORT;
2) assert(hWnd == NULL);

Известно что:

Макрос assert(), определенный в заголовке <assert.h>, записывает информацию об ошибке в поток stderr, а затем прекращает выполнение программы, если выражение ехр равно нулю. В противном случае макрос assert() никаких действий не выполняет.

но это только в Debug конфигурации, т.е. при отладке.
Если скомпилировать программу в конфигурации Release, то assert() не прекращает выполнение программы, а тупо игнорирует выражение true и проскакивает, что может приподнести неожиданные сюрпризы.
Получается так, что при написание большого проекта, мы можем утыкать его ассертами, при этом отладить и всё будет работать. Но когда скомпилируем уже готовый проект в конфигурации Release, то там тоже все будет работать, но мысль о том что, работа программы, в которой все ассерты будут игнорированы, приравнивается к мыслям о танцах на пороховой бочке.

Мне интересно, для чего вообще нужен assert?
Как assert компилируется в коде в Release конфигурации?
Есть ли какие то приемущества assert перед if в плане оптимизации программы?

[pproger]

Мне интересно, для чего вообще нужен assert?

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

Как assert компилируется в коде в Release конфигурации?

никак. нет его в релизе. если в релизе программа упадет, значит в месте падения код недостаточно отлажен/недостаточно покрыт тестами. нужно возвращаться в дебаг режим и дорабатывать.

в общем, в ассерты помещаются выражения, которые ни при каких условиях не должны быть ложными.

[Nuklon]

Как assert компилируется в коде в Release конфигурации?

при Release(NDEBUG) дефайн assert вставляет тупо ((void)0) то есть ничего и конечно никакого завершение не будет.

Мне интересно, для чего вообще нужен assert?

Ну чтобы хотя бы посмотреть на какой строчке __LINE__ и в каком файле __FILE__ проcигналил assert, да и вообще удобно не надо ручками "подтирать" после _DEBUG-отладочного режима...

Есть ли какие то приемущества assert перед If в плане оптимизации программы?

Конечно есть assert это дефайн который в Release порождает пустоту, а if команда которая будет исполнятся процессором. Вообще-то это разное понятие сравнивать assert с if, assert только к отладочному режиму имеет дело, тут скорее проверку на ошибку if надо сравнивать с исключениями(try {} catch{}), что лучше и т.п.

[SaLoKiN]

Мне интересно, для чего вообще нужен assert?

Имхо.ASSERT нужен для отловки ошибок на стадии разработки.

Как assert компилируется в коде в Release конфигурации?

ASSERT из релиза убирается

Есть ли какие то приемущества assert перед if в плане оптимизации программы?

Наверно такое не сравнивают... но If срабатывает везде, ASSERT на стадии разработки.

[Vladiger]

assert это дефайн который в Release порождает пустоту, а if команда которая будет исполнятся процессором

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

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

То есть для оптимизации работы всей программы, нужно ещё и задумываться где ассерты уместны, а где нет.

Спасибо! Суть понятна!

[Igor95]

Оператор мог его по неосторожности удалить

как это так?

[still_alive]

Есть еще замечательная вещь static_assert - проверка утверждений на этапе компиляции.

[Vladiger]

Сообщение от Igor95

Оператор мог его по неосторожности удалить

как это так?

Нажатием на клавиатуре клавиши Delete.
Вопрос не в том как он его удалил и зачем, а в том что такая ситуация возможна и приложение не должно заканчиваться крешем. Программный контроль такой ситуации должен как минимум культурненько так вывести в месэдж-бокс что то типа "ERROR: File name not found".

[Igor95]

Так не оператор, а программист.

[Vladiger]

Что то мы либо друг друга не понимаем, либо Вы не понимаете причину возникновения такой ситуации...

Моя программа использует для своей работы куча всяких всяких файлов: - config.ini, image.jpg, font.ttf и.т.д и.т.п которые находятся каждый на своем месте и распределены по каталогам. Оператор залез в один из каталогов и грохнул файл config.ini, ну прост поглядеть что будет.

Программист то при чем? Он не может программно запретить оператору удалять файлы на своем компе. А вот контролировать их ниличие во время выполнения программы - запросто!

Вот я о чем, на примере:

FILE* hFile = fopen("config.ini", "r");
assert(hFile == NULL);

В дебаг конфигурации отсутствие файла config.ini приведет к прекращению процесса, а в релизе скорее всего к крэшу.