мнение All об MFC - Форум на исходниках

WWW.ИСХОДНИКИ.РУ cpp.sources.ru

java.sources.ru web.sources.ru soft.sources.ru

jdbc.sources.ru asp.sources.ru api.sources.ru

  Форум на исходниках
  C / C++ / Visual C++
  мнение All об MFC
СПРОСИТЬ  ОТВЕТИТЬ
профайл | регистрация | faq

Автор Тема:   мнение All об MFC

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

Flex Ferrum опубликован 05-12-2001 12:43 MSK
По поводу OWLNext - извини за ссылку - лучше иди на www.owlnext.org.
А по поводу моего мнения об MFC - ИМХО я ее объектно-ориентированной библиотекой не считаю - максимум это гомогенный набор классов-оберток над API. Жизнь упрощает, конечно, но далеко не всегда. В этом отношении OWL и VCL спроектированны лучше. Помнится, лет n назад мне программисты-MFC'шники пеняли, что, мол, Borland сделал удар ниже пояса своим пользователям не сохранив совместимость между OWL 1.0 и OWL 2.0. На мой взгляд, они поняли, чем будет грозить дальнейшая поддержка и развитие библиотеки в том виде, в котором она была - и провели полный реинжениринг. Правда потом все равно похоронили, но это уже другая история.
DmitryRyvkin опубликован 05-12-2001 14:25 MSK
Гхм.. Так возникло сразу 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 не объектноориентированная
ОС, а на вопрос что делать - ответа нет.

Flex Ferrum опубликован 05-12-2001 14:55 MSK
Давай останемся на уровне обсуждения библиотек. Обсуждение компиляторов - это отдельная песня. Так вот, почему я считаю, что MFC - не ОО библиотека. По той простой причине, что она изначально разрабатывалсь как тонкая обертка над API. А API было ориентировано на использование в процедурных языках, но никак не в ОО. Суть в том, что MFC практически не упрощает работу. Да, она избавляет от рутины. Но ты, как человек, который программировал на VCL и на MFC меня поймешь. Взять хотя-бы работу с CTreeCtrl или TListView (к примеру). А на счет того, что Windows - не объектно-ориетнированная системы - это ты не прав (ИМХО). У конципции окна присутсвуют все признаки, которые определяют объект в ООП (может быть только за исключением абстракций).
server_mouse опубликован 05-12-2001 15:13 MSK
А мне MFC нравится. VCL как-то скрывает суть, то что творится внутри. MFC действительно очень тонкая надстройка над API и в этом её плюс. Более менее быстро позволяет разрабатывать обычные приложения, и в то же время позволяет писать что-то системное, не отрывает от API совсем.
Конечно для быстрой разработки сложного многооконного интерфейса VCL вне конкуренции, но писать сервер (не важно какой) я бы стал на MFC.
Flex Ferrum опубликован 05-12-2001 15:33 MSK
А вот я бы не стал писать сервер на MFC (особенно сервисы). Богу - богово, а кесарю - кесарево. В консоле нет места GUI'овым библиотекам (какой является MFC).
Не смотря на то, что контроль над внутренней работой программы должен быть, в MFC достаточно темных мест. И все же, у меня давно руки чешуться построить паралельную иерархию для облегчения рутинных операций в работе со списками, деревьями и т. д. и т. п..., вообщем для работы с элементами управления. В конце концов, объекты должны представляться объектами, а не смесью C++ с C. Кстати, именно к этому подталкивает программиста MFC.
purpe опубликован 05-12-2001 15:50 MSK
2Flex Ferrum:
Ты как-то хитро увязал сервер, сервис, консоль и GUI в одну кучу :)
согласен только с тем, что консоли и сервисы ваять в MFC не катит, но вот сервер, который должен параллельно обрабатывать теоретически неограниченное количество запросов, и который будет стабильно пахать довольно долгий период времени я б как раз сделал в MFC. Тем более, какая разница, как я его буду запускать - из Автозапуска или как сервис ?
purpe опубликован 05-12-2001 15:51 MSK
только давайте Яву не будем трогать :) с ней и так всё ясно!
Flex Ferrum опубликован 05-12-2001 16:01 MSK
Интересно, а как ты представляешь себе сервер, запускаемый из автостарта, на площадке у провайдера? Ну да ладно, к делу отношение это имеет опосредованное. Договоримся, что ты имел в виду COM-серверы. :))) А насчет использования MFC для этих целей - я скажу так, что в своем коде баги ловить легче, чем в коде MFC. Не гоже запускать программу, рассчитанную на взаимодействие с пользователем, в режиме сервиса без взаимодействия с десктопом. Специфики разные.
migel опубликован 05-12-2001 16:02 MSK
Пару слов про subj:
Хм Она все таки объектно ориентирована - но в архитектуре есть очень большие дыры (типа ссылка на нижестоящий в иерархии класс).
Насчет удобства - так за счет визардов всяких выруливает, хотя и ручкам можно с нуля писать.
Самый большой недостаток ее в том что нельзя без геморроя модифицировать поведение классов типа CFrameWnd - кто возился с док-барами тот поймет.
purpe опубликован 05-12-2001 16:12 MSK
вот как раз COM-серверы я и не имел ввиду :) с моей стороны речь идёт об обычном приложении, выступающем в роли сервера (почтовый сервер, вебсервер, и т.д.). Таким программулинам незачем взаимодействовать с десктопом. Думаю, что server_mouse тоже самое имел ввиду. И вообще мы с ним думаем одинаково, так как отвращение к VCL у меня в основном из-за её скрытности :)
server_mouse опубликован 05-12-2001 16:54 MSK
2purpe : Именно это я и имел в виду. :)))
-------
"Великие умы мыслят одинаково."
server_mouse опубликован 05-12-2001 16:57 MSK
Да и в конце концов M$ лишь рекомендует использовать для сервисов консоль, но никак не настаивает....
Flex Ferrum опубликован 05-12-2001 17:29 MSK
Чесно говоря, в первый раз слышу о неконсольном сервисе. Может быть еще и драйвера можно с использованием MFC ваять? :)))) Кстати, сервис и драйвер с точки зрения НТ очень похожи. Ну да ладно :))) Вернемся к нашим баранам.
migel: Я это и имею в виду. В принципе, это можно списать на необходимость поддержки ранних версий, но тогда с этим слабо согласуется изменение интерфейсов классов от версии к версии. Кстати, вопрос, который хотел задать: а какая могла бы быть ОО фреймворк для виндов, который удовлетворил бы максимум народа?
necer опубликован 05-12-2001 18:23 MSK
Не согласен с утверждением Flex Ferrum, что MFC исключительно GUI библиотека. Я вот часто пишу консольки с использованием некоторых MFC классов. И ведь действительно облегчает работу! Не то, чтобы даже облегчает, а скорее, ускоряет. Есть, конечно у нее и недостатки, что уж тут греха таить, но ведь и достоинств немало.
Flex Ferrum опубликован 05-12-2001 18:35 MSK
А какие классы ты в основном используешь (если не секрет)?
purpe опубликован 05-12-2001 20:41 MSK
мож я сабсем отупел, но не могу понять связку - консоль-сервис.
ну почему сервис обязательно должен быть консольным ?
purpe опубликован 05-12-2001 20:46 MSK
я, например, в восторге от MFC-шного примера вебсервера и считаю, что на его основе можно делать любой интернет-сервер. Делал на его основе вебсервер и запускал его как сервис в NT(тобишь убрал из него весь интерфейс пользователя, чтобы его вообще не было видно) и остался доволен.
server_mouse опубликован 06-12-2001 09:42 MSK
p>мож я сабсем отупел, но не могу понять связку - консоль-сервис.
Я тож как-то недогоняю. Неужто я не смогу в своём exe-шнике объявить
void WINAPI service_main(DWORD dwArgc, LPTSTR *lpszArgv);
???
KMiNT21 опубликован 06-12-2001 10:43 MSK
Вы знаете, было бы интересно послушать общие выводы, да мало конструктивизма. Привлечь бы разговору больше спецов...
место для рекламы
www.uinc.ru/forum
место для рекламы
Жаль, что эта нить пропадет бесследно. А хотелось бы, чтобы многие высказали свое мнение и все это дело было бы ОЧЕНЬ интересно прочесть.
P.S. И это, хватит про сервисы. Вы друг друга никак не поймете. :))
P.P.S. По поводу MFC-шного Веб-сервера -
зачем вообще MFC юзать ? Лучше делать на pure API. BTW, моя статья об этом на ww.uinc.ru есть. (Может пригодится)
Flex Ferrum опубликован 06-12-2001 11:07 MSK
KMiNT21: Согласен. Целиком и полностью :))
И по поводу сервисов и по поводу MFC для веб-сервера :)) Каждый инструмент надобно применять по назначению и не забивать микроскопом гвозди :))) И опять же, возвращаясь к нашим баранам, хочу спросить: какие основные достоинства находит народ, использующий MFC как ОО библиотеку? Я, кроме DVC-модели и серилизации, ничего больше не нашел.
DmitryRyvkin опубликован 06-12-2001 11:27 MSK
Достоинства... Писали вы скажем пару - тройку недель на CBuilder, все хорошо, понятно. Но потом дошло, что VCL для девочек (мнение большинства работодателей, даже для GUI, впрочем она Pas написана, и разбираться в ней подробно неоохота, а трассировать и вовсе не выйдет) и сели вы значит за VC6. А куда там садится, если не знал что такое WinMain и т п ? За Wizard... Ну и пошло и поехало. Под конец привык. А достоинства основных IMHO 3 -скорее всего (!) не придется тащить mfc42.dll
,прозрачно и достаточно удобно сделана работа с сообщениями, и , главное, если придется писать на API MFC не противоречит ей, большинство методов имеею те же названия.
В итоге я как бы и API учу.
--------------------------------------------
Так никто и не предложил, что делать то.
По крайней мере с GUI
На API писать то можно, все равно сам все в классы рано или поздно спрячеш. Но вот я лично боюсь с сообщениями заморачиваться - так и подмывает всю эту часть из MFC начисто передрать.
purpe опубликован 06-12-2001 11:32 MSK
ну и зачем изобретать ещё один апач, с его тоннами API кода, когда в MFC всё тоже самое будет раз 20 меньше весить. В апаче 2/3 кода только на обработку ошибок уходит...
А спорим мы действитель немного в разных плоскостях ... Просто я выступаю за MFC с позиции удобства создания сложных приложений (не учитывая всякие COM-мы и сериализации), при том, что всегда можно залезть в кишочки и сделать что-нить эдакое нестандартное.
2Flex Ferrum: я вот до сих пор никак не могу понять, зачем ты в разговор приплёл сервисы. Только народ взбудоражил :)
2KMiNT21: никто не имеет ничего против API, но здась идёт речь именно о достоинствах и недостатках MFC. Вот заведи новый топик про API и будем там перемалывать твоё пристрастие :) А уводить дисскуссию в сторону (как енто сделал Flex Ferrum с сервисами) не нада :)
purpe опубликован 06-12-2001 11:37 MSK
я против того, чтобы садиться кодить в VC не имея представления об WinMain, WndProc, и т.д. - помоему никакого удовольствия от такого программирования не получишь ...
DmitryRyvkin опубликован 06-12-2001 11:44 MSK
2purpe на счет вашей позиции с MFC согласен, а за что новичку тогда вообще садится ?
Если за API начинать то лучше сразу идти водку пьянствовать..
Разобраться в MFC - ( а это придется делать при первом же непонятном
поведении чего- либо), а потом и знание API и всего прочего низкоуровнего
придет. По крайней мере у меня так произошло.
А писать на VCL... Мой приятель 2 года пишет на Delphi, так
я за пол-года MFC API лучше его знаю, не потому что такой умный, а просто
приходится.
Flex Ferrum опубликован 06-12-2001 13:19 MSK
По поводу серверов первым высказался server_mouse:
"но писать сервер (не важно какой) я бы стал на MFC.".
И опять же, теперь ты уводишь дискуссию в сторону. Как ты правильно сказал, мы обсуждаем библиотеку. А всяческие там визарды относятся к среде разработки, которую мы не трогаем (или по крайней мере стараемся) :)). Если пользоваться визардами - то зачем слезать с VCL, где служебного кода надо вообще по миниму писать?
OlegO опубликован 06-12-2001 13:25 MSK
Вобщем можно я возьму на себе роль чуть-чуть подитожить :).
Во-первых начинать сравнивать VCL и MFC не совсем правильно, так как в основе их реализации лежат разные идей.
Первое (VCL) планировалось как конструктор ну например типа - Лего, есть готовые кубики из них лепи что хочешь, но в рамках того какие кубики у тебя есть в наличии - это позволяет очень быстро строить большие однотипные постойки, даже при не высокой квалификации строителя.
Второе (MFC) планировалось как легко расширяемая оболочка над API, сравним с конструктором в котором есть бруски, из них можно что построить, но чаще всего придется повырезать свои детали - скорость разработки понижается, и требует большей квалификации, однако есть большой плюс, это возможность легко создавать свои детали.
Как видно и то и другое посвоему хорошо, я бы рекомендовал VCL на стадии создания прототипов, быстро и сердито, MFC подключать когда требуется необходимость создания своих визуальных элеметов - тут это выйдет быстрее и меньшими затратами, причем если делать компонеты в виде ActiveX то переносить их из проекта в проект будет проще, тем самым будет накапливать багаж ваших собственных компонетов.
PS> Извеняюсь что может больше сказал про MFC, но с ней я больше и работаю.
DmitryRyvkin опубликован 06-12-2001 14:02 MSK
Полностью согласен.
Маленькая просьба, если есть возможность.
Пришлите исходник чего нибудь MFC ' шного что компилится в ocx
server_mouse опубликован 06-12-2001 14:43 MSK
2Flex Ferrum: Забьём на серверы и сервисы...
Полностью согласен с OlegO. От себя добавлю:
В VCL IMHO упор сделан на простоту работы (и скорость разработки!) с интерфейсом пользователя.
В MFC на гибкость в работе с системой, возможность реализации нестандартных фишек.
Для меня MFC куда более понятна и открыта нежели VCL, хотя работал с обеими. Может потому, что когда-то начинал с API...
necer опубликован 06-12-2001 15:32 MSK
to Flex Ferrum:
>А какие классы ты в основном используешь (если не секрет)?
Не секрет. :) Да хотя бы те же банальные CString, CArray, COleDateDime и тому подобные мелочи. А жизнь они облегчают здорово. Несложно, конечно, и самому написать подобные классы, но на реализацию и отладку(!) нужно время, а работу нужно сдать в срок.
Flex Ferrum опубликован 06-12-2001 16:20 MSK
2necer:
Я для этих же целей использую string, vector, и т. п. классы из STL и имею гарантию, что написанный сервис можно будет без особого труда перекомпилировать в unix-демон. Кстати, и функционала у них поболе будет.
С OlegO сложно не согласиться, то есть я тоже с ним согласен. Только сдается мне, что MFC можно было бы и иначе спроектировать. Именно поэтому я и говорю, что MFC - это набор классов. С их помощью можно построить практически все что угодно, но из-за того, что где только можно там используются API-подобные конструкции использовать ее не всегда удобно. Вот простой пример. Возмем тотже самый ListView. Чесно говоря, что я его буду заполнять с использованием API, что воспользуюсь для этого MFC - объем кода будет примерно одним и тем же. Хотя по сути дела это обычная коллекция строк или, еще лучше, объектов. Но в MFC нет возможности работать с ListView как с полноценной коллекцией. Спрашивается: почему? Я конечно понимаю, что программист должен иметь максимальный контроль над программой. Но кто мешает встроить в объект как коллекцию так и доступ к ней на уровне API? Кто хочет API - использует один интерфейс, кто коллекцию - другой.
server_mouse опубликован 06-12-2001 16:45 MSK
>Но в MFC нет возможности работать с ListView как с полноценной коллекцией
Называется 'сделай сам'. Почему спрашивается для MFC такое огромное кол-во классов (хотя бы на www.codeguru.com)? Кол-во компонентов на 'Королевстве Delfi' куда меньше. В MFC всё ручками. Делаешь однажды и пользуешся всю жизнь.
Конечно сделать и так и так было бы лучше...
Flex Ferrum опубликован 06-12-2001 16:55 MSK
Об этом я и говорю. Зачем тогда MFC, если это продукт из серии "после сборки обработать напильником"? Таким макаром я могу написать необходимый мне набор классов используя чистый API. Вот например, STL используется практически всеми программистами на C++, тем не менее такого количества довесков к ней нет. Просто в этом нет необходимости - библиотека предоставляет свои возможности в наиболее удобном для использования варианте. А у Microsoft что API, что MFC - без поллитры не разберешься (если делаешь что-либо нетривиальное).
necer опубликован 06-12-2001 18:02 MSK
STL не настолько хорошо документирован, как MFC. И примеров, чтобы разобраться в процессе обучения несравнимо меньше.
rodion опубликован 06-12-2001 19:08 MSK
Мое мнение о MFC... Это тень Билла Гейтса, это основа Windows без нее все равно никуда не денешься. Как и Билл Гейтс хочет мирового господтва на Земле, так MFC хочет мирового господтва в прогамировании под Windows.
Emerald опубликован 06-12-2001 19:47 MSK
Народ! Не нравиться MFC -- флаг вам в руки и барабан на шею -- есть чистый API. Там возможно все и не столь сложно, как все думают. И файло меньше выходит.
al опубликован 06-12-2001 19:56 MSK
Многие забывают, что 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...
al опубликован 06-12-2001 20:03 MSK
... Продолжая. По этим же причинам не совсем правильно сравнивать VCL или STL с MFC. Эти библиотеки появились значительно позже. Кроме того Borland действительно "кинула" своих пользователь при переходе c OWL 1.0 на OWL 2.0 (к стати, на мой взгляд OWL 2.0 делалась под сильным впечатлением от MFC, в те времена вообще ходил слух, что MS собирается cудиться с Borland).
А MFC - это прежде всего - СОВМЕСТИМОСЬ. А СОВМЕСТИМОСТЬ - это то, от чего с продуктами Microsoft столько проблем, а с другой стороны, это то, почему ими практически все пользуются.
DmitryRyvkin опубликован 06-12-2001 20:24 MSK
Серверы.. Сервисы.. .Net... C#...
Это все хорошо, но допустим мне надо в приемлимые сроки написать не слишком навороченную GUI прогу, немного работы с COM портом, немного обработки данных, запись в файл, возможно передача в Excel.
На Delphi VCL писать - не знаю языка,
Builder - ужасная отладка и вообще монстр,
нежто ждать пол-года этого .NET и что он мне собственно дает ? Неужели весь мир сосредоточился на сетях и старые добрые GUI уже никто не пишет ?
serp555 опубликован 06-12-2001 22:14 MSK
Да, мужики... Раз тут мнения высказываем, что-то тоже слово вставить захотелось, из собственного опыта. Где-то до 95-го я с успехом юзал Борланд 4.5, потом годик 5.0, потом МС Визуал С++, последние три года использую его только при срочных задачах и экспериментах. (На билдер только дивлюсь :-))
Вообще говоря, MFC весчь хорошая, и OWL хорошая, (но увы, Борланд, ныне Инпрайз, не создатель сей ОС, а посему хошь-не-хошь проигрывает). Тем не менее, убедился, что фундаментальнее API и удобнее ничего нет.
На мой взгляд, совершенно правы,те, кто высказал мнение, что MFC выигрывает при разработке стандартного ПИ. Добавлю, еще, что МФС прекрасно документирован, лучше чем функции и структуры АПИ и уж тем более стандартная С-библиотека. (Вероятно, по той самой причине, которая здесь так-же прозвучала: "ВСЕ ТОЛЬКО В МФС", а для остальных - особо умных - "грузить чугундий" - т.е. работать с меньшим комфортом). Но после того, как построишь свою собственную библиотечку поддержки, то лучше АПИ ничего нет. И приложения строить не менее оперативно можно. Ну и надо еще добавить, что МФС вообще говоря коммерческий продукт и не дешев :-((
А на АПИ - хоть Сигнусовский компилер используй (и их же либу ГНУшную). Да и потом, никто не может жить вечно... Это я к тому, что если пройти ч/з эти задачки, в Линуксе под иксами, писать одно удовольствие. Да, и QT очень неплохая библиотека есть, кстати, идеологически, очень похожа на МФС. Вот и ежели что случиться, без МФС и Виндов проживем.
А пока, думаю, все имеют право на жизнь.
Всем привет,
Сергей - СЕРП.
zhevak опубликован 07-12-2001 02:56 MSK
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. Вот и разгоратся споры --
что лучше, а что хуже.
Александр Жевак
kourov опубликован 07-12-2001 06:20 MSK
И всё же, для того, чтобы облегчить общение с API UI функциями, существенно не утежеляя результирующий код, MFC прекрасно подходит. От этого особо страдают Borland'овские библиотеки. Все могут сказать, что на размер проги сейчас можно положить, но я как-то привык...
А то, как деструкторы классов помогают избежать resource leaks, комменты излишни!
Flex Ferrum опубликован 07-12-2001 10:52 MSK
Итак, подведа некоторые итоги можно сказать, что мнение All об MFC переросли, как это обычно бывает, в дискуссию Borland vs Microsoft или BCB/Delphi vs VC++, что, ИМХО, суть уход от темы. Мы обсуждаем библиотеку как библиотеку, а не как приложение к конкретному компилятору. Не для кого не секрет, что версии MFC есть и для борлондавских компиляторов, под Ваткомом она работала и т. п (чего, кстати, нельзя сказать о VCL). Речь не об этом. Хорошо использовать библиотеку, когда в среде есть куча визардов, делающих за тебя основную рутину. Тогда, в принципе, и подобных тем не должно возникать - библиотека будет удобна априори. Суть в другом.
Я утверждаю, что мне эта билиотека не удобна как программисту, использующему ее без применения автоматизации. Да, согласн, в данном случае большим достоинством является то, что билиотека максимально приближена к АПИ. Удобно. Не надо менять систему понятий (как например, для той-же VCL), суть кода будет, что называется, интуитивно понятной. Проблема в другом - даже с использованием MFC кода получается много. Как я уже говорил раньше, в некоторых аспектах своего использования MFC нисколько не помогает программисту (пример я уже приводил).
Хотя, наверняка, не стоит требовать от продукта больше, чем он способен дать. Но, на мой взгляд, это некоторое издевательство над программистом. Мы дадим вам неудобный инструмент для работы (а-ля ненаточенную пилу), но звиняйте братцы - другого нет, а по этому придется этой пилой пилить толстенное дерево, предварительно обработав напильником. Но денюжек за эту пилу мы все равно много попросим - продукт то профессиональный :)).
По поводу того, что не надо сравнивать с STL или VCL - сравнивать надо, но в определенной плоскости. Сравинвать надо не с точки зрения функционального назначения (это бессмысленно), а с точки зрения качества построения концепции что-ли... Все это - ОО библиотеки. И не гоже, когда С++ применяется исключительно как надстройка над C.
DmitryRyvkin опубликован 07-12-2001 11:25 MSK
Подождите.. Разве если покупая VC++ (что то порядка $2000 кажется) мне разве MFC автоматом не предлагается ? Они вроде даже поощряют вносить изменения в исходный код ( только распространять под другим именем тогда ). И сколько ж она тогда сама по себе то стоит ? За денежки то дело другое :-) За денежки я еще подумаю, использовать ли ее...
Я где то читал, что если нашегому человеку надо нарисовать табуретку, он бежит на рынок за последней версией автокада. Может и эта "проблема" тогда той же серии ?
DmitryRyvkin опубликован 07-12-2001 11:47 MSK
Кстати спасибо 2Александр Жевак, не пожалел времени на длинный рассказ.
Тока я не понял
Вы будете приятно удивлены вашим выбором языка
программирования - подробней можно ?
А вы на чем пишите сейчас ?
al опубликован 07-12-2001 13:26 MSK
Еще раз - текущей версии MFC - 4 года (VC6 появилась в 97 году), самой MFC - более 10.
В тот момент лучшего не было. Сейчас имеется
СОВМЕСТИМОСТЬ. Сама MS нонимает неуклюжесть MFC и создает другие библиотеки ATL и WTL.
На мой взгляд будущее за .NET. К стати это не только "работа с сетью". Возможно это будущий API Microsoft.
Не только MFC проигрывает WinForms (это часть .Net, отвечающая за UI), но на мой вздляд C++ более неуклюж по сравнению с C#.
buLLet uinC опубликован 07-12-2001 20:46 MSK
2 DmitryRyvkin
Спешу сообщить что объектная ориентированость ОС не есть еквивалент с понятием ООП в целом.Изучите под отладчиком кернел любезный - я имею в виду НТ.
2 Flex Ferrum
И еще по поводу гомогенности MFC.Что вы хотели этим сказать?
Что набор классов однороден?Или что шаблоны однородны?
или что-то еще?
проясните плз...для поддержания плодотворного диспута так сказать
пионерский привет
Flex Ferrum опубликован 07-12-2001 23:41 MSK
Гомогенность - в смысле гомогенная иерархия классов, когда все классы растут из одного корня - в данном случае CObject. Но это уже другая тема для диспута - хорошо или нет использовать гетерогенные иерархии с возмолжностью множественного наследования. Я считаю, что библиотека много теряет ограничивая программиста одиночным наследованием. Но это исключительно ИМХО. Тут опять могут возразить, что MFC уже 10 лет и т. д. и т. п. Но тем неменее я считаю это недостатком.
zhevak опубликован 08-12-2001 02:18 MSK
Hi everybody
Вообще это не плохой подход -- рассмотреть вопрос о
стоимости продуктов! Америка -- не совок, где цены
устанавливаются по решению партии и правительства.
Там, на сколько я знаю, цену на продукт устанавливают
драконовские законы рынка. (Драконовские -- в
том смысле, что если сделал не верный шаг, то значит
пролетел.) Если VС++ стоит дорого, значит он столько
и стоит! Думаете Борланд не хочет продавать свой
продукт подороже? -- Хочет, да еще как! Но, увы, не
может. Задерет цены -- продажи вообще встанут. А у
нас в стране эти законы не действуют. Мы как были
пиратами, так и остаемся ими по сей день. Потому как
правосудие у нас не работает буксует в этом вопросе.
А знаете сколько можно схлопотать за пиратство в
США? Вот то-то и оно, что покупаем мы CD-юки с
Броландом и M$ по одной цене. Так что, я думаю,
наша азиатская страна не может быть "лакмусовой
бумажкой" в вопросах оценки качества продукта.
Для DmitryRyvkin -- несколько лет назад я писал на Delphi
и, откровенно говоря, был счастлив. Но мне как-то
попалась в руки книжка Дэвида Круглински (Боже, упокой
его душу! Он несколько лет назад трагически погиб). Там
черным по русскому было сказано, что "MFC не сделает
программирование достоянием для масс". Я понял так,
что MFC -- это для избранных (Я еще тогда не смотрел
"Матрицу"). А быть избранным, страсть как хотелось...
Кроме того, далее были слова, что Windows-программисты
получают большую зарплату и "эта ситуация вряд ли
изменится в ближайшем будущем". Вобщем, я заглотил
наживку... Оглядываясь назад, я не могу сказать, что я
жалею о смене своих убеждений. Скорее наоборот.
Коммерческие проги я пишу на МС++. Но вот своих
девченок (у меня две девочки 8 и 6 лет) я учу
программированию на VB, а не на Делфи. Им еще сложно
понять всякие там "синусы-косинусы", а кнопки расставить
на форме и навесть на них обработчиков они уже умеют.
Богу - богово!
To Flex Ferrum
10 лет -- это плохо?! Я не уверен! А что, разве уже вышло
положение об отмене тех задач, для которых, собственно,
и был придуман С++? Конечно, С++ вместе со всеми его
библиотеками не очень компактен. Хотя он и претендует на
роль очень универсального языка, но все ж, давайте не
будем на него вешать всех сабак! Появился Си-Шарп, ну
и на здоровье! Это не значит, что плюсам пора на пенсию.
Ассеблер ведь не умер, а занимает строго свою нишу. То же
самое происходит и плюсами. То же произойдет и с Шарпом.
Я еще раз хочу сказать, что если вы испытываете трудности
в программировании, то либо вы взяли неправильный
инструмент для решения своих задач, либо вы подошли к
границе дозволенного. Тогда вам прямой путь в написании
своего инструмента. Программистское общество вам скажет
спасибо, а лет через 10 студенты будут изучать ваш инструмент.
To DmitryRyvkin
Я прочитал еще раз ваше самое первое высказывание --
"томоза при работе с битмэпом". Нет там никаких тормозов!
Просто Вы, уважаемый, "не правильно пользуетесь вилкой"!
К сожалению, MFC -- это библиотека достаточно тяжелая в
освоениии. Но она стоит того! Делфи осваивается на прядок
быстрее.
A.Zh.
x опубликован 08-12-2001 03:44 MSK
Ну вот=опять разброд и шатание
1.не хрен обсуждать цены на софт=если-бы его все легально покупали програмеров бы вообще не было на свете
2.я по существу не услышал ни одного четкого мнения о subj
3.2 zhevak =я бы попросил не говорить за всех
>>Спокойнее, господа, спокойнее! Здесь не >>место для публичных
>>икзекуций иноверцев. Здесь место, где в >>основном тусуются
>>фанаты от MFC, т.е _МЫ_. А стало быть нам >>не к лицу мочить
>>наших же гостей из Дельфинария в нашем же >>доме. :)
4.лично я против MFC и вообще этих дуратских библиотек потому что:
__A)может кто занимался RE? более кривого
кода чем объектный придумать сложно
__B)изучение чужой библиотеки занимает столько же времени сколько написание своей
__С)ты всегда знаешь все недостатки (баги) своей а на изучение багов чужой потратиш в 20 раз больше времени и все равно ничего целиком не узнаешь
__D)готовые библиотеки развращают=сколько оригинальных,красивых прог вы видели когда был дос?;а сейчас?=ЭТО ПРОСТО ТОРМОЗИТ ПРОГРЕСС
5.о начинающих: у них должны быть свои мозги,кто поумнее сам все поймет;и если уж на то пошло идеи "правильного" "неправильного" не имеют никого отношения к реальной жизни и твоем куске хлеба
6. вместо итога:если чел досконально знает API он волен применять любые библиотеки какие сочтет нужным
max_prosto_max опубликован 10-12-2001 09:53 MSK
Юзайте WTL - нормальная ОООболочка поверх ВИН32АПИ а МФС - это просто вилы с их РТТИ - уже легкой оболочкой не сойдет
Достаточно посмотреть на исходники класса ЦСтринг - курсовая для 3 курса не более.
Flex Ferrum опубликован 10-12-2001 10:14 MSK
По поводу WTL мне особенно нравится вот что
(взято с сайта microsoft):
Windows Template Library WTL 3.1
A library for developing Windows® applications and UI components. Extends ATL (Active Template Library) and provides a set of classes for controls, dialogs, frame windows, GDI objects, and more.
Size (bytes): 317,880
Last Updated: 03/23/2001
Supported: no
^^^^^^^^^^^^^
Download
Discuss in Newsgroups

rodion опубликован 10-12-2001 12:39 MSK
1. Создание собственных библиотек дело слишком дорогое удовольствие, доступное лишь для мощных компаний.
2. Vb или Delphi не для вычислений, тут я вижу люди которые не знают, что иные расчеты идут часами.
3. Что Microsoft приобрела главного Pascalчика тем хуже для них теперь VC будет похож на Pascal. Borland делает наоборот.
4. Ты крутой не потому что пишешь на MFC, а потому что ты пишешь, и как. И на том что удобнее и быстрее для тебя.
5. И ни кто с нуля программы не пишет, у каждого есть свои наработки. Под MFC требуются более обширные.
6. Как говорится смотри в корень: Кто нибудь стал бы писать на MFC если M было не Microsoft?
al опубликован 10-12-2001 16:06 MSK
2rodion: Главный паскальщик сделал C#, C++ только так, немного потрепали - добавили __gc
ggg опубликован 11-12-2001 02:15 MSK
да здесь бесполезно что то обсуждать
вопрос из той же области - на чём писать проги - на асме или VB :)
у каждой тулзы своя область применения
но сторонников и той и другой ты не переубедишь, что их тулза не самая-самая
если интересно моё личное мнение:
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
--
СПРОСИТЬ  ОТВЕТИТЬ
Перейти:

E-mail | WWW.ИСХОДНИКИ.RU

Powered by: Ultimate Bulletin Board, Freeware Version 5.10a
Purchase our Licensed Version- which adds many more features!
© Infopop Corporation (formerly Madrona Park, Inc.), 1998 - 2000.