Алекс Jenter - Программирование на Visual C++. Архив рассылки Страница 16

С WTL все в принципе так же. Вы должны уметь программировать, используя Win32 и GDI. Но если вы это знаете, тогда WTL для вас – не более чем глоток свежего воздуха. Если же вы не имеете представления о Win32 и GDI, тогда лучше вам писать пользовательский интерфейс на VB.

Библиотека имеет основной набор классов для приложения. Заметьте, что хотя у вас нет классов-документов (documents), как в MFC, у вас все еще есть классы-представления (views). В WTL очень много кода, предназначенного для того, чтобы позволить вам манипулировать представлениями, а также легко добавлять ваш собственный код. Существует свой мастер AppWizard, с помощью которого можно легко создавать каркасы SDI-, MDI– и многопоточных SDI-приложений (т.н. Multi-SDI-приложение выглядит, как будто открыто много экземпляров обычного SDI-приложения, но на самом деле это разные окна одного и того же процесса. Примером такого приложения может служить IE или Windows Explorer). Плюс к этому, ваша программа может быть приложением на основе диалога (dialog-based) или на основе представления (view-based). Сами представления могут быть основаны на классе CWindowImpl, на каком-либо элементе управления, или даже на HTML-странице. Вы также можете выбирать, будет ли ваше приложение иметь панель инструментов в стиле IE (rebar), в стиле Windows CE (command bar), или простую (toolbar); можно добавить строку статуса (status bar). Ваше приложение может внедрять элементы управления ActiveX и может быть COM-сервером.

Есть выбор среди нескольких видов классов-представлений, которые вы можете использовать. WTL представляет классы окон с разделителями (splitter-window), так что вы можете иметь два окна в одном представлении, и классы окон с прокруткой (scroller-window), где окно может быть меньшего размера, чем представление, которое оно отбражает. Существует также некий аналог UpdateUI из MFC, хотя в WTL он работает немного по-другому – основное отличие в том, что вы сами указываете, какие элементы могут обновляться посредством карты сообщений (message map), и вы должны добавить код в ваш класс, чтобы выполнить UpdateUI. Библиотека поддерживает технологии DDX/DDV, которые, опять же, очень похожи на их аналоги из MFC, с той только разницей, что у вас есть карта сообщений, которая реализует DoDataExchange и вам нужно добавлять код для осуществления этой операции.

Присутствуют теперь и классы GDI. Класс-оболочка HDC очень похож на CWindow в том, что очень тонок, – добавляет мало новой функциональности. Тем не менее, в нем есть поддержка метафайлов и OpenGL. Я думаю, основное применение будут иметь классы-наследники для работы с принтерными контекстами устройства – в WTL есть поддержка печати и даже предварительного просмотра (print preview). Имеются также классы-обертки для GDI-объектов, кистей (brushes), перьев (pens), регионов (regions), и т.д.

Еще в библиотеке можно обнаружить классы для всех стандартных Win32 и W2K (Windows 2000) диалогов (common dialogs), опять же, хотя эти обертки довольно тонки, они делают задачу выбора шрифта или, скажем, файла действительно простой.

Старый файл AtlControls.h  был включен из ATL в WTL, и содержит несколько новых классов для элементов управления W2K, наряду с некоторыми классами для элементов управления, не относящихся к Win32, таких как клон панели команд (command bar clone), кнопка с изображением (bitmap button), гиперссылка (hyperlink) и курсор "песочные часы" (wait cursor). […]

И, наконец, в библиотеке имеются служебные классы, самым значимым из которых является CString. Да, это клон класса CString из MFC, который реализует (насколько я знаю) все его методы. Еще есть класс-оболочка для поиска файлов (find file API) и классы-аналоги CRect, CSize и CPoint.

Если вы собираетесь писать Win32-приложение с пользовательским интерфейсом, я рекомендую вам попробовать WTL прежде чем думать об MFC. Если вы пишете код в WTL, он будет меньше в объеме и более эффективен, и вы будете иметь все преимущества поддержки COM в ATL, которая, увы, отсутствует в MFC. 

Итак, WTL – очень перспективная библиотека на основе ATL, которая, однако, НЕ ИЗБАВЛЯЕТ вас, как программиста, от необходимости знания WinAPI. И я могу привести кучу доводов в пользу такой архитектуры, многие из которых достаточно очевидны. Но, как всегда, есть и аргументы contra. MFC намного мощнее, и имеет намного больше возможностей. Из них, в частности, модель "документ/представление", поддержка документов OLE, автоматизированный обмен данными, пристыковывающиеся панели/диалоги и многое другое.

Объем кода, который вам приходится писать самому, в WTL больше.

Не думайте также, что в WTL нет ошибок: как показывает практика, их там тоже полным-полно (я видел список известных на данный момент багов). Библиотека еще сыровата. Так что не следует переоценивать WTL, но и спускать со счетов тоже не стоит. Конечно, она пока не стала стандартом и официально Microsoft не поддерживается. Но, как говорят на западе, things can change. В нашей профессии всегда приходится держать ухо востро на все инновации, т.к. они имеют неприятную особенность становиться стандартами.

А что касается рассмотрения WTL в рассылке: в принципе я не против, если вы не против. Смущает меня только одно: тем для рассылки становиться настолько много, что впору было бы создавать несколько рассылок, – одну про WinAPI, другую про MFC, третью про WTL, и т.д. Знаю, многие сочтут это просто отличной идеей, т.к. смогут подписаться именно на то, что их интересует. Но, к сожалению, я один, и физически не смогу все эти рассылки готовить, а помощников нет. Конечно, я буду стараться осветить самое важное и интересное. Как кто-то сказал, "нельзя объять необъятное… а если и можно, то только по частям и не сразу" ;) Так что давайте договоримся: пока будем придерживаться общепринятого стандарта – C++, WinAPI и MFC. А WTL (или C#, или чем-то другим) займемся, когда ее название будет фигурировать в объявлениях типа "требуется программист" чаще, чем MFC.

Читайте в следующем выпуске рассылки:

• Как правильно писать программы на C++: некоторые правила, которые помогут вам писать легко читаемый код.

• Рубрики "Вопрос-ответ" и "В поисках истины".

Также планируется в последующих выпусках:

• CPropertySheet: создание окон свойств и мастеров.

• Массивы, списки и ассоциативные списки. Общие положения и реализация в MFC.

• Решение проблемы с OnIdle в dialog-based приложениях.

• Работа с панелью инструментов. Задание вида кнопок и размещение отличных от кнопок элементов.

• Постоянные рубрики "Вопрос-ответ", "В поисках истины" и "Обратная связь". 

До встречи!

Программирование на Visual C++

Выпуск №15 от 18 сентября 2000 г.

Доброе время суток!

Сегодня мы с вами поговорим о такой вещи, как стиль программирования.

Если вам когда-нибудь приходилось разбираться в чужой программе, или даже в своей собственной, но написанной несколько лет назад, да еще когда поджимает время, вы скорее всего знаете, какая это неприятная и сложная задача. Порой бывает легче весь код написать заново (а многие так и делают). Конечно, существует поговорка "настоящие программисты не пишут комментарии: если программу было трудно написать, в ней должно быть трудно что-то понять и еще труднее что-либо изменить". О комментариях мы еще поговорим, печально то, что очень многие следуют этому принципу в самой программе. "Неважно", думают они, "как это написано, главное побыстрее проверить, работает ли это вообще". Самые прилежные из них впоследствии переписывают отдельные куски кода, но таких единицы. Большинство же, убедившись в работоспособности алгоритма, оставляют все как есть и переходят к новым задачам.

Как показывает многолетняя практика, это большая ошибка. Усилия, потраченные на "причесывание" кода, окупаются с лихвой. Но по-настоящему ценится умение писать сразу такой код, который не нуждается в причесывании. Это умение не приходит само по себе, а вырабатывается постепенно, в нем надо постоянно практиковаться. И когда вы говорите себе "а, это ведь просто небольшая утилитка для удобства, вот когда получу настоящий заказ – буду писать красиво", вы тем самым приучаете себя к неправильному стилю написания программ.

Однажды я прочитал такую интересную мысль: программы надо писать не для компьютера, а для людей. Следует сразу рассчитывать на то, что этот код будут смотреть сотни или даже тысячи программистов. Компилятор же нужен просто для проверки орфографии.

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

1. Обязательно соблюдайте отступы. Хотя Visual C++ и делает отступы автоматически, иногда они все же нарушаются. С их помощью сразу видна структура программы.