мнение All об MFC

2necer:
Я для этих же целей использую string, vector, и т. п. классы из STL и имею гарантию, что написанный сервис можно будет без особого труда перекомпилировать в unix-демон. Кстати, и функционала у них поболе будет.
С OlegO сложно не согласиться, то есть я тоже с ним согласен. Только сдается мне, что MFC можно было бы и иначе спроектировать. Именно поэтому я и говорю, что MFC - это набор классов. С их помощью можно построить практически все что угодно, но из-за того, что где только можно там используются API-подобные конструкции использовать ее не всегда удобно. Вот простой пример. Возмем тотже самый ListView. Чесно говоря, что я его буду заполнять с использованием API, что воспользуюсь для этого MFC - объем кода будет примерно одним и тем же. Хотя по сути дела это обычная коллекция строк или, еще лучше, объектов. Но в MFC нет возможности работать с ListView как с полноценной коллекцией. Спрашивается: почему? Я конечно понимаю, что программист должен иметь максимальный контроль над программой. Но кто мешает встроить в объект как коллекцию так и доступ к ней на уровне API? Кто хочет API - использует один интерфейс, кто коллекцию - другой.

>Но в MFC нет возможности работать с ListView как с полноценной коллекцией
Называется 'сделай сам'. Почему спрашивается для MFC такое огромное кол-во классов (хотя бы на www.codeguru.com)? Кол-во компонентов на 'Королевстве Delfi' куда меньше. В MFC всё ручками. Делаешь однажды и пользуешся всю жизнь.
Конечно сделать и так и так было бы лучше...

Об этом я и говорю. Зачем тогда MFC, если это продукт из серии "после сборки обработать напильником"? Таким макаром я могу написать необходимый мне набор классов используя чистый API. Вот например, STL используется практически всеми программистами на C++, тем не менее такого количества довесков к ней нет. Просто в этом нет необходимости - библиотека предоставляет свои возможности в наиболее удобном для использования варианте. А у Microsoft что API, что MFC - без поллитры не разберешься (если делаешь что-либо нетривиальное).

STL не настолько хорошо документирован, как MFC. И примеров, чтобы разобраться в процессе обучения несравнимо меньше.

Мое мнение о MFC... Это тень Билла Гейтса, это основа Windows без нее все равно никуда не денешься. Как и Билл Гейтс хочет мирового господтва на Земле, так MFC хочет мирового господтва в прогамировании под Windows.

Народ! Не нравиться MFC -- флаг вам в руки и барабан на шею -- есть чистый API. Там возможно все и не столь сложно, как все думают. И файло меньше выходит.

Многие забывают, что MFC появилась очень давно (первая версия в Microsoft C/C++ 7.0 - не Visual C++, а именно Microsoft C/C++ - то, что было до Visual C++ 1.0). Там вообще была MFC для DOS (не окна конечно, но CString, CFile, CArchive и т.п.)
Это было лет 10 тому назад.
Так вот - MFC - это очень старая библиотека, много в ней было сделано из за того, что изначально MS не поддерживала некоторые возможности C++ (например, try / catch - отсюда макросы TRY / CATCH, которые сейчс уже используют орераторы try / catch, но в начале работали через jump).
Ранние версии MFC не умели работать в DLL, да и DLL в Windows 3.1 были савсем другими. И т.д.
Но база кода, созданного с MFC оченю большая. В этом смысле MFC - "FORTRAN" Windows ! Он будет всегда.
С другой стороны начинать использовать FORTRAN в новом проекте не савсем разумно.
На мой взгляд, споры о том, хороша ли MFC - пустая трата времени - она была хотоща 10 лет тому назад, когда до того был только WinAPI + С (или безымный OWL 1.0 + Pascal).
Теперь все меняется, а Microsoft делает .Net...

... Продолжая. По этим же причинам не совсем правильно сравнивать VCL или STL с MFC. Эти библиотеки появились значительно позже. Кроме того Borland действительно "кинула" своих пользователь при переходе c OWL 1.0 на OWL 2.0 (к стати, на мой взгляд OWL 2.0 делалась под сильным впечатлением от MFC, в те времена вообще ходил слух, что MS собирается cудиться с Borland).
А MFC - это прежде всего - СОВМЕСТИМОСЬ. А СОВМЕСТИМОСТЬ - это то, от чего с продуктами Microsoft столько проблем, а с другой стороны, это то, почему ими практически все пользуются.

Серверы.. Сервисы.. .Net... C#...
Это все хорошо, но допустим мне надо в приемлимые сроки написать не слишком навороченную GUI прогу, немного работы с COM портом, немного обработки данных, запись в файл, возможно передача в Excel.
На Delphi VCL писать - не знаю языка,
Builder - ужасная отладка и вообще монстр,
нежто ждать пол-года этого .NET и что он мне собственно дает ? Неужели весь мир сосредоточился на сетях и старые добрые GUI уже никто не пишет ?

Да, мужики... Раз тут мнения высказываем, что-то тоже слово вставить захотелось, из собственного опыта. Где-то до 95-го я с успехом юзал Борланд 4.5, потом годик 5.0, потом МС Визуал С++, последние три года использую его только при срочных задачах и экспериментах. (На билдер только дивлюсь :-))
Вообще говоря, MFC весчь хорошая, и OWL хорошая, (но увы, Борланд, ныне Инпрайз, не создатель сей ОС, а посему хошь-не-хошь проигрывает). Тем не менее, убедился, что фундаментальнее API и удобнее ничего нет.
На мой взгляд, совершенно правы,те, кто высказал мнение, что MFC выигрывает при разработке стандартного ПИ. Добавлю, еще, что МФС прекрасно документирован, лучше чем функции и структуры АПИ и уж тем более стандартная С-библиотека. (Вероятно, по той самой причине, которая здесь так-же прозвучала: "ВСЕ ТОЛЬКО В МФС", а для остальных - особо умных - "грузить чугундий" - т.е. работать с меньшим комфортом). Но после того, как построишь свою собственную библиотечку поддержки, то лучше АПИ ничего нет. И приложения строить не менее оперативно можно. Ну и надо еще добавить, что МФС вообще говоря коммерческий продукт и не дешев :-((
А на АПИ - хоть Сигнусовский компилер используй (и их же либу ГНУшную). Да и потом, никто не может жить вечно... Это я к тому, что если пройти ч/з эти задачки, в Линуксе под иксами, писать одно удовольствие. Да, и QT очень неплохая библиотека есть, кстати, идеологически, очень похожа на МФС. Вот и ежели что случиться, без МФС и Виндов проживем.
А пока, думаю, все имеют право на жизнь.
Всем привет,
Сергей - СЕРП.

Hi everybody!
Спокойнее, господа, спокойнее! Здесь не место для публичных
икзекуций иноверцев. Здесь место, где в основном тусуются
фанаты от MFC, т.е _МЫ_. А стало быть нам не к лицу мочить
наших же гостей из Дельфинария в нашем же доме.
Я тоже писал проги и на Delphi и на C++ MFC. После нескольких
затяжных раздумий о смысле жизни пришел к выводу, что нельзя
сравнивать эти два "станка" для обработки байтоподобной
информации. У них несколько разное назначение. Все равно,
что сравнивать ложку и вилку. Да это два инструмента для
переноса пищи в рот и у каждого свое назначение. Кроме того,
в мире существуют такие блюда и народы, что диву даешься.
Например, в Средней Азии плов едят руками... :/
Так вот, господа, что я вам могу сказать опираясь на свой опыт.
Если у вас стоят задачи написать прогу для бухгалтерии или
какой-нибудь подобной области, где оперируют такими понятиями
как "число", "математическая операция или функция", файл данных,
"поле ввода", "кнопочка" и т.д., то для этой цели лучше подойдет
Делфя. Обработка данных из баз данных -- тоже Делфя. Делфи
хороша там , где нужно быстро наваять прогу с Кнопочками-
бантиками-фантиками и прочей GUI-шной лабудой, где обработка
в основном связана с математикой.
С другой стороны VС++, хотя и позволяет делать это же и даже
еще лучше, но он не очень эффективен в свете "нарубить капуски".
Пока вы будете вылизывать ваш код в MFC, пройдет время, и
ваш потенциальный покупатель купит продукт у Делфиста.
На VC++ MFC следует создавать продукты только такие, которые
имеют длительный цикл жизни (много-много версий).
Вообще, на сколько я понимаю, мир должен быть устроен как-то
проще.
Между тем, нельзя сказать, что _ТАМ_ (за океаном) у них
господствует Borland. Скорее наоборот -- Microsoft. А почему,
собственно? Да потому, что у M$ денег больше. А почему их оказалось
больше? Да потому, что они окучивают рынок _промышленности_
(США и не только США), а Borland -- он изначально позиционировал
свои продукта в область эдюкейшина. А на каком рынке денег
больше? Соответственно, какая из компаний могла больше денег
тратить на научные работы в области разработки программного
обеспечения?
Теперь еще одно замечание. Ищем папу! Кто дал жизнь Делфям?
-- Паскаль. А С++? -- С. А он-то откуда пришел? От ассемблера.
Конечно, другие языки тоже оказали свое влияние, но "генеральная
линия партии" видна. Какие основные задачи решал "Паскакаль"?
Учебные и расчетные, типа плюс-минус-умножить-разделить.
А Ассемблер-Си-С++? В основном задачи системного характера,
распределение/управление памятью, чтение/запись в порт/регистр,
вызов 21-го прерывания в ДОСе и т.д.
Ну что же вы хотите? Разное назначение у этих языков! Другое дело
то, что каждый из них пытается вторгнуться на чужую территорию.
Из-за этого сложно принять правильное решение в выборе, они
начинают походить друг на друга. Но, я думаю, надо "зрить в корень"
проблемы, а не ломать комедию: "что лучше - что хуже".
Допустим, у общества появилась потребность в программе Х.
Быстренько сели, набарабанили на VB или Delphi косую-кривую
прогу и продали ее сотне клиентов со словами извинения, за ее
глюкавость. А за одно пообещали, что следущая версия уже не
будет иметь замеченных глюков и обойдется ровно в два раза
дешевле тем, кто купил первую. Ну кому от этого плохо? Вам -- нет!
Вы уже "нарубили капуски". Клиентам -- тоже нет! Они уже могут
что-то делать (хотя и криво-косо), т.е. их бизнес не остановился!
Плохо конкурентам! Он пишут прогу на MFC. Она будет готова
через несколько недель. Цена у нее будет дороже, потому как
ее писали дольше. Зряплата у программеров примерно одинаковая.
Кто ее купит? А вот после того, как вы "заполучили клинта" нужно
быстренько переносить свой продукт в среду С++. Клиент еще
долго не убежит от вас.
Между прочим, кто-нибудь знает, что первая версия виндов была
написана на ... Microsoft Pascal. Ну а если все так хорошо с Паскалем,
то почему следущие версии Виндов писались на С?
Между прочим, кто-нибудь знает, что Anders Hejlsberg -- разработчик
самого лучшего (по тем временам) компилятора TurboPascal,
разрабатывал компилятор для Delphi? А знает ли кто-нибудь, что после
третьей версии Делфей Андрюша свалил из Борланда? А кто-нибудь
знает, куда он свалил и какие продуты он потом извоял? Тому, кто
действительно не знает -- зайдите на сайт M$ и почитайте прессу.
Вы будете приятно удивлены вашим выбором языка
программирования.
А знаете ли вы, что _там_ Борланд не в почете? А знаете ли вы,
что _там_ у программистов не стоит проблема выбора С++ или
Делфя? Что они (почти) все помешаны на идее личного обогащения.
Это при том, что на Делфи можно быстро настругать много программ.
Значит не в Делфях счастье?! И даже не в МС++! Оно -- в другой
плоскости. Мы, в России, а не в Америке. И хоть Путин месяц назад
обронил фразу, дескать в России будут введены какие-тольготы
программистам (видимо, что б мы _туда_ срывались). Но оно, как-то
не вериться. Каждый второй программер мечтает поработать за
доллары. Посмотрите заокеанские сайты работодателей, кто-нибудь
спрашивает писателей на Delphi? Везде UNIX, VC++, Java и другие
"сетевые" языки. О чем это говорит?
Вывод такой. Если вас не интересует долгосрочное сотрудничество с
клиентом -- пишите на Делфи. Это проще, дешевле и быстрее. Все
остальное не относится к категории "продал и свалил с рынка".
Рынок нужно держать, за него нужно биться. А для этого нужен
хороший инструмент. Не знаете какой? Посмотрите на чем пишут
не русскоязычные программеры. К нам это тоже прийдет от _туда_,
если каждый второй из нас не сорвется _туда_ раньше.
У меня много вопросов к VC++ и MFC намного сложнее в изучении,
но к Делфям я стараюсь не возващаться. "Чтобы чувствовать себя
комфортно в некоторой технологии -- требуется понимать ее"
(Charles Calvrt). Не многим Делфистам (простим их великодушно!)
удалось понять и освоить VC++ и MFC. Вот и разгоратся споры --
что лучше, а что хуже.
Александр Жевак

И всё же, для того, чтобы облегчить общение с API UI функциями, существенно не утежеляя результирующий код, MFC прекрасно подходит. От этого особо страдают Borland'овские библиотеки. Все могут сказать, что на размер проги сейчас можно положить, но я как-то привык...
А то, как деструкторы классов помогают избежать resource leaks, комменты излишни!

Итак, подведа некоторые итоги можно сказать, что мнение All об MFC переросли, как это обычно бывает, в дискуссию Borland vs Microsoft или BCB/Delphi vs VC++, что, ИМХО, суть уход от темы. Мы обсуждаем библиотеку как библиотеку, а не как приложение к конкретному компилятору. Не для кого не секрет, что версии MFC есть и для борлондавских компиляторов, под Ваткомом она работала и т. п (чего, кстати, нельзя сказать о VCL). Речь не об этом. Хорошо использовать библиотеку, когда в среде есть куча визардов, делающих за тебя основную рутину. Тогда, в принципе, и подобных тем не должно возникать - библиотека будет удобна априори. Суть в другом.
Я утверждаю, что мне эта билиотека не удобна как программисту, использующему ее без применения автоматизации. Да, согласн, в данном случае большим достоинством является то, что билиотека максимально приближена к АПИ. Удобно. Не надо менять систему понятий (как например, для той-же VCL), суть кода будет, что называется, интуитивно понятной. Проблема в другом - даже с использованием MFC кода получается много. Как я уже говорил раньше, в некоторых аспектах своего использования MFC нисколько не помогает программисту (пример я уже приводил).
Хотя, наверняка, не стоит требовать от продукта больше, чем он способен дать. Но, на мой взгляд, это некоторое издевательство над программистом. Мы дадим вам неудобный инструмент для работы (а-ля ненаточенную пилу), но звиняйте братцы - другого нет, а по этому придется этой пилой пилить толстенное дерево, предварительно обработав напильником. Но денюжек за эту пилу мы все равно много попросим - продукт то профессиональный ).
По поводу того, что не надо сравнивать с STL или VCL - сравнивать надо, но в определенной плоскости. Сравинвать надо не с точки зрения функционального назначения (это бессмысленно), а с точки зрения качества построения концепции что-ли... Все это - ОО библиотеки. И не гоже, когда С++ применяется исключительно как надстройка над C.

Подождите.. Разве если покупая VC++ (что то порядка $2000 кажется) мне разве MFC автоматом не предлагается ? Они вроде даже поощряют вносить изменения в исходный код ( только распространять под другим именем тогда ). И сколько ж она тогда сама по себе то стоит ? За денежки то дело другое :-) За денежки я еще подумаю, использовать ли ее...
Я где то читал, что если нашегому человеку надо нарисовать табуретку, он бежит на рынок за последней версией автокада. Может и эта "проблема" тогда той же серии ?

Кстати спасибо 2Александр Жевак, не пожалел времени на длинный рассказ.
Тока я не понял
Вы будете приятно удивлены вашим выбором языка
программирования - подробней можно ?
А вы на чем пишите сейчас ?