мнение All об MFC

Мляяя. Ну понаписали... "Вечная" тема типа...
Постоянно... "Презерватив", "Мастдай", "MFC"... Никому не нравится, все пользуются.
Вот народ!
Презервативы юзаете? Думаю >80 - да.
Мастдай? >99\%, 1\% - не ленивые, упертые, сисадмины либо вообще без компа...
MFC? Аналогично. Думаю, больше 70\% народа его юзает повсеместно.
НИКТО же не просит вас делать веб-серваку или еще чему-нить навороченный GUI?
Да пропади он пропадом блин...
В Мастдае вообще GUI кривой как мой кулер!
Нужен GUI - юзайте DirectX.
Да и вообще... Не нравится - ставь халявБздю и е\%ись с ней на здоровье...
Но нееет. Юзают мастдай...
Особо извращенные еще и билдер 5й... Потом в форуме вопросы типа "Где ошибка?" В ДНК блин, как в том анекдоте.
Народ. Ну ведь давно уже ясно, что MFC - не тормозит. MFC - удобна (И пусть мне плюнет в рожу (а еще лучше - я плюну) тот, кто это сможет опровергнуть и доказать). MFC - всего одна (ну почти) DLL... Которая ЕСТЬ ВЕЗДЕ...
Дальше продолжать? Под мелкософтовские продукты надо юзать мелкософтовские же вещи... Благо выбор небольшой. Ну не котируется это, не котируется. Надо скорость разработки/элементарную прогу - бери VB и разрабатывай. БЭЭЭйсик надеюсь все в школе учили?
Вы бы еще на фортране писали млин...

ЗЫ: Это я по пьяни такой, а обычно я трезвый ;-)))

2ggg
Насчет HWND. Что вы хотели сказать ?
Например смотрим вызов апи функции.
_AFXWIN_INLINE void CWnd::Invalidate(BOOL bErase)
{ ASSERT(::IsWindow(m_hWnd)); ::InvalidateRect(m_hWnd, NULL, bErase); }
Ну и ? Прямой вызов. HWND хранится как переменная класса. Небольшая проверка только в дубуг версии.
Где жуткие тормоза или что ?

насчёт HWND
а в обратную сторону ?
(HWND->this)

дополнение
хоть я и против МФС и давно её не юзаю и больше никогда надеюсь не буду юзать...
но имхо она всё-таки нужна
хотя бы потому что в большинстве коммерческих проектов цель одна - побыстрее и побольше
о качестве (эффективности, ресурсах) в последнее время думают мало (современное железо это позволяет)
ещё насчёт HWND:
простой пример:
если у вас в проге бывает ТОЛЬКО ОДИН экземпляр окна одновременно, то навороченная схема с преобразованием HWND->this вовсе ни к чему. достаточно завести одну статическую переменную. вот так одной переменной херится многокилобайтный код мфс

Коша, ты наш парень !!!
я уже распорядился выдать тебе партбилет, так как круче тебя ещё никто не излагал политику партии

долго терпел но уже не сдержусь...
Развели мля,... флейм...
Типа моя вилка круче сказал один людоед другому....
Не нравиться не пользуй... пиши свое и пинай ногами...
Больше конкретики господа...
PS.
MFC юзает хэш мап для преобразования HWND->CWnd (ну и остальные хэндлы).

Короче, писал (вернее дописывал) прогу для работы с аппаратурой (девайс к компутеру через LPT - порт подключается). Лучше б я ее сразу на VC переписывал! Я не бог весть какой крутой программер, но заметно сразу:обработка сообщений кривая, глюки у CB под 2К просто жуткие, встроенных команд работы с портами нет, надо писать ассеблерную вставку. И тогда всеми обожаемый СВ начинает компилять всю эту херню сперва в ASM ПОЛНОСТЬЮ (!), а потом уж из этого ваять ехе-шник. Как все это тормозит - сами представьте. А насчет MFC - я с ней сразу начал работать, и все нормально, нормальная библиотека, в отличие от VCL - без больших глюков. А насчет скорости - это еще можно поспорить: если в Ваших программах, ув. Dmitry, все сводится к вводу-выводу и счету, то это же можно написать и на MFC / VC, ненамного медленнее. А чтоб совсем быстро и пушисто было - берите какую-нибудь дополнительную библиотеку, напр. для работы с теми же БД, от того же Mabry - получите набор кульных классов.

Тут одну интересную вещь вспомнил. В некоторых статьях выдвигался тезис, что MS не делает нормальный RAD в VC толко потому, что не хочет создавать конкуренции VB. По словам MS, почти 30\% пользователей VC используют именно VB для создания интерфейса, а сложное взаимодействие с API делают на VC. Связывается все это через ActiveX.
К стати в VC7 особых изменений в этом плане нет

Кто-то тут говорил, что одно из достоинств в том, что не надо тащить за собой dll-ки? Хочу заметить, что достоинство это весьма сомнительное, в чем имел возможность убедиться не далее, как сегодня. Хорошо, если модули откомпилированные с использованием Shared MFC DLL переносятся на машину с библиотеками той-же версии или более новыми. А когда они переносятся на машину, использующую старые версии библиотек? Это становится большой проблемой, поскольку легко выдрать и заменить на новые эти библиотеки не так просто. Спасло меня только то, что я имел возможность перекомпилировать все переносимые модули. А если такой возможности нет? Кстати, голая NT Server 4.0 SP6 как раз и явилась виновницей оного торжества, так как в ее поставке идет MFC 4.2 97 года, в отличии от версий, идущих с MSVC++ 6.0 (они там датированны 98-м годом). И, что меня больше всего "порадовало", что функции из того-же MSVCRT.dll экспортируются по ordinal number.

По поводу библиотек в DLL. Если делается просто EXE файл, то особого смысла использовать DLL версии MSF или VCRT нет. Ну будет EXE немного меньше, ну и что? Если размер имеет значение, то действительно имеет смысл использовать только WinAPI (даже без VCRT - в API есть все что надо - работа с фалами, строками, памятю и т.п.).
На мой взгляд использование DLL-версий библиотек более уместно в проектах, состоящих из нескольки DLL. В этом случае все DLL проекта используют общие библиотечные таблицы, а это позволяет, например вызвать new или Create в одном модуле, а delete или FromHandle - в другом. При этом, конечно, возникают проблемы с обновлением библиотечных DLL на других машинах и решение тут одно - делать нормальный дистрибутив - в VisualStudio есть урезанная версия InstasllShield - ее вполне хватает.

В таком случае это - тем более не аргумент в пользу MFC. Все равно все таскать с собой надо )

Цитата

2jcukeng
Вы предлагаете писать GUI на VCL и... Паскале
(aka Delphi) ? Я правильно понял ? Или стоит
юзать Билдер ?

Вы угадали. Да, Дельфи. Не вижу ничего плохого в юзаини "Паскаля". Мы же здесь высказываем свое мнение о библиотеках, а не о языках. То, что некоторые относятся с пренебрежением к "Паскалю" и возносят хвалу VB - это, пардон, прикольно. VB, IMHO, это по крупному счету, средство для использования ActiveX, и довольно-таки убогое средство. О VBA и говорить не стоит:). А Дельфи - это среда разработки + довольно неплохой язык программирования.

Цитата

Когда элементарная прога весит больше метра и так тормозит, становится за себя стыдно.

дык если бы Вы подлинковывали MFC-dlls статически, программа написанная на VC весила бы не намного меньше аналогичной, но написанной на дельфях.
А по части скорости работы таких программ особой разницы нет, если скорость критична, надо юзать API. Нужно писать грамотно, тогда и работать будет быстро.
Далее.
Думать, конечно, неплохо. Сам регулярно этим занимаюсь:). А что касается ламерских вопросов на дельфийской конфе - дык это начинающие программеры их задают. А начать программировать(с нуля) на дельфи гораздо проще, чем на VC, поэтому и начинающих в этой области больше. Понимаете, приложив очень немного усилий, начинающий на Дельфи начнет писать нормальные программы гораздо раньше, чем начинающий VC-программист. А что касается глубокого понимания вопроса - не поверите, мне столько раз доводилось проводить собеседование с кандидатами на должность программиста в нашу фирму - и ни один(!!!) кандидат, не знал что делает цикл while(GetMessage(......))DispatchMessage(...). А среди кандидатов были люди, имеющие сертификат от Microsoft:).
Забавно - про синхронизацию потоков человек знает, а что делает GetMessage - нет.
В общем, глубокое понимание зависит скорее от заинтересованности программиста в оном, а не от того, VCL или MFC он использует.
Рихтера, например, ни один из собеседовавшихся не читал.

Цитата

Я не сомневаюсь, в M$ прграммеры сидят не сильно глупей нас с вами.

дык, умнее они. только MS - потогонка еще та(сведения из вторых рук), вот они и делают баги.
А нитку пора закрывать. Каждый все равно будет пользоваться тем, чем ему удобно. Я - API(в силу харахтера работы)+когда надо -VCL или MFC, под настроение; Вы - MFC.
2 Kosha: Фортран не так уж плох, поверьте. Просто у него специфическая область применения.

Более того, как то раз пришлось мне писать сетевую приладу которая связывалась с машинами через сокеты, причем количество сокетов, естественно, теоретически не ограничено, и каждое новое соединение выделял в отдельный поток. Так вот, в этом случае другого способа кроме того как тащить с собой все DLL я не нашел - при компиляции со статически прилинкованной MFC однозначное обращение к неверному адресу памяти и неминуемый крах.

здравтвуйте.
здраствуйте господа присяжные,
пидарасы,
и прочие девелоперы и хм.
а ниче вы так тут гоните.
про мс чтоли ?
дима.
ты бля че, не наелся серверным софтом мс ?
а ты перееименованый хрен "х" ?
то красново хакера бля увидят, то юсиэл бля
не заменят крякеры ебаные ...

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

ззы.
и не спорьте дети.
не надо.

itz the final countdown ...
ps
окститезь епт.
какой нахуй мкрософт.
itz the final countdown ...