А третьим игроком будут макросредства, типа MS Access, PB, Lotus Notes, развитые до голосового ввода бизнез-рулз. :)

Или докажем что то-то могём, или вымрем как динозавры.

.NET тоже на C++ написана, микрософт исходники вывалила, можно полюбоваться. Гарбадж-коллектор оттуда - зело серьезная фишка. Интересно, его можно юзать вне .NET? :)
Он там стек прочесывает на предмет поиска переменных в стеке, т.е. там нет счетчика ссылок на объект (обычно). Я насчитал 4 способа уборки мусора, когда просматривал. Кстати - он объекты в памяти двигает! Прикол? И все ссылки сохраняют целостность. Думаю эту фишку вне микрософт писали, уж больно академическая...

Насчет MFC - я тут того, либу объектную писал, с 0-ля. Типа эксперименты. Быстродействие вышло гораздо выше, чем у ATL/MFC. И код маленький получается. Нинавижу обе технологии - наелся. Тупо и то и другое. И WTL не сильно сглаживает впечатление. Надо что-то типа System.Windows.Forms по стилю и принципам. MC++ не предлагать! :)

Кто хочет поучаствовать в разработке GUI-либы для Win32 на C++?

ну, когда говорю про MC++ то имею ввиду __gc и __value классы. К этим классам неприменимо ничего интересного из C++, на них действуют такие же ограничения, как на классы C#. Можно прочитать отличия MC++ от С++ в MSDN.

напр.
1. __gc классы можно наследовать только от __gc классов
2. Множественное наследование позволительно только в виде множественного наследования __interface.
3. забыдь про шаблонные классы и функции.
4. вместо статического приведения типов используй динамический dinamic_cast<>(), при той же сигнатуре он работает по-другому для .NET классов, хотя его смысл остается прежним.
5. __gc классы можно создавать только по new, __value классы создавать по new бесполезно.

Я бы использовал MC++ как "связку" c .NET или wrapper, т.к. MC++ класс все же позволяет хранить обычные (не .NET) типы. Т.е. твой чистый С++ класс может быть мембером __gc класса.

2 alexey_1979

Желание "рукоблудить" пришло давно, по мере изучения внутренних принципов работы MFC/ATL/WTL.

На большинство приходящих в обычной работе собощений Windows, в этих библиотеках происходит следующее:
1. reflection всех Notifications
2. PretranslateMessage вдоль по всей иерархии окон.
3. Поиск объекта в MAP-ах по хендлеру.
4. линейное "прочесывание" message maps классов в ответ на КАЖДОЕ ПРИХОДЯЩЕЕ СООБЩЕНИЕ.

В моей либе среднее время обработки сообщения примерно на порядок меньше.

Да, очень много материала из ATL и WTL можно использовать вне проектов одноименных типов. (всякие EditImpl + тонна вспомогательных полезных классов и утилит)

2 alexey_1979

Меня можно смело считать еретиком, потому как:

1. reflection всех Notifications
Оказ от этого заметно усложнит реализацию и использование.
А я порой не использую встроенные классы окон, типа "Button", "ComboBox", "ListBox", т.к. имею с 0-ля написанные ООП-аналоги. И мне не нужен Reflection, достаточно наследования для переопределения СВОИХ СОБСТВЕННЫХ свойств или поведения.

2. PretranslateMessage вдоль по всей иерархии окон.
Не понял?
Если тебе не нравиться, что нужно вызывать m_view.PreTranslateMessage и PreTranslateMessage CMainFrema, то как реализовать, чтобы он автоматом вызывался?
В том то и дело, что не понял. НЕ ДОЛЖНО БЫТЬ НИКАКОГО PretranslateMessage вдоль по всей иерархии окон. Это как хук по смыcлу, т.е. "черный вход", т.е. слабость самой модели. В своем GUI оно мне ПРИНЦИПИАЛЬНО не нужно!

3. Поиск объекта в MAP-ах по хендлеру.
Чаво?
MAP разворачивается в большой if then else. Это самое эффективное в данной ситуации. Ты же не будешь создавать массив обработчиков на несколько тысяч элементов для того, чтобы обработать пару сообщений.
Вот пример расточительного использования возможностей языка. if-else, понимаешь...
Загляни в файлы с описанием WM_XXXX, сколько там реальных сообщений? (я спрашиваю именно про общие сообщения, всякие EM_XXXX не берем, потому как в моей модели их НЕТ). Так вот, там чуть больше 200 реально используемых сообщений.
Слушай внимательно:
В моей модели я использую всего только 3 класса окон: простой контрол, контрол-контейнер, форма. Все! Большинство сообщений (99.99% из общего приходящего потока) в своей оконной процедуре просто достают адрес объекта из самомого экземляра МОЕГО класса окна (а не из многотысячного ATL/MFC MAP-а) и переходят сразу на функцию из таблицы. Т.е. у меня примерно 200 функций-обработчиков. Очень простых функций. Каждая функция-обработчик просто вызывает виртуальную функцию объекта! Поэтому у меня нет "прочесывания" MAP-ов на предмет поиска сообщений или на предмет if-else.
Почему же мне потребовалось 3 класса окна? Все эти классы оперируют одними и теми-же процедурами, просто используют разный их набор в своем массиве указателей на функции-обработчики. Самый младший из них - "контрол" просто игнорирует приличную часть сообщений, для него не предназначенную, чтобы не вызывать лишний раз виртуальную функцию, т.е. определив всего еще 2 таблицы из 200 элементов я получил дополнительное повышение эффективности.
Разработчик может наследовать свой GUI-элемент от Control, ControlContainer и Form - классов, используя разные базовые классы для требуемого множества перехваченных сообщений.
Повторюсь - у меня все работает примерно на порядок быстрее, чем MFC/WTL.
В этих библиотеках на каждое приходящее сообщение происходит тонна всяких бесполезных вызовов, у меня - не происходит ничего (вызов одной виртуальной функции и то не всегда, см. Control, ControlContainer, Form).

Если у тебя есть конкретные предложения, милости просим в форум ATL/WTL на RSDN.
ok. Только насколько это приятно - обсуждение тонкостей - если немного тошнит от самой концепции. Правда, в своих коммерчесских разработках я пока использую WTL или MFC, потому как мой фреймворк требует разработки аналогов всех контролов (!!!).
Однако, посмотрите что твориться с C#! Не успел толком выйти, как под него народ уже написал тысячи и тысячи контролов. Почему? Да потому, что там нужно просто отнаследоваться и переопределить несколько виртуальных функций - это на порядок проще, а главное - на порядок типобезопаснее, чем MESSAGE_MAP-ы. В моей либе - та же самая ситуация. Написать новый контрол так же легко, как на C#. Поэтому и приглашаю единомышленников.

Программируя на MFC/WTL я изучил WinAPI практически наизусть. А не пошел бы он... Очень смешно - программируешь на ООП-библиотеке, при этом думаешь понятиями OS API.
У меня сообщения Windows "спрятаны" в самых базовых классах и о них можно забыть - это тонкости конкретной платформы.

Я сам не проч заняться созданием более продуманного фрейморка для GUI аплитух, но только
1. После выхода wtl7.1
2. После изучения и выявления недостатков всех существующих аналогов.
Изучал QT и WxWindows.
QT - весьма оторвана от чего бы то ни было, в то время как моя либа обладает общей событийной моделью для всех классов, а не только для GUI. Т.е. у меня событие (не сообщение!) может получить экземпляр какого угодно класса (как в C#) и даже просто CallBack - функция (как только в С++)

WxWindows - сильно, весьма... Но хочется сильнее :)

2 Фурников Юрий

Сейчас рулит идея, что ООП себя не оправдало в смысле повторного использования кода и в данный момент модно говорить о компонентном подходе.
Если под компонентным подходом ты подразумеваешь открытые "чисто"-виртуальные интерфейсы, т.е. всего лишь "побочный" эффект множественного наследования. В .NET и Java, наряду с открытыми "голыми" интерфейсами так же рулит идея открытых базовых классов - это все одного поля ягоды...

Никто никогда не говорил о слобой выразительности C++ - говорили о другом. В частности о его сложности и противоречивости.
Сложность - да. Но без некоторой сложности не добиться некоторой выразительности. Слабый аргумент, особенно в эпоху насыщения рынка программистами. Кто не тянет - нафиг из области.

Оказалось что сам язык сейчас значит далеко не все. Т.е ты же сам знаешь что если сказать что пишешь на C++ - обязательно спросят на чем именно - т.е. среда разработки/выполнения, подходы и т.д.
К счастью компиляторы "движуться" на встречу друг-другу, вернее навстречу стандартному С++. Свои программы я обычно компилю на VC.NET и GCC для пущей переносимости.

2 Yossarian

> Для С++ можно использовать технологию COM для аналогичных целей.
Для каких ? Для сборки мусора ? Здесь что-то не так. >
Все так, и то и другое - подходы к контролю времени жизни объектов. И там и там используется общий смысл - объект уничтожается тогда, когда на него никто больше не ссылается.

>Язык Java не люблю до сих пор,
может быть в этом дело ?
А может, все же, яйцо раньше курицы... :)

>Самый-пресамый интересный момент.
Действительно, интересный. Фактически автор утверждает, что на С++
все пишут неправильно, кроме самого автора.
Нет. В том же посте ниже я приводил причину большого размера программ - это недостаточность существующих библиотек. При ПРОЧИХ РАВНЫХ условия программа на С++ обычно никак не меньше аналогов на Java или C#.

(а что не так - в Java есть общий предок для всех
объектов, а в С++ нет, отсюда описанная проблема)
Попал в точку! Почти...
Для всех объектов мне и не нужен один базовый класс, а вот для всех Exception - крайне необходим! Я бы запретил выброс Exception произвольного типа на уровне языка (фанаты С++ - не бейте), а оставил бы только унаследованные от некоторого одного класса (компилятор -> конкретный класс - не очень красивая связка, однако typeid использует тот же подход)

> Языки типа Java и C# изначально по своим возможностям являются подмножествами языка С++
Утверждать это - само по себе неграмотно. В строгом смысле слова "подмножество языка" это когда мы можем скомпилировать программу на подмножестве компилятором для надмножества, возможно с косметическими изменениями.
Именно так. Все вполне грамотно. (если, опять же, не иметь ввиду Reflection)

Я - за.
:)) угу, т.е. С++ все-равно умирать не собирается! (а иначе на чем будут .NET - фреймворки писать?)

в предыдущем посте читать:

>Самый-пресамый интересный момент. Действительно, интересный. Фактически автор утверждает, что на С++
все пишут неправильно, кроме самого автора.
Нет. В том же посте ниже я приводил причину большого размера программ - это недостаточность существующих библиотек. При ПРОЧИХ РАВНЫХ условия программа на С++ обычно никак не больше аналогов на Java или C#.

Да и с мнением Геннадия Васильева согласен - многие пишут так себе. В основном это то поколение, которое выросло на всяких Wizard-ах. (хотя, бывают исключения, у меня есть знакомый парень, 22 года, удивительно правильно мыслит и кодит).

www.codeproject.com - полно материала для подобного исследования. Порой там встречаются очень неплохие вещи, но большей частью - всякая ерунда. Материалы на сайте позволяют оценить средний уровень современного программиста.

Это может и хорошо, что есть Java и C#. Кому С++ кажется слишком сложным - просим туда. Не представляю грамотного С++-ника, который бы полностью разменялся на Java или C#. Я вот практически в совершенстве VB и VBScript знаю - писал несколько гибридных проектов, "стыковался" с ними при помощи COM. И что с того? VB-рулез?
Теперь активно изучаю .NET и C#, но "дно" уже видно. После изучения исходников .NET-а, и двоичного формата .NET-объектов, для меня вообще никаких интересных моментов относительно .NET не осталось. Мне откровенно импонирует язык C#, там где я раньше использовал VB, теперь буду использовать только его (учитывая беспланую VSA-engine). Но это все рассматриваю только как неплохое дополнение, которое очень экономит время в некоторых случаях. Просто полно ситуаций, когда на Java или C# поставленную задачу НЕВОЗМОЖНО РЕШИТЬ. Потому от С++ никуда не деться.

Любителям Delphi:\r
\r
Обратите внимание, народ 2 недели пишет DBImage - компонент (6-й пост и ответ тигра в 11-м)\r
\r
/topic/45348\r
\r
Очень показательно.\r
На с++ это примерно за пол-дня делается, если не за 2 часа...

2 alex_k

WxWindows, в и-нете с пол-пинка найдешь.

На чем компилишь?

Лучше потрать пару дней на изучение и компиляцию - это все вознаградится. Там не только GUI-либа. Еще тонна полезного материала.