мнение All об MFC

Похоже, MFC принято чаще ругать или игнорировать.
Я начал изучение C++ вместе с MFC одновременно, и пока, в принципе
не пожалел времени на изучение MFC (жаль конечно что у нее очень
слабая работа с GDI,хоть понятно что MFC - суть АПИ в классах , но все равно)
Тем более что это часто и вызывает вопросы. Вот SunteXX спрашивал про
работу с битмэпами. Я глянул, как TCanvas реализован в VCL - очень неплохо.
Если на АПИ (MFC) работать с битмэпом SetPixel- Getpixel (к примеру)
то тормоза будут жуткие. А они создают memDC и работают напрямую.
Но это так, к слову. Не столь уж сложно написать свой класс для этого.
А вобщем, IMHO, работа с сообщениями, сериализация, исключения
и подобное реализовано весьма неплохо.
Вот и хочу услышать мнения о MFC, а то часто слышу, что мол изврат это,
настоящие профи пишут на АПИ. Но АПИ это ж тихий ужас. Пока хотя бы
в свои классы все не упрячеш, будет структурное программирование
со всеми вытекающими... А кто нибудь в СВОИ классы прятал АПИ ?
PS2Flex Ferrum - жаль, но на вашей наводке (OWLNExt)в download уже ничего нет.
То ли переехали, то ли забили.

По поводу OWLNext - извини за ссылку - лучше иди на www.owlnext.org.
А по поводу моего мнения об MFC - ИМХО я ее объектно-ориентированной библиотекой не считаю - максимум это гомогенный набор классов-оберток над API. Жизнь упрощает, конечно, но далеко не всегда. В этом отношении OWL и VCL спроектированны лучше. Помнится, лет n назад мне программисты-MFC'шники пеняли, что, мол, Borland сделал удар ниже пояса своим пользователям не сохранив совместимость между OWL 1.0 и OWL 2.0. На мой взгляд, они поняли, чем будет грозить дальнейшая поддержка и развитие библиотеки в том виде, в котором она была - и провели полный реинжениринг. Правда потом все равно похоронили, но это уже другая история.

Гхм.. Так возникло сразу 2 вопроса, хотелось бы выяснить.
1. Вчера поставил BC 5.02 глянул их иерархию, честно говоря,
серъезных улучшений(vs MFC) не заметил. Почти тоже самое.
Сравнивать качество IDE даже не берусь... Тут VC похоже уехала
далеко и надолго (давно начинал с CBuilder++ 5, недавно поставил -
еклмн... такой отстой (IDE)
2. Качество компилятора. Похоже Борланд не в курсе, что команды
могут спариваться в одном цикле. Компилятор как был прямолинейным,
так и остался (CBuilder 5 использует компилятор BC 5).
А если ж поставить под Visual Studio Intel'овский компилер....
Конечно не всегда важна скорость, но это не маловажно.
Так вот ,подводя итог, хочется найти приличную библиотеку, встраиваемую
в Visual C и совместимую хотя б по расширениям языка, быструю и небольшую.
Может конечно OWLNExt подойдет , надо глянуть.
Интересно, на чем ребята из M$ пишут, не уж то на АПИ. Вот их бы классы
национализировать
Короче ответ на вопрос - кто виноват - однозначен - M$ (Win не объектноориентированная
ОС, а на вопрос что делать - ответа нет.

Давай останемся на уровне обсуждения библиотек. Обсуждение компиляторов - это отдельная песня. Так вот, почему я считаю, что MFC - не ОО библиотека. По той простой причине, что она изначально разрабатывалсь как тонкая обертка над API. А API было ориентировано на использование в процедурных языках, но никак не в ОО. Суть в том, что MFC практически не упрощает работу. Да, она избавляет от рутины. Но ты, как человек, который программировал на VCL и на MFC меня поймешь. Взять хотя-бы работу с CTreeCtrl или TListView (к примеру). А на счет того, что Windows - не объектно-ориетнированная системы - это ты не прав (ИМХО). У конципции окна присутсвуют все признаки, которые определяют объект в ООП (может быть только за исключением абстракций).

А мне MFC нравится. VCL как-то скрывает суть, то что творится внутри. MFC действительно очень тонкая надстройка над API и в этом её плюс. Более менее быстро позволяет разрабатывать обычные приложения, и в то же время позволяет писать что-то системное, не отрывает от API совсем.
Конечно для быстрой разработки сложного многооконного интерфейса VCL вне конкуренции, но писать сервер (не важно какой) я бы стал на MFC.

А вот я бы не стал писать сервер на MFC (особенно сервисы). Богу - богово, а кесарю - кесарево. В консоле нет места GUI'овым библиотекам (какой является MFC).
Не смотря на то, что контроль над внутренней работой программы должен быть, в MFC достаточно темных мест. И все же, у меня давно руки чешуться построить паралельную иерархию для облегчения рутинных операций в работе со списками, деревьями и т. д. и т. п..., вообщем для работы с элементами управления. В конце концов, объекты должны представляться объектами, а не смесью C++ с C. Кстати, именно к этому подталкивает программиста MFC.

2Flex Ferrum:
Ты как-то хитро увязал сервер, сервис, консоль и GUI в одну кучу
согласен только с тем, что консоли и сервисы ваять в MFC не катит, но вот сервер, который должен параллельно обрабатывать теоретически неограниченное количество запросов, и который будет стабильно пахать довольно долгий период времени я б как раз сделал в MFC. Тем более, какая разница, как я его буду запускать - из Автозапуска или как сервис ?

только давайте Яву не будем трогать с ней и так всё ясно!

Интересно, а как ты представляешь себе сервер, запускаемый из автостарта, на площадке у провайдера? Ну да ладно, к делу отношение это имеет опосредованное. Договоримся, что ты имел в виду COM-серверы. )) А насчет использования MFC для этих целей - я скажу так, что в своем коде баги ловить легче, чем в коде MFC. Не гоже запускать программу, рассчитанную на взаимодействие с пользователем, в режиме сервиса без взаимодействия с десктопом. Специфики разные.

Пару слов про subj:
Хм Она все таки объектно ориентирована - но в архитектуре есть очень большие дыры (типа ссылка на нижестоящий в иерархии класс).
Насчет удобства - так за счет визардов всяких выруливает, хотя и ручкам можно с нуля писать.
Самый большой недостаток ее в том что нельзя без геморроя модифицировать поведение классов типа CFrameWnd - кто возился с док-барами тот поймет.

вот как раз COM-серверы я и не имел ввиду с моей стороны речь идёт об обычном приложении, выступающем в роли сервера (почтовый сервер, вебсервер, и т.д.). Таким программулинам незачем взаимодействовать с десктопом. Думаю, что server_mouse тоже самое имел ввиду. И вообще мы с ним думаем одинаково, так как отвращение к VCL у меня в основном из-за её скрытности

2purpe : Именно это я и имел в виду. ))
-------
"Великие умы мыслят одинаково."

Да и в конце концов M$ лишь рекомендует использовать для сервисов консоль, но никак не настаивает....

Чесно говоря, в первый раз слышу о неконсольном сервисе. Может быть еще и драйвера можно с использованием MFC ваять? ))) Кстати, сервис и драйвер с точки зрения НТ очень похожи. Ну да ладно )) Вернемся к нашим баранам.
migel: Я это и имею в виду. В принципе, это можно списать на необходимость поддержки ранних версий, но тогда с этим слабо согласуется изменение интерфейсов классов от версии к версии. Кстати, вопрос, который хотел задать: а какая могла бы быть ОО фреймворк для виндов, который удовлетворил бы максимум народа?

Не согласен с утверждением Flex Ferrum, что MFC исключительно GUI библиотека. Я вот часто пишу консольки с использованием некоторых MFC классов. И ведь действительно облегчает работу! Не то, чтобы даже облегчает, а скорее, ускоряет. Есть, конечно у нее и недостатки, что уж тут греха таить, но ведь и достоинств немало.