| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > чистый WinApi удобнее MFC |
| Автор: En_t_end 24.4.2005, 14:32 |
| Пришлось тут не давно заняться написанием проги с использованием WinApi. Раньше для создания приложений под win юзал MFC, но как ни странно с WinApi работать на прямую во много раз легче, чем юзать классы MFC, да и код получается более менее понятным. Ты видишь что за чем идет, тебя не беспокоят врубленные по дефолту бесполезные ресурсоемкие фичи, ты просто прогишь. Мой вывод: чистый WinApi удобнее чем классовая оболочка MFC. Да и ещё... о чем интересно думали мелкомягкие, когда делали в MFC мапы сообщений ? крайне неудобно это, удачнее просто использовать цикл с выборкой нужной инфы. У кого какие мысли ? |
| Автор: Alastis 24.4.2005, 15:40 |
| Не могу согласиться... мне кажется утверждение, что WinApi удобнее чем MFC верно только для конкретных задач, в частности, таких как системное программирование... да и то, если приложение довольно громоздкое, то придется писать некую обертку над WinApi для комфортного программирования... Хотя у MFC очень много недостатков, согласен и смерть MFC - это лишь дело времени. И лично я для тех задач, в которых MFC удобнее WinApi предпочитаю VCL:) |
| Автор: En_t_end 24.4.2005, 16:15 |
| Да для работы с "Документ-представление" довольно трудно юзать чистый WinApi, но в остальных случаях он просто идеально подходит. |
| Автор: chipset 24.4.2005, 16:38 |
| Проблема в том, что этих случаев так мало... |
| Автор: rsm 24.4.2005, 23:14 |
| Я шел в полностью противоположном направлении - писал несколько лет на WinApi и VCL и лишь недавно заинтересовался MFC. В процессе ознакомления (а в последствии - и более углубленного изучения) сделал для себя следующие выводы: 1. В стандартной поставке MFC имеется весьма ограниченный набор компонентов. Сравнив стандартный набор компонентов из VС++.NET 2003 и из http://www.winasm.net я с удивлением обнаружил, что первая среда разработки содержит всего на 2  компонента больше! Причем эти компоненты далеко не самые ходовые - календарь и "супер-комбобокс".Разумеется существует огромное количество других компонентов (http://www.codeproject.com) но все они написаны сторонними разработчиками что несколько озадачивает - сильно сомневаюсь что за все N лет существования MFC в Microsoft'e не нашлось ресурсов чтобы сделать побольше компонентов (хотя бы на уровне VCL). 2. Код, выдаваемый "мастером", порой весьма сложен для понимания. Например уже упомянутые мапы сообщений - простое ветвление сообщений гораздо нагляднее и удобнее. 3. Код, который пишешь сам, так же далеко не всегда прост и очевиден. Особенно "нравится" ручное создание переменных для каждого контрола - чрезвычайно "удобно" и "интуитивно". Часто бывает проще написать все родными WinApi чем извращаться с тем что наворочено MFC. 4. MFC слишком низкоуровневая библиотека. Почему например нельзя добавлять страницы в TabControl сразу во время проектирования интерфейса и кидать на них контролы? Вместо этого приходится извращаться стандартным способом (подгрузкой окон диалогов, см. MSDN). Общий вывод: суммируя изложенные выше качества приходим в выводу, что MFС без дополнительных компонентов от сторонних разработчиков очень мало на что способна по сравнению с "голым" WinApi, не говоря уж о VCL. Отвечая на негласный вопрос "а что же юзать?" можно сказать следующее: - если время особо не поджимает и устраивает стандартный интерфейс (без всяких изращений типа разноцветных кнопок, анимированных меню и прочих поющих бирюзовых слоников), то лучше всего будет взять хороший редактор ресурсов (например упомянутный выше http://www.winasm.net) и писать на WinApi; - если время сильно поджимает и\или нужен нестандартный интерфейс тогда лучше всего будет воспользоваться VCL. |
| Автор: AISIN 24.4.2005, 23:21 |
| Сам .exe файл в MFC получается больше! |
| Автор: Fire-Plug 25.4.2005, 04:23 | ||
Идея-то в действительности простая - связать идентификатор сообщения с указателем на ф-цию-обработчиком соотв. события. Если подумать о том, какие варианты решения возможны, с учетом что требовалось разработать нек-рый framework, к-рый можно было бы сравнительно несложно приспособить для конкретного Windows-приложения, то окажется, что их, т.е. решений, не так уж много. Это значит, что требуется: 1) динамический контейнер, в к-рый нужно добавлять элементы (т.е. указатели на ф-ции-обработчики событий) в произвольном порядке, ключом к-рого явл. в общем случае натуральное число (т.е. идентификатор сообщения); 2) обеспечить эффективный поиск элемента в контейнере по ключу-идентификатору сообщения. Вопрос, какой контейнер наиболее полно удовлетворяет данным требованиям? Вот и вылезла-то она, т.е. "мапа", к-рая скорее всего реализована как двоичное дерево, производительность поиска в к-ром - O(log 2 (n)). Если бы мне потребовалось бы разработать некий функциональный framework, то в его основу я так же положил бы "мапу" указателей на ф-ции или еще лучше классов-функторов, в к-рой произвольный элемент разыскивается по его идентификатору. Ну, так чем неудобна "мапа"? Что, std::map - тоже неудобна? ЗЫ: Чтобы быть правильно понятым, также считаю, что MFC - наиболее уродливая библиотека классов среди всех тех, что когда-либо мне встречались. |
| Автор: En_t_end 25.4.2005, 06:39 | ||||
Fire-Plug
| ^
Вот и взаимосвязь. ЗЗЫ я бы предложил вариант со списком, так лично мне удобно В голове содержиться массив int. То есть чтобы найти обработчик, надо просмотреть массив на предмет подходящего номера сообщения. Идентификатор же подходящего члена будет номер члена в списке. То есть сразу переходим к нужному члену списка и обрабатываем... |
| Автор: Nastya 25.4.2005, 13:39 |
| Попробуй WTL, мне понравилось, с одной стороны совершенно APIпрозрачно, с другой все-таки ООП |
| Автор: rsm 25.4.2005, 16:06 | ||
Nastya
Тот же шарик только в профиль  |
| Автор: chipset 27.4.2005, 06:23 |
| ИМХО, MFC скоро отомрёт за ненадобностью, в перспективе. Нет, я не спорю, отдельные задачи на нём будут решаться, но скорее всего часть программеров уйдет в Java/.NET а часть приверженная плюсам пойдет в Qt/wxWidgets - надежду всех прогрессивных плюсников |