опубликован 17-01-2002 10:38 MSK            

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

если интересно моё личное мнение:

1)я против MFC (см. далее)

2)имея большой опыт программирования на API очень быстро создаются те вещи, которые предлагает MFC (т.е. MFC практически не ускоряет процесс создания программ)

3)вставляя прослойку ЧУЖОГО кода, вы увеличиваете размер программы и вероятность глюков

4)при повышении универсальности обязательно снижается эффективность; MFC универсальная библиотека, разработанная для применения в самых разных проектах, а значит она не является максимально адаптированной под ваш конкретный проект; т.е. используя МФС вы снижаете эффективность вашей программы
(а вы не задумывались, как происходит связь между HWND и this?? прежде чем посмотреть исходники МФС возмите тряпочку чтобы стирать слюни с монитора)

5)используя МФС вы, например, не контроллируете основной цикл сообщений (иногда это создаёт проблемы, которые не кривыми способами решить невозможно)

6)С++ может быть очень низкоуровневым языком, а может быть и очень извращённым, похожим на паскаль или бейсик; МФС сдвигает его как раз в сторону последних (вспомните хотя бы навязанные классы исключений и сами исключения)
(кстати а многие ли поклонники МФС обрабатывают эти исключения? а вы сами их обрабатываете? а вы вообще знаете что это такое? а вы знаете что в МФС бесполезно проверять new char[size] на NULL? а вы знаете, что большинство ГУЁвых классов МФС могут бросать исключения? у вас теперь не изменилось мнение о стабильности вашей программы?)

7)какая бы большая ни была библиотека, API всё равно разнообразнее и дают больше возможностей, а значит позволяют делать более разнообразные и оригинальные проги, эффективнее использовать систему

jcukeng опубликован 11-12-2001 08:48 MSK
--------------------------------------------------------------------------------
Привет всем!
Возражения апологетам Microsoft(R) MFC(TM).
1.По поводу
[quote]
Если VС++ стоит дорого, значит он столько
и стоит!...
Так что, я думаю,
наша азиатская страна не может быть "лакмусовой
бумажкой" в вопросах оценки качества продукта.
[/quote]
А не кажется ли многоуважаемому All, что тот факт, что на дельфи в нашей стране больше (или, во всяком случае, не меньше) программируют, чем на VC (при одинаковой цене на эти продукты :Ж) ) как нельзя лучше говорит от том, что есть что?
2. Далее, кто-нибудь из сторонников MFC изучал сорсы CAsyncSocket/CSocket? Тогда вы в курсе, что писать в такие сокеты из разных нитей если не невозможно, то связанно с колоссального размера геморроем.

3.
[quote]
Я вот часто пишу консольки с использованием некоторых MFC классов. И ведь действительно облегчает работу! Не то, чтобы даже облегчает, а скорее, ускоряет.
[/quote]
Ускоряет? Вот win2k, судя по всему, почти все аж на VB написано, GUI, во всяком случае, уж точно:). Ускорение - просто летать стала по сравнению с WinNT. Попой вперед. (дамы, пардон ми)

4. Выше были реплики. Теперь подойдем систематически.
Рассмотрим отдельно две сферы программирования:
а)системное программирование
б)написание прикладных GUI-программ
и оценим удобство/надежность MFC как инструмента для реализации каждого из видов программ.
А. Использование MFC для написания служб/драйверов не только неправильно, но еще и глупо - нельзя же ради какого-то класса CString и ему подобных использовать в серьезной программе либу, которая 1) немало весит и 2) ненадежна. Предвидя возражения по поводу ненадежности - напишите многопоточную прогу которая использует более-менее много классов MFC и погоняйте ее в NuMega Bounds Checker'е. Очень прикольно и поучительно.
Посему писать системные программы нужно на чистом апи плюс (при достаточно уважительной причине) STL. Кстати, апи тоже не весь юзать можно. ShellAPI, например, не стоит; а в особо серьезных программах не стоит использовать и ф-ии из user32.dll.
[отступление. для ценителей среды MS VC, в частности еённого дебуггера:).
пробовал ли кто-нибудь отлаживать программы, использующие STL и делать "trace into" в эти шаблоны? далее, при запуске такой программы в дебаг моде не показываются некоторые memory leaks после завершения отладки.
[/конец отступления]

Б. Написание GUI-приложений.
Спорить не стану, использовать MFC для этой цели _можно_. Но, пардон, вспомните, с какими траблами связана, казалось бы, такая мелочь - организация fullrowselect'а в листконтроле, размещенного на диалоговой форме. И так по мелочам. Тут говорилось о кубиках. Так вот, согласен, VCL - это разноцветные кубики разных размеров. А MFC - это круглые кирпичи + несколько отдельных типовых молекул:).
Проблема программирующих интерфейсы на VCL заключается не в том, что VCL плох, а в том, что перед тем как писать программу, нужно подумать, спроектировать ее, в конце концов. А люди ленятся - они привыкают, что сложные с точки зрения MFC-программиста вещи делаются двумя щелчками мышки - и некоторые(подсознательно? :))считают, что и думать за них компьютер должен. А программисту, использующему MFC думать нужно. И много думать. Ведь в MFC сделать потомка от CDialog'а с возможностью изменения размеров непросто. А чтоб добавить в CTreeControl элемент -минимум строк десять написать надо. Чуть поменьше чем на API. И т.д. и т.п.

Вывод.
Для написания GUI-приложений следует использовать VCL. Склонные к мазохизму и располагающие временем могут использовать MFC; кроме того, его глюкавость здорово стимулирует интерес к чтению MSDN.
Для написания системных программ нельзя использовать ни то, ни другое.
-------
Замечу, что про написание COM/ActiveX я ничего не говорил намеренно - я не специалист в этой области. И не мне судить.
--

enigma опубликован 11-12-2001 18:39 MSK
--------------------------------------------------------------------------------
2 purpe:
Короче, увидел эту рубрику и решил почитать...
Дочитал до высказывания PURPE о том что мол Web-server на MFC легче и лучше. А ты задумайся, сколько простоит в сети такой сервер???? (естественно, даже если не вмешиваться из вне. на мой взгляд, тут проблема состоит в том, что MFC приходится взаимодействовать с Windows, что само по себе не долговечно). Желаю удачи в работе с такими серверами!!!

purpe опубликован 11-12-2001 21:01 MSK
--------------------------------------------------------------------------------
ну так ... это ....
я ж не собираюсь запускать вебсервак в 98-ых :)
ясный пень, что без всяческих примочек сервак долго не простоит :)
WinNT+грамотнонастроенный AtGuard+выбивание из NT лишней дури+грамотная настройка NT+а ещё NT можно посадить за проксю.... и т.д.

кароче, четыре месяца ентот сайт просидел без перезагрузки при посещаемости 700-800 хостов в сутки.

Чем больше возможностей в программе, тем быстрее она упадёт. Так что если сделать вебсервер безо всяких наворотов (типа апача) то енто хозяйство очень даже стабильно пашет!!!

А реплики админов, которые даже не представляют, как защитить NT от взлома - не принимаются!

jcukeng опубликован 11-12-2001 22:10 MSK
--------------------------------------------------------------------------------
Скорее всего, имелось в виду, что в таком веб-серваке будет куча дырок, например, типа buffer overflow vulnerability. Так что прикрытие портов гвардом не поможет (не будем обсуждать дырки в самом гваде:) ).

DmitryRyvkin опубликован 11-12-2001 23:23 MSK
--------------------------------------------------------------------------------
2jcukeng
Вы предлагаете писать GUI на VCL и... Паскале
(aka Delphi) ? Я правильно понял ? Или стоит
юзать Билдер ? Если так, тогда программер
не только мазохист, но и садист.
Когда элементарная прога весит больше метра и так тормозит, становится за себя стыдно.
Что же касается неудобства ListView (а причем тут его размещение на диалоге ?)
, то давно есть дополнения к MFC, создающие свои аналоги с более удобным интерфейсом (то же что и VCL). А MFC этих прибамбасов не предоставляет и правильно делает. Может им еще и Chart запихать туда ?
И все таки не могла библиотека равиваться 10 лет , если она такая тупая, ненужная и глючная.
Я не сомневаюсь, в M$ прграммеры сидят не сильно глупей нас с вами.
Повторяю, нет ни у кого восторгов от MFC, но голым API сейчас не отделаешся.
А замечание, что когда пишеш на MFC приходится куда больше думать, чем в VCL верно. Разве это плохо ? Посмотрите на кофы дельфистов. Конечно есть серьезные вопросы, но чаще - как подвинуть/ изменить размер формы.. итд итп. На MFC такого вопроса не возникнет - иначе до этого момента просто не дойдеш.

Kosha опубликован 12-12-2001 12:17 MSK
--------------------------------------------------------------------------------
Мляяя. Ну понаписали... "Вечная" тема типа...
Постоянно... "Презерватив", "Мастдай", "MFC"... Никому не нравится, все пользуются.
Вот народ!
Презервативы юзаете? Думаю >80 - да.
Мастдай? >99%, 1% - не ленивые, упертые, сисадмины либо вообще без компа...
MFC? Аналогично. Думаю, больше 70% народа его юзает повсеместно.

НИКТО же не просит вас делать веб-серваку или еще чему-нить навороченный GUI?
Да пропади он пропадом блин...
В Мастдае вообще GUI кривой как мой кулер!
Нужен GUI - юзайте DirectX.

Да и вообще... Не нравится - ставь халявБздю и е%ись с ней на здоровье...

Но нееет. Юзают мастдай...
Особо извращенные еще и билдер 5й... Потом в форуме вопросы типа "Где ошибка?" В ДНК блин, как в том анекдоте.

Народ. Ну ведь давно уже ясно, что MFC - не тормозит. MFC - удобна (И пусть мне плюнет в рожу (а еще лучше - я плюну) тот, кто это сможет опровергнуть и доказать). MFC - всего одна (ну почти) DLL... Которая ЕСТЬ ВЕЗДЕ...

Дальше продолжать? Под мелкософтовские продукты надо юзать мелкософтовские же вещи... Благо выбор небольшой. Ну не котируется это, не котируется. Надо скорость разработки/элементарную прогу - бери VB и разрабатывай. БЭЭЭйсик надеюсь все в школе учили?

Вы бы еще на фортране писали млин...

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

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

ggg опубликован 12-12-2001 09:16 MSK
--------------------------------------------------------------------------------
насчёт HWND
а в обратную сторону ?
(HWND->this)

ggg опубликован 12-12-2001 09:30 MSK
--------------------------------------------------------------------------------
дополнение
хоть я и против МФС и давно её не юзаю и больше никогда надеюсь не буду юзать...

но имхо она всё-таки нужна

хотя бы потому что в большинстве коммерческих проектов цель одна - побыстрее и побольше
о качестве (эффективности, ресурсах) в последнее время думают мало (современное железо это позволяет)

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

purpe опубликован 12-12-2001 09:33 MSK
--------------------------------------------------------------------------------
Коша, ты наш парень !!!
я уже распорядился выдать тебе партбилет, так как круче тебя ещё никто не излагал политику партии :)

migel опубликован 12-12-2001 16:34 MSK
--------------------------------------------------------------------------------
долго терпел но уже не сдержусь...
Развели мля,... флейм...
Типа моя вилка круче сказал один людоед другому....
Не нравиться не пользуй... пиши свое и пинай ногами...
Больше конкретики господа...
PS.
MFC юзает хэш мап для преобразования HWND->CWnd (ну и остальные хэндлы).
iscander опубликован 13-12-2001 09:45 MSK
--------------------------------------------------------------------------------
Короче, писал (вернее дописывал) прогу для работы с аппаратурой (девайс к компутеру через LPT - порт подключается). Лучше б я ее сразу на VC переписывал! Я не бог весть какой крутой программер, но заметно сразу:обработка сообщений кривая, глюки у CB под 2К просто жуткие, встроенных команд работы с портами нет, надо писать ассеблерную вставку. И тогда всеми обожаемый СВ начинает компилять всю эту херню сперва в ASM ПОЛНОСТЬЮ (!), а потом уж из этого ваять ехе-шник. Как все это тормозит - сами представьте. А насчет MFC - я с ней сразу начал работать, и все нормально, нормальная библиотека, в отличие от VCL - без больших глюков. А насчет скорости - это еще можно поспорить: если в Ваших программах, ув. Dmitry, все сводится к вводу-выводу и счету, то это же можно написать и на MFC / VC, ненамного медленнее. А чтоб совсем быстро и пушисто было - берите какую-нибудь дополнительную библиотеку, напр. для работы с теми же БД, от того же Mabry - получите набор кульных классов.
al опубликован 13-12-2001 10:26 MSK
--------------------------------------------------------------------------------
Тут одну интересную вещь вспомнил. В некоторых статьях выдвигался тезис, что MS не делает нормальный RAD в VC толко потому, что не хочет создавать конкуренции VB. По словам MS, почти 30% пользователей VC используют именно VB для создания интерфейса, а сложное взаимодействие с API делают на VC. Связывается все это через ActiveX.
К стати в VC7 особых изменений в этом плане нет
Flex Ferrum опубликован 13-12-2001 14:00 MSK
--------------------------------------------------------------------------------
Кто-то тут говорил, что одно из достоинств в том, что не надо тащить за собой dll-ки? Хочу заметить, что достоинство это весьма сомнительное, в чем имел возможность убедиться не далее, как сегодня. Хорошо, если модули откомпилированные с использованием Shared MFC DLL переносятся на машину с библиотеками той-же версии или более новыми. А когда они переносятся на машину, использующую старые версии библиотек? Это становится большой проблемой, поскольку легко выдрать и заменить на новые эти библиотеки не так просто. Спасло меня только то, что я имел возможность перекомпилировать все переносимые модули. А если такой возможности нет? Кстати, голая NT Server 4.0 SP6 как раз и явилась виновницей оного торжества, так как в ее поставке идет MFC 4.2 97 года, в отличии от версий, идущих с MSVC++ 6.0 (они там датированны 98-м годом). И, что меня больше всего "порадовало", что функции из того-же MSVCRT.dll экспортируются по ordinal number.
al опубликован 13-12-2001 16:37 MSK
--------------------------------------------------------------------------------
По поводу библиотек в DLL. Если делается просто EXE файл, то особого смысла использовать DLL версии MSF или VCRT нет. Ну будет EXE немного меньше, ну и что? Если размер имеет значение, то действительно имеет смысл использовать только WinAPI (даже без VCRT - в API есть все что надо - работа с фалами, строками, памятю и т.п.).
На мой взгляд использование DLL-версий библиотек более уместно в проектах, состоящих из нескольки DLL. В этом случае все DLL проекта используют общие библиотечные таблицы, а это позволяет, например вызвать new или Create в одном модуле, а delete или FromHandle - в другом. При этом, конечно, возникают проблемы с обновлением библиотечных DLL на других машинах и решение тут одно - делать нормальный дистрибутив - в VisualStudio есть урезанная версия InstasllShield - ее вполне хватает.
Flex Ferrum опубликован 13-12-2001 17:08 MSK
--------------------------------------------------------------------------------
В таком случае это - тем более не аргумент в пользу MFC. Все равно все таскать с собой надо :))
jcukeng опубликован 13-12-2001 17:28 MSK
--------------------------------------------------------------------------------
[quote]
2jcukeng
Вы предлагаете писать GUI на VCL и... Паскале
(aka Delphi) ? Я правильно понял ? Или стоит
юзать Билдер ?
[/quote]
Вы угадали. Да, Дельфи. Не вижу ничего плохого в юзаини "Паскаля". Мы же здесь высказываем свое мнение о библиотеках, а не о языках. То, что некоторые относятся с пренебрежением к "Паскалю" и возносят хвалу VB - это, пардон, прикольно. VB, IMHO, это по крупному счету, средство для использования ActiveX, и довольно-таки убогое средство. О VBA и говорить не стоит:). А Дельфи - это среда разработки + довольно неплохой язык программирования.
[quote]
Когда элементарная прога весит больше метра и так тормозит, становится за себя стыдно.
[/quote]
дык если бы Вы подлинковывали MFC-dlls статически, программа написанная на VC весила бы не намного меньше аналогичной, но написанной на дельфях.
А по части скорости работы таких программ особой разницы нет, если скорость критична, надо юзать API. Нужно писать грамотно, тогда и работать будет быстро.
Далее.
Думать, конечно, неплохо. Сам регулярно этим занимаюсь:). А что касается ламерских вопросов на дельфийской конфе - дык это начинающие программеры их задают. А начать программировать(с нуля) на дельфи гораздо проще, чем на VC, поэтому и начинающих в этой области больше. Понимаете, приложив очень немного усилий, начинающий на Дельфи начнет писать нормальные программы гораздо раньше, чем начинающий VC-программист. А что касается глубокого понимания вопроса - не поверите, мне столько раз доводилось проводить собеседование с кандидатами на должность программиста в нашу фирму - и ни один(!!!) кандидат, не знал что делает цикл while(GetMessage(......))DispatchMessage(...). А среди кандидатов были люди, имеющие сертификат от Microsoft:).
Забавно - про синхронизацию потоков человек знает, а что делает GetMessage - нет.
В общем, глубокое понимание зависит скорее от заинтересованности программиста в оном, а не от того, VCL или MFC он использует.
Рихтера, например, ни один из собеседовавшихся не читал.
[quote]
Я не сомневаюсь, в M$ прграммеры сидят не сильно глупей нас с вами.
[/quote]
дык, умнее они. только MS - потогонка еще та(сведения из вторых рук), вот они и делают баги.
А нитку пора закрывать. Каждый все равно будет пользоваться тем, чем ему удобно. Я - API(в силу харахтера работы)+когда надо -VCL или MFC, под настроение; Вы - MFC.
2 Kosha: Фортран не так уж плох, поверьте. Просто у него специфическая область применения.

enigma опубликован 13-12-2001 17:58 MSK
--------------------------------------------------------------------------------
Более того, как то раз пришлось мне писать сетевую приладу которая связывалась с машинами через сокеты, причем количество сокетов, естественно, теоретически не ограничено, и каждое новое соединение выделял в отдельный поток. Так вот, в этом случае другого способа кроме того как тащить с собой все DLL я не нашел - при компиляции со статически прилинкованной MFC однозначное обращение к неверному адресу памяти и неминуемый крах.
lamo опубликован 13-12-2001 18:55 MSK
--------------------------------------------------------------------------------
здравтвуйте.
здраствуйте господа присяжные,
пидарасы,
и прочие девелоперы и хм.

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

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

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

lamo опубликован 13-12-2001 19:13 MSK
--------------------------------------------------------------------------------
itz the final countdown ...
ps
окститезь епт.
какой нахуй мкрософт.

itz the final countdown ...

lamo опубликован 14-12-2001 02:09 MSK
--------------------------------------------------------------------------------
черт.
вот придэш с утра - и ужас.
пора бухать бросать.
ну это ... я подписываюсь под каждым своим
словом ...
но извиняюсь за 6(шесть) своих слов. (не буду перечислять =)).

зы.
дим. можеш грохать весь мой гон,
но ваш базар всеравно ни к чему не приведет.

ззы.
ну ваше дело.
я не виноват, что только пьяным сюда хожу.

зззы.
благодарности принимабтся =).

stan опубликован 14-12-2001 13:37 MSK
--------------------------------------------------------------------------------
Народ, вот тут много рассуждений, а между тем, мне, например, интересно узнать - кто-нибудь РЕАЛЬНО сравнивал скорость разроботки приложения на MFC и (например) VCL. Мой опыт показывает, что большая часть времени уходит не на написание клиентского кода, а на его отладку, написание серверной части кода (я базами данных занимаюсь) и на решение вопроса , чего же хочет заказчик. В такой ситуации разве очень большое значение имеет некотарая тормознутость разработки (несомненно, присущая MFC по сравнению с VCL)? Или я не прав? Вообще кто-нибудь может привести реальное сравнение времени и затрат труда?
lamo опубликован 14-12-2001 14:13 MSK
--------------------------------------------------------------------------------
тз проекта:
серв. часть - веб, оракл.
клиент. часть - хттп клиент.
адм. часть - мс апликэшн.
ракло - ~30 tables, 12 packages, ~60 stored
procedures, functions, triggers.
web - ~60000 рабочего клиентского кода.
адм апликэшн - 1-я версия VCL. вторая - MFC.

в первом случае (VCL) разработка адм части заняла
процентов 10 от общего времени разработки.
во втором случае (MFC) - 30.

ps.
делаем выводы.
т.е.
вывод только один - нужно опохмеляться.

vik опубликован 17-12-2001 14:27 MSK
--------------------------------------------------------------------------------
Я лично дома пишу на Дельфи, а на работе - на VC. Мое мнение: MFC - библиотека, не дающая программисту никаких преимуществ. Чем использовать ее, лучше писать под голым API.
Что ее изучать, что API - одинаковая сложность и одинаковый размер исходного кода.
Что касается размера exe-шника, то добавление одного только класса CString добавляет к его размеру больше, чем все стандартные Дельфийные объекты.
Потому при написании под Дельфями я использую ее библиотеку (хотя можно писать и под голым API, но гораздо менее удобно), а под VC - под голым API (MFC преимуществ по сравнению с API не дает, а объем тянет).
А когда необходимо сделать что-нибудь действительно хитрое, то часто лезу в исходники VCL, посмотреть, "а как это сделано у Борланда".

eyes опубликован 17-12-2001 17:07 MSK
--------------------------------------------------------------------------------
Я можетъ и не dogаняю что... но...
Мля ситьюэйшн... диалог надо спросить... это как? в MFC:

СMyDialog dlg;
if (dlg.DoModal() == IDOK)
{
// обработаем ща...
}

// и тд и тп ну чо в винапи будем делать....

я может лишку перепил... но у меня есть повод...
как там на счет это быстро под апи...

Flex Ferrum опубликован 17-12-2001 17:13 MSK
--------------------------------------------------------------------------------
Нет ничего проще:
if (DialogBox(hinst,
MAKEINTRESOURCE(DLG_DELETEITEM),
hwnd, (DLGPROC)DeleteItemProc)==IDOK)
{

// Complete the command; szItemName contains the
// name of the item to delete.

}

Не веришь - посмотри в MSDN.

Flex Ferrum опубликован 17-12-2001 17:16 MSK
--------------------------------------------------------------------------------
Да, забыл, функция окна для этого диалога:
char szItemName[80]; // receives name of item to delete.

BOOL CALLBACK DeleteItemProc(HWND hwndDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_COMMAND:
switch (LOWORD(wParam))
{
case IDOK:
if (!GetDlgItemText(hwndDlg, ID_ITEMNAME,
szItemName, 80))
*szItemName=0;

// Fall through.

case IDCANCEL:
EndDialog(hwndDlg, wParam);
return TRUE;
}
}
return FALSE;
}

stan опубликован 17-12-2001 21:21 MSK
--------------------------------------------------------------------------------
Подводя очередной итог:
MFC - фигня с кноголетним стажем(а потому заслуживающая почтения), процесс разработки ускоряет, но не сильно, упрощает, но не очень.
Для любителей быстрой разработки интерфейса не подходит.
То есть если хочешь писать нормальные, стабильные проги use API, STL, ATL, WTL.
MFC - нафиг, за исключением суперстандартных приложений, которые неплохо генерятся визардом.
eyes опубликован 18-12-2001 09:27 MSK
--------------------------------------------------------------------------------
2FlexFerrum:
ну и какой смысл городить этот код для приложения, расчитанного на взаимодействие с пользователем. Таких диалогов там под сотню, а то и больше. Для каждого писать оконную функцию... согласитесь, это долго и нудно (дольше и нуднее). Не вижу смысла использовать апи.

может вы мне докажете что код под апи надежнее (в данном случае)?

*Сервисы, драйверы не пишу. Согласен, что для них надо использовать только апи*

Flex Ferrum опубликован 18-12-2001 10:29 MSK
--------------------------------------------------------------------------------
В программировании на API - своя специфика. И оконную функцию под каждый диалог писать не обязательно - просто нужно немного подумать. И все.
Qwertyu опубликован 18-12-2001 13:43 MSK
--------------------------------------------------------------------------------
Господа, Вы плац ломами не подметаете?
MFC, по-моему мнению, заточена под
"документ/представление". Для остальных задач
см. выше.
Базы данных? Delphi, VB
Числодробилка - вполне Borland Pascal 7.0 подойдет.
Интерфейс - VB + COM , Delphi
COM - ATL.
Драйвера - ASM.
Или не перевелись еще мазохисты на земле русской?
>> (И пусть мне плюнет в рожу (а еще лучше - >> я плюну) тот, кто это сможет опровергнуть >> и доказать). MFC - всего одна (ну почти) >> DLL... Которая ЕСТЬ ВЕЗДЕ...

Поставь VB 4.0 поверх Microsoft Office 97.
И запусти Word. Угадай, какая библиотека
Word'у сразу не понравится?
Не все живут в Москве и юзают ПО последней версии.Есть программы и активно используются
(нашими бухгалтерами), написанными еще 5-6
лет назад. Переписывать их нет смысла - я работаю за деньги, а не ради удовольствия.

Win API и в Африке Win API. Его достаточно
корректно один раз прописать, а не править
при каждом удобном случае исходники MFC,
особенно горячо мною любимые CString и CTime.

"Каждому - свое!"

One опубликован 21-12-2001 17:43 MSK
--------------------------------------------------------------------------------
Читал, я тут, читал, так ничего для себя и не подитожил.
1. Я пишу на дельфях! Да, причем все. Я знаю C и WinAPI (иначе чтобы я тут делал), может, не очень, но знаю. По крайне мере, разберусь в любом исходнике. Да, я садомазахист. Но мне нравится. Именно паскаль. (если по секрету - то только за понятность структур, с детства пошло).

2. Человечество идет по пути деградации!? Пять - Шесть лет назад проги выпускались настолько отточеными, что практически не к чему было придраться. Между прочем, все писалась на обычных C + asm с использованием WinAPI. Вспомним Photoshop 3 - 4, Corel Draw 4 - 5 и ежи с ними. Да хоть по играм судить - вот настоящий двигатель прогресса. Что имели тогда - и что сейчас? Да, не спорю, красиво, стильно, все там новейшие прибамбасы, но: криво! Патч через каждые три дня, а все равно не работает. В Corel 10 напихали столько прибомбасов, что он из-за них летает не хуже Виндов и тормозит жутко, а кому это нужно? ICQ, по слухам (говорили мне) вообще на Java написана, и я этому верю. :-).

Короче девиз время - деньги работает в наше время как нельзя лучше. Быстро сварганил - побольше получил. Вот для этого и придумывают всякие прибамбасы - начиная от subj и заканчивая тем же Delphi.

Ну и плюс мода, конечно. Ну объясните мне, дураку, зачем везде, куда не лень, пихать, ну например, ActiveX? Не, ну где там он нужен (Интенет?), там понятно, но ведь везде уже. И с остальным также - если один Soft Developer чего-то там к себе такого вставил, то другой обязательно воткнет, а то вдруг без этого не продаст? Кстати, моду диктует, мне так кажется, все тот-же MS.

3. Кстати, кто такой сегодняшний программер? Россию в расчет брать не будем (у нас тут каждый второй), посмотрим глобальнее. Вот когда программер за перфоратором сидел, он просто обязан был знать все, иначе после каждой ошибки... долгая работа. Сейчас же можно начать писать проги, пройдя школьный курс! Кто-то там сумел создать окно - все, программер. Не, ну если какие проблеммы, можно там Win SDK заглянуть или по формумам поститься :-))). Вот он влез в MFC, почитал чуть-чуть хелп, посмотрел примерчики, и давай по Wizard'ам лазить, программировать. А ведь все это сказывается на качестве (см. п. 2).

Итог: я не имею ничего против всяческих оболочек. Ни-че-го. Но надо помнить, что прога пишеться для юзера. Программер не продавец, товар - деньги не его девиз. Его девиз: хорошо сделал - хорошая зарплата. Все остальное - дело продавца. Я конечно знаю, что богатый ламер - наш клиент, но и совесть-то поиметь надо. А писать можно хоть на asm'е, хоть на Java.

Так что поменьше всем багов в их коде.

DmitryRyvkin опубликован 22-12-2001 05:49 MSK
--------------------------------------------------------------------------------
2One.
Полазать чуть-чуть в хелп - к этому как раз
Delpi располагает, в MFC на чуть-чуть далеко не уедеш.
Отсутствие в языке модификатора inline и запихивание в exe шник текстовых строчек а ля OnButtonClick как раз вряд ли можно считать хорошим стилем.
И наконец, кто же такой по вашему программер ? IMHO - человек, умеющий перевести понятия реальности, конкретные задачи в АЛГОРИТМ решения. А знание тонкостей языка и библиотек придет само.
А бояться что ныне программы пишутся не так отточено как раньше не следует. Сложность постоянно растет, написание программ с вымучиванием каждой строчки - дорогое и неэффективное занятие. Которое становится никому ненужным с очередным повышением частоты проца на 20 %.
PS Чем структуры Паскаля отличаются от аналогичных C++ ?
PPS Кончаем религиозный флейм !!!
stan опубликован 22-12-2001 11:26 MSK
--------------------------------------------------------------------------------
Да ладно врать то, про чуть-чуть в хелп...
Писал я на Дельфях - хелпы там по размерам действительно чуть-чуть. Нередко то, что нужно я находил с большим трудом, а чаще вообще не находил (знаю я Дельфи плохо, а потому часто лезу в хелп). Участвовал я в большом проекте на Дельфи - прога была красивая, функциональная, огромная и чрезвычайно глючная. Время разработки интерфейса она действительно сокращает. Но что же это за прога, если большую часть в ней занимает интерфейс. Если надо написать небольшую прогу, то я и в MFC без нажатия на клавиши сделаю SDI приложениес тулбаром, сплашем, множеством контестных меню и т.д. Я и сам MFC не люблю, но и Дельфи не переношу. Тлько из-за того, что это Паскаль + то, что непонятно как она работает. Поясню: СИ реально позволяет писать проги короче и быстрее. Дельфи часто валится, непонятно почему. Самый прикол, что целый Дельфевый проект свалился на моих глазах, причем два раза, как раз в тот момент, когда мне доказывали, насколько Дельфи хорошая. Если такое случается в Сях, я лезу в МСДН и ищю раздел BUG: Visual Studio hangs if...
MFC реально неприкольно использовать для больших прог (хотя 1С на нем, похоже, и написан. Кстати ICQ тоже если не полностью, то частично юзала MFC, достаточно взглянуть на таблицы экспорта и импорта ее модулей и внутренний код). Дельфи - не альтернатива
One опубликован 22-12-2001 13:27 MSK
--------------------------------------------------------------------------------
Ну вот, опять давай рассуждать, что лучше, а что хуже. Я написал п.1. только для того, чтобы небыло недомолвок с моей стороны. Хоть кто-нибудь увидел, чтобы я сказал, что дельфа мол лучше C? Я лишь сказал, что мне с ней удобнее.
И насчет хелпа я говорил чуть-чуть(т.е. толком не разобравшись), а что в делфях ее до фига, я уж и сам знаю (бессоные ночи, провиденные в Delphi Help и Win32 SDK).

Я говорил о том, что нет смысла спорить о том, какая оболочка лучше, какая хуже (если рассматривать это просто как спор). Главное, чтоб писать не коряво. Мне вот из Москвы недавно спустили прогу - так там глюк, который все программеры на C прекрасно занют - при Enter'e она закрывается. Вопрос - что это, C - плохой язык? Ни в дельфях, ни в VB такого не получишь. Ответ: нет, просто у кого-то очень корявые руки.

Нет, можно, конечно сравнивать технические параметры, с этим я согласен, но там то одно, то другое побеждает, смотря по какому параметру смотреть. Так что однозначности нет.

Так что писать надо кто-на-чем-может (смотри выше п. Итог!).

2DmitryRyvkin

>Которое становится никому ненужным с
>очередным повышением частоты проца на 20 %

Вот об этом я и говорил, по твоему при достижении процом частоты, ну допустим, 100ГГц можно вообще прогу не отлаживать?

Кстати, сравни:

i = 0;
for(i;i<=Max;i++)
{
do something
}

и

for i:=0 to Max do
begin
do something
end;

в принципе один фиг, но по-моему!, на паскале яснее.

DmitryRyvkin опубликован 22-12-2001 17:32 MSK
--------------------------------------------------------------------------------
Не ну я вообще несогласен.
1. 100 ГГц = 0.003 м это меньше чем размер кристалла- такой частоты не будет (на полупроводниках) НИКОГДА
2. Не путайте C c C++ (каламбур однако)
for (int i = 0; i < MAX_LIMIT; i++) DoSomething (anyThing);
Это куда более понятно чем паскалевские begin end да + убогий for . Вы же знаете , что можно сделать в C++ в цикле for- пол программы :) Да и вообще это дело привычки.
На C/C++ возможны конструкции, кажующиеся
дикими, но потом начинаеш понимать и любить язык именно за них.
............................................
2 FlexFerrum
Вот скачал WTL, вещь любопытная, обращаюсь к тебе как к спецу по templates.
Вот допустим есть шаблон. Никак не могу запомнить синтаксис, но что то типа
template <class T> class CTestTempl
{
public:
}
Потом я делаю
CMyUsefullClass : public CTestTempl <CMyUsefullClass>
{
}

Вот чой-то не понимаю, что тут произойдет с виртуальными ф-циями объявленными в шаблоне.
Это я конечно от дури, но , имхо, шаблоны - одна из самых сложных особенностей C++.
Может ссылки какие даш ? А то вот счас пол- литра принял, а в суть шаблонов так и не въехал. В твоем примере про _closure до сих пор разбираюсь. Хоть там нет виртульных

One опубликован 23-12-2001 14:54 MSK
--------------------------------------------------------------------------------
2DmitryRyvkin:
Начет дела привычки - это правильно. Именно об этом я и говорил. Вот.

А вот насчет проца - это неправильно. Человек должен быть оптимистом. Лично я верю, что придет тот долгожданный день, когда в моем компе будет стоять проц со сверхзвукавой частотой. А с кристаллами, да фиг с ними, на чем нибудь другом сделают.

Lord_DEMON опубликован 25-12-2001 01:24 MSK
--------------------------------------------------------------------------------
Господа!
Это спор на тему - что лучше, топор или пила(Borland|Visual; PHP|Perl; C|Pascal; Asm|Others; Windows|*nix).
Как показывает Российская действительность - лучше - водка, а потом - что под рукой оказалось и в памяти еще осталось. У меня на последнем проекте ушло больше всего времени (30-50%) на осознание того, что нужно, а оставшаяся часть была ударными темпами сварена на Перле для http. Что лучше - каждому свое. Пока в это не вмешался клиент - мы вольны говорить - ЭТО БУДЕТ НА МФК. А ЭТО БУДЕТ ПОД ВИНАПИ КАК СЕРВИС ВИСЕТЬ НА ХР. Но пришел клиент, положил бабоны на стол начальству, и все сели писать на яве под сан...
А щас еще сишар будет :) и .нэт :) в общем мыльные пузыри растут и размножаются... и не видать конца этому. Прогресс...
Так что изучать надо ВСЕ. а потом продаваться в рабство какой нить IBS или WestDEV.
Vovochka опубликован 28-12-2001 16:46 MSK
--------------------------------------------------------------------------------
Возвращаясь к исходному: MFC (и VC в целом) сделаны для программистов Мелкософта, а изделия дядьки Борланда для людей. Почувствуйте разницу.
ADK опубликован 29-12-2001 08:47 MSK
--------------------------------------------------------------------------------
Прежде всего, что лучше. На мой взгляд (и не только на мой, как вижу) лучше то, на чём ты ближе придёшь к цели использования средств разработки, то есть к готовой программе. На мой взгляд, товарищи как-то увлеклись и забыли о том, что мы, в сущности, ПИШЕМ ПРОГРАММЫ, а не ИСПОЛЬЗУЕМ КОМПИЛЯТОРЫ. Писать программы можно по-разному. Для моих целей (в оcновном системные программы) лучше пока подходит VC++.
Теперь - Delphi - это ответ Borland на MS Visual Basic. Её даже вначале особо остроумные члены команды хотели назвать VBK, Visul Basic Killer (или типо того, не утверждаю точно).

Году в 95-м всё было совсем не так, как теперь. Самая известная RAD - среда VB была лишь интерпретирующей, и многие считали её игрушкой для сборки демок. Многие и сейчас так считают.
Традиционыые IDE - Borland С++ 5, MS VC++ 4. Причём последний НАМНОГО лучше. Другие поставщики компиляторов, например, Symantec, признают MFC как промышленный стандарт и поставляют со своими компилерами. То же делает и Borland.

Неизвестно бы, чем это кончилось..

И вот - Delphi. Фантастические отзывы, "эта среда должна изменить мир" и т.д. Borland понимает, что традиционные среды разработки в прошлом и срочно переносит VCL на C++ Builder. Вначале Builder активно юзал OWL, ранее популярный framework Борланда. Были даже герои, использовавшие в своих проектах и VCL, и OWL. Естественно, пухлость их была необъятна.

Borland понимает, что её рынок - это RAD, и с корнем уходит туда.

M$ не откликается на призывы девелоперов добавить RAD-элементы в VC. Это, кстати, и к лучшему, а то бы WinXP могла занимать пару-тройку компактов. Да, M$ делает VC для себя.

MFC. Единственное, что сейчас серьёзно её поддерживает - тонны готового кода. Мне кажется, M$ не зря в последние годы предлагает схему VC->ActiveX->VB, чтобы у людей копились разработки, которые бы не нуждались в MFC.

C++ Builder - это продукт, в который всё пихают после появления в Delphi. Delphi для Борланда самый продаваемый продукт, и вообще любимое дитя. VC умирает, M$ проталкивает шарпы в надежде завязать всех программеров под себя. Выход J# этому подтверждение.

Короче, всё это было может не к месту, но что я хочу сказать. Выбирайте, то, что делает Вашу работу продуктивнее, хватит тут пихаться :-; Разработчики компилеров создали много чего и на любой вкус.

jcukeng опубликован 07-01-2001 06:30 MSK
--------------------------------------------------------------------------------
A skazite mne - kotorij
Chlen postavit' v rjad Tejlora?
Oba chlena horoshi -
I Lagranzha, i Coshi!
Ochen' v temu, po-mojemu.

PS. Sorry for translit.

vitya опубликован 07-01-2001 10:28 MSK
--------------------------------------------------------------------------------
На самом деле в основном это просто обертки
для handle-ов, но они упрощают жизнь,
просты и главное они легкие,
за счет того, что у них все реализовано не виртуальными функциями, а макросами
(message_map), a такую вещь как Serialize
писать самом редкий геморрой, так что все не так плохо.
А насчет компилятора, то такого компилятора, как BC3.01 нету к сожалению. Хоть он и и не-инкрементальный, он делает оптимизацию, как никто. VC6.0 ни фига не оптимизирует,
следующий код при всех оптимизациях остается таким же
int i, h;
for (i =0; i < 100; i++)
{
h = i*i;
}
старый борланд превращал примерно это в
...
mov es:[bx], 10000
...

вот так.

KMiNT21 опубликован 16-01-2001 12:51 MSK
--------------------------------------------------------------------------------
Во-первых, пора новую нить начинать. :)
И так уже эта 107 К.
Во-вторых, в продолжении темы очень маленьких прог - читайте новый документ на www.uinc.ru/articles/
--
Написание экстра-маленьких Win32 приложений на С++ от 1 КБ используя лишь API, на примере программы Windows Hider