Пришлось тут не давно заняться написанием проги с использованием WinApi. Раньше для создания приложений под win юзал MFC, но как ни странно с WinApi работать на прямую во много раз легче, чем юзать классы MFC, да и код получается более менее понятным. Ты видишь что за чем идет, тебя не беспокоят врубленные по дефолту бесполезные ресурсоемкие фичи, ты просто прогишь.
Мой вывод: чистый WinApi удобнее чем классовая оболочка MFC.
Да и ещё... о чем интересно думали мелкомягкие, когда делали в MFC мапы сообщений ? крайне неудобно это, удачнее просто использовать цикл с выборкой нужной инфы.
У кого какие мысли ?

Не могу согласиться... мне кажется утверждение, что WinApi удобнее чем MFC верно только для конкретных задач, в частности, таких как системное программирование... да и то, если приложение довольно громоздкое, то придется писать некую обертку над WinApi для комфортного программирования... Хотя у MFC очень много недостатков, согласен и смерть MFC - это лишь дело времени. И лично я для тех задач, в которых MFC удобнее WinApi предпочитаю VCL:)

Да для работы с "Документ-представление" довольно трудно юзать чистый WinApi, но в остальных случаях он просто идеально подходит.

Проблема в том, что этих случаев так мало...

Я шел в полностью противоположном направлении - писал несколько лет на WinApi и VCL и лишь недавно заинтересовался MFC. В процессе ознакомления (а в последствии - и более углубленного изучения) сделал для себя следующие выводы:

1. В стандартной поставке MFC имеется весьма ограниченный набор компонентов. Сравнив стандартный набор компонентов из VС++.NET 2003 и из WinAsm Studio я с удивлением обнаружил, что первая среда разработки содержит всего на 2 компонента больше! Причем эти компоненты далеко не самые ходовые - календарь и "супер-комбобокс".

Разумеется существует огромное количество других компонентов (например тут) но все они написаны сторонними разработчиками что несколько озадачивает - сильно сомневаюсь что за все N лет существования MFC в Microsoft'e не нашлось ресурсов чтобы сделать побольше компонентов (хотя бы на уровне VCL).

2. Код, выдаваемый "мастером", порой весьма сложен для понимания. Например уже упомянутые мапы сообщений - простое ветвление сообщений гораздо нагляднее и удобнее.

3. Код, который пишешь сам, так же далеко не всегда прост и очевиден. Особенно "нравится" ручное создание переменных для каждого контрола - чрезвычайно "удобно" и "интуитивно". Часто бывает проще написать все родными WinApi чем извращаться с тем что наворочено MFC.

4. MFC слишком низкоуровневая библиотека. Почему например нельзя добавлять страницы в TabControl сразу во время проектирования интерфейса и кидать на них контролы? Вместо этого приходится извращаться стандартным способом (подгрузкой окон диалогов, см. MSDN).

Общий вывод: суммируя изложенные выше качества приходим в выводу, что MFС без дополнительных компонентов от сторонних разработчиков очень мало на что способна по сравнению с "голым" WinApi, не говоря уж о VCL.

Отвечая на негласный вопрос "а что же юзать?" можно сказать следующее:

- если время особо не поджимает и устраивает стандартный интерфейс (без всяких изращений типа разноцветных кнопок, анимированных меню и прочих поющих бирюзовых слоников), то лучше всего будет взять хороший редактор ресурсов (например упомянутный выше WinAsm Studio) и писать на WinApi;

- если время сильно поджимает и\или нужен нестандартный интерфейс тогда лучше всего будет воспользоваться VCL.

Это сообщение отредактировал(а) rsm - 24.4.2005, 23:18

Сам .exe файл в MFC получается больше!

Цитата(En_t_end @ 24.4.2005, 14:32)

о чем интересно думали мелкомягкие, когда делали в MFC мапы сообщений ? крайне неудобно это, удачнее просто использовать цикл с выборкой нужной инфы

Идея-то в действительности простая - связать идентификатор сообщения с указателем на ф-цию-обработчиком соотв. события. Если подумать о том, какие варианты решения возможны, с учетом что требовалось разработать нек-рый framework, к-рый можно было бы сравнительно несложно приспособить для конкретного Windows-приложения, то окажется, что их, т.е. решений, не так уж много.
Это значит, что требуется:
1) динамический контейнер, в к-рый нужно добавлять элементы (т.е. указатели на ф-ции-обработчики событий) в произвольном порядке, ключом к-рого явл. в общем случае натуральное число (т.е. идентификатор сообщения);
2) обеспечить эффективный поиск элемента в контейнере по ключу-идентификатору сообщения.
Вопрос, какой контейнер наиболее полно удовлетворяет данным требованиям?
Вот и вылезла-то она, т.е. "мапа", к-рая скорее всего реализована как двоичное дерево, производительность поиска в к-ром - O(log 2 (n)).
Если бы мне потребовалось бы разработать некий функциональный framework, то в его основу я так же положил бы "мапу" указателей на ф-ции или еще лучше классов-функторов, в к-рой произвольный элемент разыскивается по его идентификатору.
Ну, так чем неудобна "мапа"? Что, std::map - тоже неудобна?
ЗЫ: Чтобы быть правильно понятым, также считаю, что MFC - наиболее уродливая библиотека классов среди всех тех, что когда-либо мне встречались.

Fire-Plug 

Цитата

Если бы мне потребовалось бы разработать некий функциональный framework, то в его основу я так же положил бы "мапу"

|
^

Цитата

Чтобы быть правильно понятым, также считаю, что MFC - наиболее уродливая библиотека классов среди всех тех, что когда-либо мне встречались.

Вот и взаимосвязь.

ЗЗЫ я бы предложил вариант со списком, так лично мне удобно В голове содержиться массив int. То есть чтобы найти обработчик, надо просмотреть массив на предмет подходящего номера сообщения. Идентификатор же подходящего члена будет номер члена в списке. То есть сразу переходим к нужному члену списка и обрабатываем...

Попробуй WTL, мне понравилось, с одной стороны совершенно APIпрозрачно, с другой все-таки ООП

Nastya

Цитата

Попробуй WTL, мне понравилось

Тот же шарик только в профиль

ИМХО, MFC скоро отомрёт за ненадобностью, в перспективе. Нет, я не спорю, отдельные задачи на нём будут решаться, но скорее всего часть программеров уйдет в Java/.NET а часть приверженная плюсам пойдет в Qt/wxWidgets - надежду всех прогрессивных плюсников