Примечаниеnbsp; Эта техническая записка была написана для Windows 3.1. Windows &NT реализует большинство из этих функций. При запуске приложения под Windows 3.1 (с Win32s DLL), эти методы могут помочь в отладке. Windows 95 также реализует и расширяет функции надежности, ввести в действие во время Windows 3.1. Запуск отладочной версии Windows 95 является наилучшим способом застраховать ваше приложение работает корректно.
Windows 3.1 будет главное улучшение над Windows 3.0 в области разработки надежных приложений. Windows 3.1 включает в себя ряд новых функций, которые повышают надежность приложения Windows. Это техническое примечание описывает использование этих функций в рамках библиотеки MFC.
Эти возможности включают отладки ядра, СТРОГАЯ проверка типов, диагностики и управления памятью и WINDOWSX.H улучшения.
Ядро отладки Windows 3.1
Примечание Этот раздел относится только к Microsoft Visual C++ версии 1.5.
Тестирование приложения MFC с исполняемых файлов системы отладки, вероятно, лучшее, что можно сделать, чтобы убедиться, что ваши приложения прочной и надежной. Отладки версии исполняемых файлов системы выполняют все виды полезных проверку ошибок для вас, информирующее Вас о любых проблемах, которые возникают с отладки вывода сообщений.
Для использования системы отладки лучше с двумя машинами: машина для тестирования и отладки, была установлена система отладки и машины для развития. Одна машина, ваш тест, следует всегда запускаются с отладки ядра. Другой машины, ваш компьютер для разработки, следует запускать с ядром-debug. Выходные данные отладки ядра может быть направлена на основной машине через нуль-модемный линии. Если у вас есть только один компьютер, то вы должны обязательно для запуска отладки ядра (есть небольшое снижение производительности). Выходные данные отладки ядра могут быть маршрутизированы к DBWIN, инструмент, включенные в Microsoft Visual C++ версии 1.5. Кроме того в окне вывода Visual C++ будет получать данные при выполнении в отладчике.
Полезный трюк для отладки сингл машина-размещать копии системы и отладочные двоичные файлы и символы в отдельный каталог и пакетных файлов, которые скопировать соответствующие файлы в каталог вашей системы Windows. Таким образом, вы можете выйти из Windows и быстро переключаться взад и вперед между-debug и отладки. Программа установки Visual C++ версии 1.5 будет задать этот вопрос, то можно переключаться между отладочной и неотладочные версии Windows с D2N.Бат и N2D.BAT пакетных файлов.
Если вы не работаете с отладчиком или отладки терминал, запустите приложение DBWIN так что вы можете видеть ошибки и предупреждающие сообщения отладки системы. Это приложение входит в Visual C++ версии 1.5.
Ниже приведены несколько распространенных ошибок программирования, которые часто встречаются в приложениях Windows поставляется. Многие из этих проблем может привести к случайной системы UAEs и другие проблемы под Windows 3.0. Системные двоичные файлы отладки поможет вам отслеживать проблемы, такие как:
Диагностика MFC
Кроме того, классов MFC поставляются с набором функций надежности, которые компилируются и связаны только в отладочной версии библиотеки (эти варианты библиотека, заканчивая был '). Использование этих функций в приложениях вы пишете и в классах, которые вам дизайн значительно увеличит время выполнения и перехват ошибок времени компиляции приложения. Ниже излагаются эти функции, но все описаны в справочнике Справочник по библиотекам классов.
Каждый класс, производный от CObject в MFC реализует функцию Dump -член, которая позволяет вам просматривать состояние объекта в формате ASCII. Эта функция может быть вызван из отладчика или в # ifdef _DEBUG /#endif части вашего кода. Вспомогательная функция AfxDump включен в отладочной библиотеки только для этой цели. Он вызывается с единственным параметром, CObject *. Эту функцию можно вызвать из отладчика для печати из аргумента. Следует указать членом дампа для классов, реализующих вам. Как с AssertValid, следует сначала явно вызывать базовый класс функцию-член Dump . Вывод дампа направляется в стандартный MFC CDumpContext, afxDump, идущий по умолчанию в окне вывода отладчика или для отладки вашего терминала. DBWIN программы можно также использовать для просмотра выходных данных afxDump. Исходный файл MFC\SRC\DUMPINIT.НПК включает в себя информацию о том, как направить afxDump в другой пункт назначения.
ТРАССИРОВКИ, макрос, который ведет себя гораздо как printf, только маршруты вывода в afxDump место. Операторы ТРАССИРОВКИ следует использовать для обозначения сложно или исключительные мест в вашем коде. С другими характеристиками надежности TRACE имеет смысл только в отладочной библиотеке, а не оказывает влияния в коммерческом построении. Библиотека MFC включает в себя ряд построен в операторов ТРАССИРОВКИ для отслеживания потока сообщений. Для получения дополнительных сведений о трассировке отладки смотрите техническое примечание 7.
ASSERT -это проверка во время выполнения для действительности заявление. Используйте метод ASSERTs обильно всей вашей программы. Любое место, у вас есть комментарий о том:
/ / lpStr должно быть NULL в данный момент
что следует заменить метод assert во время выполнения:
Assert(lpStr == NULL)
Компилятор не может понять комментарий, но он может вычислить выражение в макросе, утверждение. Операторы ASSERT не имеют эффекта в построение розничных продаж. Если вам нужна информация из ASSERT в коммерческом построении, используйте макрос VERIFY.
MFC имеются обширные диагностические памяти распределителя. Распределитель памяти используется для проверки освободить все ресурсы памяти во время определенных функций программы. Диагностические средства выделения будет отслеживать исходный файл и линии номер выделения памяти, так что если вы используете CMemoryState::DumpAllObjectsSince API, вы можете найти все распределения, которые остаются.
По умолчанию MFC будет дамп все объекты, не освобождены вашей программы (если таковые имеются) до выхода из программы. Этот вывод можно просмотреть, запустив приложение в режиме отладки.
Проверка СТРОГОГО типа Windows 3.1
СТРОГАЯ проверка типов является с ОКНАМИ.H заголовочный файл. MFC использует эти СТРОГИЕ типы по умолчанию, и вы должны использовать их, если вы создаете приложение MFC. MFC больше не поддерживает построение приложения без STRICT defintions.
Строго типизированные связь и СТРОГОЕ
В C++ вам разрешается иметь много функций с тем же именем, поскольку эти функции имеют различные официальные списки параметров. Для того чтобы иметь уникальную ссылку символы, компилятор C++ будет «украшают» эти имена с помощью алгоритма, который кодирует информацию о такие функции, как имя, номер и тип формальных параметров, соглашение о вызове, и т.д.
Это недавно созданное имя используется как символ внешней ссылки для функции. Это известно как строго типизированные связь и является большим преимуществом C++. Это искажение имени не применяется к функции в пределах блока extern «C», и вот почему все интерфейсы API в WINDOWS.H находятся в блоке.
Строгий тип проверки в WINDOWS.H повышает безопасность типов для программ Windows с использованием различных типов для представления различных ДЕСКРИПТОРОВ в Windows. Так, например STRICT позволяет ошибочно передачи HPEN в обычной ожидали HBITMAP.
Поскольку интерфейсы API Windows находятся в блок {} extern «C», они не оформлены в форме, описанной выше. Строгий меняет типы различных typedefs Windows, чтобы сделать их уникальный (именно его использует различных типов для представления ОБРАБАТЫВАТЬs, который не может быть преобразован свободно без явного приведения).
Как вы можете видеть, если у вас есть СТРОГАЯ проверка типов, включена в одном файле, но не в другом, C++ компилятор генерирует символы различных внешних ссылок для одной функции. Это приведет к ошибкам времени компоновки. Таким образом рекомендуем использовать строгий тип проверки только для c модулей (те, которые заканчиваются на.C). Кроме того, СТРОГИЕ настолько время компиляции только вариант, как только вы успешно скомпилировать код, полностью реализовать выгоды STRICT.
Если вы смешивания STRICT и non-STRICT кода, вы должны осознавать связь несоответствий. В общем все Программирование MFC и все C++ должно быть сделано с STRICT. Если у вас есть наследие код на Си, не используя STRICT является приемлемым.
Windows 3.1 WINDOWSX.H заголовочный файл
Новый Windows 3.1 и Win32 является WINDOWSX.H заголовочный файл, который поддерживает различные расширения для C-кодирование стиля для программистов Windows с помощью C. Эти макро API-интерфейсы сообщений крекеры управления и API-интерфейсы определены в файле WINDOWSX.H.
Этот синтаксис предназначен в основном для программистов. MFC поддерживает использование WINDOWSX.H, так что если у вас есть существующий код, который основывается на них напряженность, используйте этот код не изменяются в MFC. Однако, вы найдете, что MFC имеет сопоставимые идиоматизмы для всех функций WINDOWSX.H и язык использует C++ для выполнения этих задач с больше семантических и архитектурных безопасности.
Для использования WINDOWSX.H, не забудьте # включить его, прежде чем вы включили AFXWIN.H (или STDAFX.H если вы используете AppWizard структуры).
Единственная загвоздка состоит в том, что существует два WINDOWSX.H API, которые сталкиваются с MFC C++ API. Два API SubclassWindow и CopyRgn не доступны для использования в MFC. Вам потребуется перекодировать их для использования MFC API (и классах) или непосредственно вызывать Windows API. Вы также можете код свой собственный макрос, пока он имеет другое имя.
Технические примечания по номеру |nbsp; Технические примечания по категориям