|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
29.10.2013, 12:20 | #1 | |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
if или assert - контроль ошибок в программе
Тут уже была подобная тема if && assert но она уже закрыта, а вопросы остались.
При написании программы, каждый программист старается учитывать нестандартные ситуации и делает проверки на ошибки. Контролировать возникновение ошибок можно по разному, например так: 1) if (hWnd == NULL) return E_ABORT; 2) assert(hWnd == NULL); Известно что: Цитата:
Если скомпилировать программу в конфигурации Release, то assert() не прекращает выполнение программы, а тупо игнорирует выражение true и проскакивает, что может приподнести неожиданные сюрпризы. Получается так, что при написание большого проекта, мы можем утыкать его ассертами, при этом отладить и всё будет работать. Но когда скомпилируем уже готовый проект в конфигурации Release, то там тоже все будет работать, но мысль о том что, работа программы, в которой все ассерты будут игнорированы, приравнивается к мыслям о танцах на пороховой бочке. Мне интересно, для чего вообще нужен assert? Как assert компилируется в коде в Release конфигурации? Есть ли какие то приемущества assert перед if в плане оптимизации программы? Последний раз редактировалось Vladiger; 29.10.2013 в 12:30. |
|
29.10.2013, 12:41 | #2 | ||
C++ hater
СтарожилДжуниор
Регистрация: 19.07.2009
Сообщений: 3,333
|
Цитата:
Цитата:
в общем, в ассерты помещаются выражения, которые ни при каких условиях не должны быть ложными.
I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. (c)Alan Kay
My other car is cdr. Q: Whats the object-oriented way to become wealthy? A: Inheritance Последний раз редактировалось pproger; 29.10.2013 в 12:48. |
||
29.10.2013, 12:54 | #3 | |||
Форумчанин
Регистрация: 05.04.2012
Сообщений: 134
|
Цитата:
Цитата:
Цитата:
|
|||
29.10.2013, 12:58 | #4 | |||
Форумчанин
Регистрация: 19.09.2013
Сообщений: 597
|
Цитата:
Цитата:
Цитата:
Сделал сам, помоги другому!
Что-то работает не так? Дебаггер в помощь!!! |
|||
29.10.2013, 13:19 | #5 | |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Цитата:
То есть на этапе разработки и отладки мы можем делать проверки на ошибки, которые могут возникать не по вине оператора, а по вине самого разработчика (выход за пределы массива, какие то пустые параметры передаваемые функциям где их быть не должно, и.т.д и.т.п). В дебаг конфигурации всё это можно отловить и отладить, а в релизе эти проверки совершенно излишни, стало быть разгружаем процессор, увеличиваем быстродействие. Другое дело проверка на наличие файла при попытке его прочитать (как пример). Оператор мог его по неосторожности удалить, либо переместить и тут обязательно должна быть проверка в любой конфигурации, без if не обойтись... То есть для оптимизации работы всей программы, нужно ещё и задумываться где ассерты уместны, а где нет. Спасибо! Суть понятна! |
|
29.10.2013, 16:14 | #6 |
Форумчанин
Регистрация: 03.01.2013
Сообщений: 388
|
Код:
|
29.10.2013, 16:27 | #7 |
Great Code Monkey
Форумчанин
Регистрация: 09.08.2007
Сообщений: 533
|
Есть еще замечательная вещь static_assert - проверка утверждений на этапе компиляции.
|
29.10.2013, 18:08 | #8 |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Нажатием на клавиатуре клавиши Delete.
Вопрос не в том как он его удалил и зачем, а в том что такая ситуация возможна и приложение не должно заканчиваться крешем. Программный контроль такой ситуации должен как минимум культурненько так вывести в месэдж-бокс что то типа "ERROR: File name not found". Последний раз редактировалось Vladiger; 29.10.2013 в 18:10. |
29.10.2013, 18:10 | #9 |
Форумчанин
Регистрация: 03.01.2013
Сообщений: 388
|
Так не оператор, а программист.
|
29.10.2013, 18:20 | #10 |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Что то мы либо друг друга не понимаем, либо Вы не понимаете причину возникновения такой ситуации...
Моя программа использует для своей работы куча всяких всяких файлов: - config.ini, image.jpg, font.ttf и.т.д и.т.п которые находятся каждый на своем месте и распределены по каталогам. Оператор залез в один из каталогов и грохнул файл config.ini, ну прост поглядеть что будет. Программист то при чем? Он не может программно запретить оператору удалять файлы на своем компе. А вот контролировать их ниличие во время выполнения программы - запросто! Вот я о чем, на примере: Код:
Последний раз редактировалось Vladiger; 29.10.2013 в 19:14. |
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Исправление ошибок в программе | Makson | Assembler - Ассемблер (FASM, MASM, WASM, NASM, GoASM, Gas, RosAsm, HLA) и не рекомендуем TASM | 0 | 04.12.2011 13:15 |
Try... except...end или обработка ошибок | who i | Работа с сетью в Delphi | 2 | 31.01.2011 14:09 |
самописный assert: проблема с утечкой памяти) | sashonk | Общие вопросы C/C++ | 2 | 26.04.2010 15:58 |
Контроль ввода данных в DBgrid(или Table?) Delphi | Студло | Помощь студентам | 8 | 11.02.2010 18:37 |