wxwidgets debug alert что это
wxWidgets Discussion Forum
Official forum for the wxWidgets Cross-Platform GUI Toolkit
Debug alert in Release? Why? Topic is solved
Debug alert in Release? Why?
Post by extreme001 » Tue Feb 28, 2012 2:08 pm
Got back to development with wxWidgets and created a small application i compiled and linked in Release-Version (MSVC10-Compiler and wx 2.93). Got a crash and a wxWidgets-Debug-Alert. why is it called debug-alert in Release-Version?
What could be the mistake? I’m using wx 2.93 and compiled it with the project-files provided in the download.
Thank you very much!!
Re: Debug alert in Release? Why?
Post by doublemax » Tue Feb 28, 2012 2:19 pm
That’s a new feature in wx 2.9.x, asserts are enabled in release mode by default. Bad decision IMHO.
If you don’t want this, you have to change a setting in setup.h and rebuild wxWidgets.
Re: Debug alert in Release? Why?
Post by Auria » Tue Feb 28, 2012 3:32 pm
Re: Debug alert in Release? Why?
Post by doublemax » Tue Feb 28, 2012 4:09 pm
Not in professional software development. The last thing i need is an error message popping up at a customer, that a) is totally meaningless to the user and b) is harmless in 99% of the cases.
That’s what debug versions are for.
Re: Debug alert in Release? Why?
Post by tuli » Tue Feb 28, 2012 6:06 pm
Re: Debug alert in Release? Why?
Post by extreme001 » Tue Feb 28, 2012 6:35 pm
Thanks! I totally agree. the Error-Message is not helpful for the customer. But why did they add a debug-error-message in a release-version? I want to make sure it’s understood correctly by you. I’m not running a debug-exe, i’m running a release-exe.
Thank you for your answers!
Re: Debug alert in Release? Why?
Post by Auria » Wed Feb 29, 2012 2:48 pm
Not in professional software development. The last thing i need is an error message popping up at a customer, that a) is totally meaningless to the user and b) is harmless in 99% of the cases.
That’s what debug versions are for.
Re: Debug alert in Release? Why?
Post by extreme001 » Wed Feb 29, 2012 3:49 pm
Re: Debug alert in Release? Why?
Post by doublemax » Wed Feb 29, 2012 4:30 pm
Re: Debug alert in Release? Why?
Post by PB » Wed Feb 29, 2012 4:45 pm
I just tried and wxASSERT does not produce any message nor is the expression inside the parenthesis evaluated in the Release mode (wxInfoMessageBox reports debug level = 1). wxWidgets 2.9.4 compiled with MSVC 2008 Express using default settings. I also couldn’t find any information about changing the assert behaviour in wxWidgets changelog; in section «Changes in behaviour not resulting in compilation errors» or elsewhere. wxWidgets docs also state that asserts are disabled in release builds.
jenyay.net
Софт, исходники и фото
Компиляция библиотеки wxWidgets в Code::Blocks
На мой взгляд для кроссплатформенной разработки на C++ в качестве среды разработки больше всего подходит Code::Blocks, с каждой версией этой IDE пользоваться становится все легче, и все лучше она работает «из коробки». В этой статье мы рассмотрим процесс компиляции библиотеки wxWidgets в этой среде.
На странице загрузки wxWidgets можно скачать уже скомпилированные объектные файлы для этой библиотеки, но иногда нужно самому скомпилировать библиотеку, например, если требуется задать какие-то параметры компиляции или скомпилировать каким-нибудь специфическим компилятором.
Компиляция библиотеки wxWidgets
0. Качаем Code::Blocks Главное скачать Code::Blocks с интегрированным mingw.
2. Установка переменной окружения PATH. Code::Blocks может использовать как сторонние компиляторы, так и интегрированный mingw (именно этот случай мы рассматриваем), который после установки будет располагаться в папке C:\Program Files (x86)\CodeBlocks\MinGW\. Чтобы было проще использовать этот компилятор, желательно добавить этот путь в переменную окружения PATH. В принципе, этого можно не делать, но тогда во многих случаях при работе с тем же компилятором из командной строки придется или указывать полный путь до компилятора, или добавлять его в ту же самую переменную при каждом сеансе работы. ИМХО, лучше установить эту переменную окружения сразу.
Для того, чтобы установить переменную окружения под Windows, нужно попасть в диалог «System Properties» (поскольку у меня англоязычная Windows, все названия я буду приводить на английском языке, думаю, что найти их русскоязычный аналог не составит труда). Этот диалог достаточно глубоко закопан, чтобы в него попасть под Windows 8.1, нажимаем правую кнопку мыши на кнопке Пуск, выбираем пункт меню System. Откроется следующее окно:
Слева выбираем пункт Advanced system settings и попадаем в диалог «System Properties». Затем на вкладке Advanced нажимаем кнопку Environment Variables
Откроется диалог «Environment Variables», в нижнем списке которого нужно найти переменную Path.
Значение этой переменной у вас будет скорее всего другое. Дважды щелкаем на эту переменную, и в открывшемся диалоге добавляем в конец через точку с запятой путь до запускаемых файлов mingw, т.е. в нашем случае до C:\Program Files (x86)\CodeBlocks\MinGW\bin\.
3. Качаем wxWidgets. Нужно скачать файл из раздела «Source Code», для простоты будем считать, что скачиваем архив с исходниками в формате zip или 7z.
4. Распаковываем архив с wxWidgets в какую-нибудь папку, например, в C:\Library\wxwidgets\.
5. Открываем командную строку с помощью команды cmd.
6. В архиве wxWidgets есть специальная папка («build\msw»), в которой хранятся файлы проекток для компиляции библиотеки под Windows с помощью различных сред. Переходим в эту папку с помощью команды
7. Если вы уже пытались (безуспешно) или с другими параметрами компилировать wxWidgets, то нужно предварительно удалить следы предыдущей компиляции. Разумеется, можно просто удалить папку с распакованными файлами библиотеки, а можно воспользоваться скриптом makefile. На самом деле удаление результатов компиляции с помощью makefile может быть полезно, если вы хотите заново перекомпилировать wxWidgets с каким-то определенным набором параметров, в то время как файлы, удачно скомпилированные с другими параметрами компиляции, оставить. Далее (в п. 8) мы будем компилировать библиотеку с использованием параметров USE_XRC=1 SHARED=1 MONOLITHIC=1 UNICODE=1 USE_OPENGL=1 BUILD=release, поэтому команда удаления должна иметь точно такие же параметры с добавлением команды clean в конце:
Если во время выполнения этой команды вы получите ошибку о том, что команда mingw32-make не найдена, значит, вы не добавили путь до этой команды в переменную окружения PATH (см. п. 2).
8. Осталось в той же папке C:\Library\wxwidgets\build\msw\ запустить компиляцию исходников библиотеки. Теперь мы должны выбрать, компилируем мы библиотеку как монолитную (с параметром компиляции MONOLITHIC=1), когда будет создана одна большая dll-ка, или не монолитную, когда различные пакеты будут собраны в отдельных dll-ках (с параметром компиляции MONOLITHIC=0).
Забегая вперед, вот результирующие файлы, после компиляции wxWidgets в монолитном режиме:
А вот список файлов при компиляции в разные dll-ки:
На странице вики wxWidgets рекомендуются такие параметры компиляции:
Библиотека инструментов wxWidgets. Сборка
Выдержка из Wiki: wxWidgets — это кросс-платформенная библиотека инструментов с открытым исходным кодом для разработки кроссплатформенных на уровне исходного кода приложений, в частности для построения графического интерфейса пользователя (GUI).
Библиотека имеет набор классов для работы с графическими изображениями, HTML, XML документами, архивами, файловыми системами, процессами, подсистемами печати, мультимедиа, сетями, классы для организации многопоточности, отладки, отправки дампов и множество других инструментов.
Совет: При установке каких либо программ, библиотек, распаковки пакетов и т.д., лучше всего использовать, в мастере установки программ, настройки (опции) по умолчанию. Поверьте, это вызовет намного меньше забот, и меньше плясок с бубном вокруг библиотек и программ. Это касается, библиотек, программ, и всевозможных компиляторов.
Настройка компилятора заключается в том, что необходимо добавить в системную переменную окружения Path, путь к бинарным сборкам компилятора, если этого не сделал мастер установки по умолчанию. Обычно это: C:\TDM-GCC-32\bin (если директорией установки (распаковки) был выбран корневой каталог диска C:\ ); 
Процесс сборки будет похож на этот скриншот:
FAQ, Note: The codeblocks-13.12mingw-setup.exe file includes the GCC compiler and GDB debugger from TDM-GCC (version 4.7.1, 32 bit). The codeblocks-13.12mingw-setup-TDM-GCC-481.exe file includes the TDM-GCC compiler, version 4.8.1, 32 bit. While v4.7.1 is rock-solid (we use it to compile C::B), v4.8.1 is provided for convenience, there are some known bugs with this version related to the compilation of Code::Blocks itself.
IF UNSURE, USE «codeblocks-13.12mingw-setup.exe»!
Примечание: Общее время компиляции занимает в среднем порядка 30-40 минут. Да-да, библиотека не такая уж и маленькая, имеет кучу классов.
Далее стандартная процедура, запускаем мастер установки, и устанавливаем программу с опциями по умолчанию.
должен быть такой код:
если необходимо редактируем.
Глобальные переменные проекта должны быть настроены следующим образом ( Settings—>Global variables ):
__GNUWIN32__
__WXMSW__
wxUSE_UNICODE
WX_PRECOMP
Окно Project build options ( wx_test ) [Вкладка Linker settings ]:
Окно Project build options ( Debug ) [Вкладка Linker settings ]:
Окно Project build options ( Release ) [Вкладка Linker settings ]:
Бывают и неприятности. Например линовка может выдавать следующую ошибку:
rem gcc_mswudll\monodll_xh_combo.o: file not recognized: Memory exhausted
rem collect2.exe: error: ld returned 1 exit status
rem mingw32-make.exe: *** [..\..\lib\gcc_dll\wxmsw28u_gcc.dll] Error 1
Проявляется на некоторых 32 битных платформах при компоновке монолитной динамической библиотеки из-за нехватки памяти. Из-за того, что линковщик собранный для x86 архитектуры, не может использовать адреса выше 2Гб, даже на x86_64 архитектуре. Поэтому смена компилятора обычно не помогает, перепробованы MinGW4.4.1TDM, всё семейство MinGW4.6.x, а также MinGW4.7.0, хотя в сети есть информация, что собирается под TDM-GCC 4.5.2 sjlj.
Также обойти проблему можно не используя монолитную сборку, или отказавшись от создания динамических библиотек для монолитной сборки, статические собираются без этой ошибки.
Решаются явным указанием стандарта при сборке библиотеки (добавление опции):
CXXFLAGS=»-std=gnu++11″
Upd1: вероятно в последних релизах MinGW баги пофиксили, теперь можно смело собирать при помощи указанного компилятора, соблюдая те же (описанные) правила.
p/s.
Пост ориентирован прежде всего на начинающую аудиторию программистов, и не в коем случае не претендует на истину в последней инстанции.
В следующих постах опишу как «правильно» собрать библиотеку компьютерного зрения OpenCV.
Настройка wxWidgets в Code::Blocks
Краткий справочник новичка по настройке wxWidgets с Code::Blocks в Windows [1]
Поддерживаемые компиляторы: MinGW или MSVC
При загрузке официального релиза Code::Blocks, есть возможность загрузки пакета, который включает в себя полный набор инструментов MinGW/GCC.
Содержание
Загрузка исходного кода wxWidgets [ править ]
wxWidgets распространяется в виде исходного кода, и необходимо скомпилировать его в библиотеку, прежде чем станет возможным использовать его в своих собственных программах.
Рекомендованная к использованию версия wxWidgets 2.8.12. Нажмите сюда, чтобы скачать исходные коды wxWidgets 2.8.12 для Windows (wxMSW-2.8.12-Setup.exe; 12.2 MB). Можно также зайти на страницу загрузки wxWidgets чтобы проверить доступность новой стабильной версии. Настоятельно рекомендуется установить исходные коды wxWidgets с путем без пробелов. Требуется выбор тома (диска) с минимум 300 МБ свободного пространства.
Сборка wxWidgets [ править ]
Примечание: /D флаг после cd может быть опущен из команды; просто это позволяет командной строке при необходимости изменить диски.
С последними версиями GCC (не с MSVC) необходим параметр «CXXFLAGS =-fno-keep-inline-dllexport» для предотвращения проблем с использованием памяти при выполнении финального шага сборки в монолитную DLL.
В разделе ниже под названием «Пояснение по опциям сборки wxWidgets» объясняется подробная информация о значении различных вариантов сборки: BUILD, SHARED, MONOLITHIC и UNICODE. Эти опции имеют критически важное значение, поскольку они определяют основу среды разработки wxWidgets используемой в дальнейшем. А именно, требуется дублировать их при запуске мастера создания проекта Code::Blocks’ wxWidgets.
Создание проекта wxWidgets в Code::Blocks [ править ]
Сборка и Запуск [ править ]
Нажмите «Сборка и запуск» (F9) чтобы проверить сборку и запуск приложения. Если все пойдет хорошо, ваше приложение wxWidgets должно появиться на экране.
Пояснение по опциям сборки wxWidgets [ править ]
Что означают опции BUILD, SHARED, MONOLITHIC, and UNICODE?
BUILD [ править ]
BUILD задает какую версию wxWidgets, отладочную (BUILD=debug) или конечную (BUILD=release), следует собрать. В подавляющем большинстве случаев нужна только конечная версия выпуска wxWidgets, так как отладка самого wxWidgets не потребуется. Вполне можно создавать отладочные сборки своих собственных программ, которые ссылаются на конечную сборку wxWidgets.
SHARED [ править ]
SHARED задает какую версию wxWidgets, динамически связываемую DLL (SHARED=1) или статически связанную static (SHARED=0), следует собрать. При сборке DLL версии компиляция происходит быстрее и размер исполняемого файла меньше. Общий размер одного исполняемого файла плюс библиотеки DLL wxWidgets больше, но одну и ту же библиотеку DLL могут использовать несколько исполняемых файлов и в этом случае получается экономия места на диске.
MONOLITHIC [ править ]
MONOLITHIC задает какую библиотеку, единую (MONOLITHIC=1) или многокомпонентную (MONOLITHIC=0) следует собрать. При монолитной сборке дальнейшие установка и разработка проекта выполняются намного проще, т.к. если используется DLL тип сборки библиотеки, то для распространения потребуется только одна библиотека DLL. При немонолитной (multilib) сборке, собираются несколько различных библиотек, и можно избежать связывания со всей базой кода wxWidgets тех программ, которые не нуждаются в ней. Нужно быть полностью уверенным в своих действиях выбирая правильный компонент библиотеки.
UNICODE [ править ]
UNICODE задает использование в библиотеке wxWidgets и в создаваемой программе поддержки символов Юникода. Эта возможность используется в большинстве программ для ОС Windows 2000 и более поздних версий. Более ранние версии Windows не имели необходимой поддержки Юникода. Вы всегда должны использовать макросы _(«string») и _T(«string») wxWidget для обеспечения того, чтобы жестко закодированные строки были правильного типа.
Configuring Debug Support
Starting with wxWidgets 2.9.1 debugging features are always available by default (and not only in a special «debug» build of the library) and you need to predefine wxDEBUG_LEVEL symbol as 0 when building both the library and your application to remove them completely from the generated object code. However the debugging features are disabled by default when the application itself is built with NDEBUG defined (i.e. in «release» or «production» mode) so there is no need to do this, unless the resources of the system your application will be running on are unusually constrained (notice that when asserts are disabled their condition is not even evaluated so the only run-time cost is a single condition check and the extra space taken by the asserts in the code).
This automatic deactivation of debugging code is done by wxIMPLEMENT_APP() macro so if you don’t use you may need to explicitly call wxDISABLE_DEBUG_SUPPORT() yourself.
Also notice that it is possible to build your own application with a different value of wxDEBUG_LEVEL than the one which was used for wxWidgets itself. E.g. you may be using an official binary version of the library which will have been compiled with default
but still predefine wxDEBUG_LEVEL as 0 for your own code.
On the other hand, if you do want to keep the asserts even in production builds, you will probably want to override the handling of assertion failures as the default behaviour which pops up a message box notifying the user about the problem is usually inappropriate. Use wxSetAssertHandler() to set up your own custom function which should be called instead of the standard assertion failure handler. Such function could log an appropriate message in the application log file or maybe notify the user about the problem in some more user-friendly way.
Assertion Macros
wxASSERT(), wxFAIL(), wxCHECK() as well as their other variants (see Debugging macros) are similar to the standard assert() macro but are more flexible and powerful. The first of them is equivalent to assert() itself, i.e. it simply checks a condition and does nothing if it is true. The second one is equivalent to checking an always false condition and is supposed to be used for code paths which are supposed to be inaccessible (e.g. default branch of a switch statement which should never be executed). Finally, the wxCHECK() family of macros verifies the condition just as wxASSERT() does and performs some action such returning from the function if it fails – thus, it is useful for checking the functions preconditions.
All of the above functions exist in _MSG variants which allow you to provide a custom message which will be shown (or, more generally, passed to the assert handler) if the assertion fails, in addition to the usual file and line number information and the condition itself.
Example of using an assertion macro:
The default assertion handler behaviour depends on whether the application using wxWidgets was compiled in release build (with NDEBUG defined) or debug one (without) but may be changed in either case as explained above. If it wasn’t changed, then nothing will happen in the release build and a message box showing the information about the assert as well as allowing to stop the program, ignore future asserts or break into the debugger is shown. On the platforms where wxStackWalker is supported the message box will also show the stack trace at the moment when the assert failed often allowing you to diagnose the problem without using the debugger at all. You can see an example of such message box in the Exception Sample.
Logging Functions
You can use the wxLogDebug and wxLogTrace functions to output debugging information in debug mode; it will do nothing for non-debugging code.