Статья:
SWL – Small Windows Library

Автор(ы): Alexander Kluev
Дата: 05.02.2003
Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

Авторы:
Alexander Kluev

Аннотация:
Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

Здравствуйте, Alexander Kluev, Вы писали:

AK>Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

Не хочу раздувать флейм, но С++ — как раз и есть убожество (мое мнение)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alexander Kluev, Вы писали:

AK>>Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

А>Не хочу раздувать флейм, но С++ — как раз и есть убожество (мое мнение)

К счастью ваше мнение не оказывает на красоту С++ никакого влияния. Золото всегда останется золотом независимо от того что о нем говорят и как называют.

Здравствуйте, Kluev, Вы писали:

K>К счастью ваше мнение не оказывает на красоту С++ никакого влияния. Золото всегда останется золотом независимо от того что о нем говорят и как называют.

Да только в последнее время С++ очень тесно связывается с MFC и подобными ублюдствами, что не меня не радует...
А насчет золота — вспомните — "посмотришь — оно..."

Здравствуйте, Amon-RA, Вы писали:

AR>Здравствуйте, Аноним, Вы писали:
А>>Да только в последнее время С++ очень тесно связывается с MFC и подобными ублюдствами, что не меня не радует...
А>>А насчет золота — вспомните — "посмотришь — оно..."

AR>Что за ерунда. MFC действительно отстой, но причем тут С++. Можно и на супер-языке написать говенную программу
Правильнее было бы сказать, что на голимом языке тоже можно сделать приличную программу...
Чё вы все спорите, кто лучше, тот язык или другой? Не понимаю вообще. Мне вон тоже не особо понятно рвение всех изучать С++, но я ж не говорю, что он плохой.
Видите ли, люди, все зависит не от языка, а от его использования (от программера, тобишь)... Какой программер, такая и программа.

Велосипед велосипеду рознь ;)

Здравствуйте, Аноним, Вы писали:

А>И никуда Win32 не уйдет.

Однозначно Win32 уже уходит в прошлое. В следующем виндосе среда исполнения будет на Net.

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>И никуда Win32 не уйдет.

А>Однозначно Win32 уже уходит в прошлое. В следующем виндосе среда исполнения будет на Net.

А Net-то на чем написан будет???

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alexander Kluev, Вы писали:

AK>>Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

А>Не хочу раздувать флейм, но С++ — как раз и есть убожество (мое мнение)

Здравствуйте, Tall, Вы писали:

T>Здравствуйте, <Аноним>, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>И никуда Win32 не уйдет.

А>>Однозначно Win32 уже уходит в прошлое. В следующем виндосе среда исполнения будет на Net.

T>А Net-то на чем написан будет???
Да там вроде какой-то WinFX обещают. Только два но:
1) Это они что весь .нет заново перепишут на основе этого эфикса? А пока там win32 везьде торчит почти неприкрытый. Есть ощущение, что указанный эфикс — новое название для старого апи.
2) Когда выйдет следующая версия windows, предыдущие на помойку отправятся далеко не моментально.

Здравствуйте, Andrew S, Вы писали:

AS>И все-таки макросы в разы лучше для карты сообщений. Учитывая, что при этом карта сообщения преобразуется макросами в конструкцию вида switch{case}, очевидно, ....

Тезка, Вас нагло обманули по поводу switch{case}
Там все на if сделано...

Т.е. то что следует за Вашим "очевидно" — как раз наоборот....

Андрей.

Здравствуйте, Alexander Kluev, Вы писали:

AK>Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

По статье. "Красота C++" — это, похоже, моменты типа msg.begin_paint(). Рискну выразить мнение, что это не красота языка, а стиль "как не надо проектировать классы". Достаточно прочитать по-русски: "Сообщение! Начни отрисовку!". Так и появляются классы типа "таймер со встроенной отрисовкой часов и поддержкой скинов". Конечно, в рамках подхода это можно было бы сделать несколько поизящнее, организовав синтаксис типа msg.hdc.begin_paint(), но само по себе весьма показательно.

Применение шаблонов для сообщений считаю неоправданным. Собственно, нужно оно как раз для того, чтобы писать "красоты" типа упомянутой в предыдущем абзаце, в остальном это совершенно излишне.

Весьма поверхностное замечание. Попахивает пальцами.
И никуда Win32 не уйдет.

Это мое личное отношение к win32 (не тема для флейма ;) )

И все-таки макросы в разы лучше для карты сообщений. Учитывая, что при этом карта сообщения преобразуется макросами в конструкцию вида switch{case}, очевидно, что у компилера есть все шансы оптимизировать выборку сообщения по ID во время компиляции, что он в большинстве случаев и делает (обычно используется некоторое преобразование над аргументом switch, а далее выбирается нужный элемент массива переходов).
У вас же поиск происходит горааааааздо медленнее (более того, он похоже даже не ассоциативный):
bool Handler::call( SWL::Handler mmp[], Wnd *wnd, MsgBase *msg ) {
Handler *p = mmp;
_ASSERTE( tag_begin == p->_proxy );
if ( p->_id == tag_x )
_init( mmp );

Handler vh;
vh._id = msg->id;

Handler *hs = mmp + 1;
Handler *he = mmp + ( 1 + mmp[0]._id );

Handler *ph = lower_bound( hs, he, vh, _less_by_id );

if ( ph != he && !(vh._id < ph->_id) ) {
ph->_call( wnd, msg );
return false;
}
return true;
}

Вывод: боюсь эта библиотека не показывает красоту С++ в полной мере (хотя бы так, как это делает ATL/WTL), и более того, показывает, что иногда макросами не стоит пренебрегать. А выражение про убогость win32 действительно смахивает на "пальцы".

У меня используется двоичный поиск в предварительено отсортированном массиве:
Handler *ph = lower_bound( hs, he, vh, _less_by_id ); — смотрите сырцы stl
это работает не намного медленне (а может и быстрее. я не проверял {это мне неинтересно})
К тому же поиск сообщения в карте/свитче это не самое узкое место в программах.

И давайте не будем разводить флейм типа SWL vs WTL, макросы vs шаблоны. Здесь показано как сделать БЕЗ макросов, другой стиль програмирования демонстрируется.

Насчет убогости win32 я уже сказал, что это мое личное отношение.

To Andrew S
Забыл написать, что в WTL макросы не в switch\case, а в обычный if преобразуются. Оптимизацией там и не пахнет, да и не нужна она там.

Да, верно, если у вас random-access итератор, то это так и будет (честно говоря, особо ковыряться в коде не хочется)
И в любом случае — выборка по индексу из массива не может быть (!) медленнее поиска, пусть даже как Вы утверждаете, и в упорядоченой последовательности.
А скорость как раз нужна. Когда по окнам пробегают много сообщений — это уже становится накладно. А насчет WTL — да, ошибся, там действительно switch только на MessageMapId. Печально.
А насчет мнения о win32 — fine, оно Ваше, но необязательно выражать его так категорично.

>И в любом случае — выборка по индексу из массива не может быть (!) медленнее поиска, пусть
>даже как Вы утверждаете, и в упорядоченой последовательности
А где вы видели такую реализацию? (если речь конечно о поиске обработчика)

>Когда по окнам пробегают много сообщений — это уже становится накладно
двоичный поиск хорошо справится даже с картами в 1000 сообщений (потребуется не более 10 операций сравнения)

>А насчет мнения о win32 — fine, оно Ваше, но необязательно выражать его так категорично
Выражаю как считаю нужным

Бр... Люди — а можно немного мозгов проявить ?
для чего оптимизация message mapов ?
если в вашем диалоге больше 255 контроллов — то ни один узер им пользоваться не будет.
Если меньше — то for будет работать быстрее и занимать меньше памяти чем любые его оптимизации (i.e. map)

Но мне понравилась идея Msg<WM_CREATE>... в WTL до такого не дошли —
там вечно конверитовать надо из параметеров в хрен знает что...

Очень, жаль.

А вы посмотрите (в исходники) как приходится изворачиваться, чтобы сделать что-то удобное :)

Не стоит расстраиваться ;)

Win32 не уйдёт!!! Это точно... Убожество? Любая библиотека основанная на API сейчас выглядит убого :) Но для Win32 это нормально и обоснованно. Так что здесь автор перестарался.

Не стреляйте в пианиста ;) он играет как умеет

Согласен с Вами насчет оптимизации Message Map.
Конечно трудно сделать диалог более чем с 100 контролами. Да и какой юзер сможет пользоваться таким диалогом? Я имею ввиду обычных юзеров. И сделать меню более
чем с 70 пунктами — это тоже сложно и для разработчика и для юзера.
А насчет ухода Win32 — по-моему, это глупо. Никуда она не уйдет, в Win64 скорее всего будут использоваться теже принципы.

Говоря про уход win32 я имел ввиду уход многих разработчиков на .net. Сам api конечно же никуда не денется.

я пока не собираюсь на .Net :)

Отличное использование шаблонов!
Кстати, показывает убожество не только Win32, но и С++. :))
Все эти приёмы должны оптимизироваться на этапе компиляции, что в С++ конечно же не происходит. :-Р

А чего там оптимизировать? все и так быстро :)
Самое главное чтобы программеру было удобно.

Здравствуйте, <Аноним>, Вы писали:

хъ

А>Однозначно Win32 уже уходит в прошлое. В следующем виндосе среда исполнения будет на Net.

Безосновательное утверждение.

З.Ы. Не надо только разводить флуд.

Здравствуйте, Аноним, Вы писали:
А>Да только в последнее время С++ очень тесно связывается с MFC и подобными ублюдствами, что не меня не радует...
А>А насчет золота — вспомните — "посмотришь — оно..."

Что за ерунда. MFC действительно отстой, но причем тут С++. Можно и на супер-языке написать говенную программу

AK>Авторы:
AK> Alexander Kluev

А что у Вас с этим проектом? Развивается, есть обновления и прочее или так на уровне лабораторной работы и останется?
Есть желание применить, доработать?

(с уважаением, батьку aka dad)

Здравствуйте, Аноним, Вы писали:


AK>>Авторы:
AK>> Alexander Kluev

А>А что у Вас с этим проектом? Развивается, есть обновления и прочее или так на уровне лабораторной работы и останется?
А>Есть желание применить, доработать?

Да нет, я вообще с программированием завязал практически . Сейчас больше руками работаю в CAD-ах

K>Да нет, я вообще с программированием завязал практически . Сейчас больше руками работаю в CAD-ах

понятно. жалько

Здравствуйте, Аноним, Вы писали:

А>Весьма поверхностное замечание. Попахивает пальцами.

Его пальцы пахнут мясом, не кажется? (х/ф Доберман)

Здравствуйте, Alexander Kluev, Вы писали:

AK>Статья:


AK>Авторы:
AK> Alexander Kluev

AK>Аннотация:
AK>Small Windows Library – это экспериментальная оконная библиотека вокруг win32. Особой практической ценности она не представляет ввиду неизбежности ухода win32 со сцены, но тем не менее иллюстрирует еще один способ организации оконной библиотеки. Она предназначена показать красоту С++ и убожество win32.

В коде стоит:

HWND hw = ::CreateWindowEx( exStyle, XImpl::clsName, name, style, 
        rc.left, rc.top, rc.width(), rc.height(), 
        parent, (HMENU)id, GetModuleHandle(NULL), this );

В CreateWindowEx последний параметр pParam предназначен для:

A pointer to a value to be passed to the window through the CREATESTRUCT structure passed in the lParam parameter the WM_CREATE message. If an application calls CreateWindow to create a multiple document interface (MDI) client window, lpParam must point to a CLIENTCREATESTRUCT structure.

Собственно вопрос. Что ты будешь делать с MDI interface и с диалогами?

Здравствуйте, Олег Гашев, Вы писали:

Я не автор, но отвечу

ОГ>Собственно вопрос. Что ты будешь делать с MDI interface и с диалогами?
Насчет планов смотри .
Наcчет MDI: видать не перебороть аналогичным способом.
Насчет диалогов: есть CreateDialogParam, DialogBoxParam. Диалоговая функция все равно для них нужна другая.
Более общий подход — использовать TLS, ведь WM_CREATE или что там первое ( это знать не обязательно, так как можно сделать StartWindowProc ) всегда приходит до завершения любой из создающей функции.

Здравствуйте, Рома Мик, Вы писали:

РМ>Насчет планов смотри .
В смысле Re[2]: SWL – Small Windows Library

Автор: Kluev
Дата: 22.12.03

Здравствуйте, Kluev, Вы писали:

K>Говоря про уход win32 я имел ввиду уход многих разработчиков на .net. Сам api конечно же никуда не денется.

Про Джаба говорили так же, а что в итоге. Джаба заняла свою нишу в софтверном рынке, и ни гу-гу.

Здравствуйте, <Аноним>, Вы писали:

А>Весьма поверхностное замечание. Попахивает пальцами.
А>И никуда Win32 не уйдет.
Не то, чтобы не уйдёт, а не скоро ещё уйдёт.

Здравствуйте, Alexander Kluev, Вы писали:

AK>Она предназначена показать красоту С++ и убожество win32.

А что насчет эффективности?
Шаблоны это кончна круто и даже удобно. Но насколько оправдано их приминение в данном контексте? В чем глубокий смысл в раздувании кода? Когда размер бинарника несколько сотен килобайт, это конечно не имеет значения. Но если мне нужен сверхтонкое приложение я бы взял WTL

Здравствуйте, AndrewJD, Вы писали:

AJD>А что насчет эффективности?
AJD>Шаблоны это кончна круто и даже удобно. Но насколько оправдано их приминение в данном контексте? В чем глубокий смысл в раздувании кода? Когда размер бинарника несколько сотен килобайт, это конечно не имеет значения. Но если мне нужен сверхтонкое приложение я бы взял WTL

А WTL что без шаблонов сделан? Возьмите лучше голый АПИ. (и голый masm) и будет вам сверхтонко.

Здравствуйте, Kluev, Вы писали:


K>А WTL что без шаблонов сделан? Возьмите лучше голый АПИ. (и голый masm) и будет вам сверхтонко.

Не будем впадать в крайности... WTL сделан на шаблонах, но там для каждого обработчика сообщений не создается по классу и конструктору. Их ведь ооочень много может быть.

Здравствуйте, AndrewJD, Вы писали:

AJD>Не будем впадать в крайности... WTL сделан на шаблонах, но там для каждого обработчика сообщений не создается по классу и конструктору. Их ведь ооочень много может быть.

Странные у вас запросы. Нужно сверхтонкое приложение и ооочень много обработчиков. Когда ооочень много обработчиков обычно забивают на сверхтонкость и более уделяют внимание внятности архитектуры проекта.

AJD>>Не будем впадать в крайности... WTL сделан на шаблонах, но там для каждого обработчика сообщений не создается по классу и конструктору. Их ведь ооочень много может быть.

K>Странные у вас запросы. Нужно сверхтонкое приложение и ооочень много обработчиков. Когда ооочень много обработчиков обычно забивают на сверхтонкость и более уделяют внимание внятности архитектуры проекта.

не объекты которые использованы здесь не сказываются на производительности, это все миф.

А вот обработка сообщений в стиле:

if ( message = ok ) 
{
    BOOL handled = FALSE;
    LRESULT  r = process_ok_(message, lparam,rparam,handled);
    if ( handled ) return r;
}

действительно очень "мощно"

Здравствуйте, dad, Вы писали:


dad>не объекты которые использованы здесь не сказываются на производительности, это все миф.

dad>А вот обработка сообщений в стиле:
skip

dad>действительно очень "мощно"

Я за производительность не переживаю — она здесь будет вполне приличная. Я за размер бинарника и скорость компиляции

Здравствуйте, AndrewJD, Вы писали:

AJD>Я за производительность не переживаю — она здесь будет вполне приличная. Я за размер бинарника и скорость компиляции

Как раз с WTL и будет маленькая скорость компиляции и распухание бинарника. Знаем, проходили. Там же все в шаблонах и через псевдовиртуальные функции сделано. Вместо десяти маленьких классов производных от одного большого, в WTL получится десять больших.

Вообще микровсосовские поделия в области библиотек классов вызывают только огорчения и ничего больше. Чтобы написать нормальную оконную библиотеку под Win надо полностью закрывать оконный WinApi. Чтобы из библиотеки от него наружу ничего из него не торчало и даже не пахло.