LINUX.ORG.RU

Сравнение: MFC vs Qt


0

0

Вышел перевод Andi Peredri, автор статьи Pascal Audoux. Статья не претендует на полноту охвата сравнения, но достаточно точно подмечены некоторые особенности работы с обеими библиотеками. Надеемся, что это первый перевод из серии ... vs Qt.

>>> Перевод можно прочесть здесь:

Нашли что сравнивать:

КуТю с МФЦ

весчь - с ацтоем

------

статья в общем правильная, только ненужная, тк итак все было понятно...

другое дело сравнили бы кутю и гноме/жтк+

anonymous
()

Нафига с еще одним отстоем сравнивать? :)

А вообще MFC с Qt и рядом не стояла по удобству программирования :)
Тут уж и спорить нечего.

Eugeny_Balakhonov ★★
()
Ответ на: комментарий от anonymous


>другое дело сравнили бы кутю и гноме/жтк+

Там в конце статьи есть несколько ссылок на эту тему

sS ★★★★★
()

Eugeny Balahonov (*) (2002-08-28 18:35:12.672)

это ты здря так

кстати, я тут программку некую фаял (чистый интерфейс - кнопочки и поля) так между гном\жтк и кутей чтобы перенести надо переписать очень немного...

anonymous
()

Qt - ацтой! - тяжелая хреновая тормозная

Gnome\GTK+ - рулит! - легкая модульная быстрая

anonymous
()

приятно почитать правдивую статью

anonymous
()

правдивая статья о Qt vs MFC на сайте, посвященном KDE, написанная линуксоидом.. LOL! :)) если в двух словах - то автор просто не знает MFC. впрочем, MFC все равно говно.

qrot
()

2Eugeny Balahonov (*) (2002-08-28 18:35:12.672):

> А вообще MFC с Qt и рядом не стояла по удобству программирования :)
> Тут уж и спорить нечего.

Верно! Это и без статьи было ясно. Всё равно, что сравнивать чёрное
и белое.

badger
()

MFC скоро отомрёт, его заменит технология .NET

anonymous
()

иду по ссылке в новости: Нет документов Извините, запрошенный документ в базе не найден. Если эта ошибка повторится, сообщите вебмастеру!

anonymous
()
Ответ на: комментарий от anonymous

>иду по ссылке в новости: Нет документов Извините, запрошенный документ в базе не найден. Если эта ошибка повторится, сообщите вебмастеру!

Нет это не ошибка - читай внимательно :)

Warning: Too many connections in /home/bart/kde.ru/www/db/sql.php on line 24
         ^^^^^^^^^^^^^^^^^^^^^   
Статья пользуется популярностью видимо не без подачи LOR ;)

sS ★★★★★
()
Ответ на: комментарий от sS

> Статья пользуется популярностью видимо не без подачи LOR ;)

таким образом, впервые научно зафиксирован slashdot-effect, производимый LOR. Похлопаем. Важная веха в развитии сайта. ;)

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Не просто зафиксирован, а побит.
Сервак уже как пол-часа лежит. Не может запросов такое кол-во обработать...

aim1159 ★★★★★
()

Рекорд, рекорд.... Это просто ваш *nix. М-да очюработоспособная(ые) ОС.......

anonymous
()

Слушайте понимаю тема оффтопик полный но все же - вот поставил сусе там кде3 уж очень хорошо бегает и это сразу без всяких настроек..Как такого добиться скажем в ред хат? там у меня даже после перекомпиляции все медленнее работает :( где то надо спеть ритуальную песню во время стартапа или попрыгать с бубном в консоли? Если кому не лень прокомментируйте пожалуйста и еще раз извините за оффтопик ( ну почти тема то qt затрагивает ;) )

anonymous
()

Microsoft doesn't use MFC in their own products. MFC is a library to do quick and dirty stuff. Want serious shit - use .NET Windows Forms. Why not compare WF and QT. QT would suck real bad in this case, that's why.

anonymous
()

2anonymous:"Microsoft doesn't use MFC in their own products. MFC is a library to do quick and dirty stuff. Want serious shit - use .NET Windows Forms. Why not compare WF and QT. QT would suck real bad in this case, that's why."

Да да.. слышал я эту песню. Потом Майкрософт скажет, что .NET WF - это говно, теперь Microsoft юзает .DA BLAH, а потом будет .NE_ZNAIU EAH. Проходили, знаем.
Ведь Microsoft Press выпустило кучу книг по MFC и милионными тиражами. Все уже привыкли к этому кривому MFC. И теперь вот тебе НА: Еще одна кривая обертка вокруг кривого WinAPI.


"Qt - ацтой! - тяжелая хреновая тормозная
Gnome\GTK+ - рулит! - легкая модульная быстрая"
"другое дело сравнили бы кутю и гноме/жтк+ "

Бред. GTK есть Си, QT есть С++. Как можно сравнивать C с C++? Одно дело написать new QButton("but", parent); А другое дело написать:
struct button blahButton;
blahButton.size.h = 99;
blahButton.size.w = 99;
blahButton.caption = "ffsfs";
create_button(blahButton, parent);

Разница есть?

"кстати, я тут программку некую фаял (чистый интерфейс - кнопочки и поля) так между гном\жтк и кутей чтобы перенести надо переписать очень немного..."

Программка была Hello World? Вот вот.

logIN
()

Хорошое сравнение. Есть правда несколько замечаний:
- MSDN доступна бесплатно по адресу msdn.mictosoft.com (так что платить не обязательно)
- MSDN это не 10 дисков как утверждает автор
- я не знаю, куда он смотрел, но вся иерархия и описанияфункций там имеется
- TCHAR и char, явно показывает, что человек просто не в курсе, того что это стандарт С, а не MFC. И уж тем более TCHAR прекрасно будет работать в не юникодной системе (то же относится и к функциям типа strcpy)
- не проблема использовать не юникодные библиотеки в юникодной программе
- А когда речь зашла про QString, то автор чего-то "забыл" про CString
- про ресурсы он начал гнать просто откровенно, потому как забыл что тот же C++ Builder нормально работает с ресурсами.
- про resource.h просто смешно - надо нормально собирать программы
- "Сетевой API:" так же существует в MFC
Да MFC не фонтан, но так откровенно гнать, что замечаний чуть ли не больше чем сама статья, не следует.

Ogr
()

Ogr (*) (2002-08-29 06:41:16.387)

Недели три назад эту статью напечатали на KDE News ( http://dot.kde.org/1028305638/ ) и никто её даже там всерьёз не принял.

anonymous
()

Вот и Ogr проснулся и лег на амбразуру :)

anonymous
()

Эта статья не сравнивает MFC и QT, её цель - показать, что QT лучше. В чём-то это так. Но если писать что-то вроде Word'а, то MFC рулит. У QT очень геморорйная система сообщений. Сами подумайте: в определение класса вставляем какие-то макросы, которые разворачиваются в rtti-информацию (отличную от стандарта С++), затем этот фай лпрогоняем через специальный QT-препроцессор, на выходе получаем какой-то код, реализующий эти rtti-методы, затем этот код добавляется в проект. Это что, нормально??? Карты сообщений в MFC - это, конечно, не фонтан, но явно лучше. Вообще, MFC - это довольно тонкая обёртка над API, и не призвана полностью исключить API, а QT претендует на то, чтобы реализовывать всё. Если не считать механизма сообщений, то QT производит благоприятное впечатление. Хотя некоторых вещей не хватает. Ну и конечно документация. Если возник затык в MFC, то есть тонна документации, форумы и пр. Любая проблема решаема. В QT, кроме 20М документации, больше ничего нет. Документация покрывает только стандартные случаи. Шаг влево, шаг вправо - и неразрешимая проблема.

anonymous
()

Хотя я тоже отнюдь не в восторге от MFC и Qt действительно удобнее (да еще и мультиплатформенная), но статья напоминает продукт, сделанный по технологии "Черный пиар" ;-)
Откровенный гон на бедную MFC ;-)

Eugeny_Balakhonov ★★
()
Ответ на: комментарий от Ogr

2Ogr :

"- MSDN доступна бесплатно по адресу msdn.mictosoft.com (так что платить не обязательно) "

MSDN Library -> buy it first baby :-)

"- TCHAR и char, явно показывает, что человек просто не в курсе, того что это стандарт С"

Are you crazy or fool ?
The C Standrad are described -> neither UNICODE nor TCHAR.

WBR,
The Int

anonymous
()

Have you ever seen or used Gtkmm (former GTK--), guys? That's wahat one would call a really MODERN, komfortable C++ toolkit (We have year 2002 now but some people here say that the Qt's messaging and RTTI macros system is Ok 8-0).

anonymous
()

Про UNICODE. Дело в том, что char - Это всегда 1 байт. И ни MFC, ни QT тут не причем. Поэтому в стандарт С++ был введён тип wchar_t для поддержки UNICODE. Чтобы была совместимость на уровне исходных текстов, необходимо явно отличать константы UNICODE от однобайтовых. Для этого и введён макросы CHAR и TEXT, которые, в зависомости от установки значения _UNICODE, определяют ASCII или UNICODE константы. Это не вопрос QT или MFC. QT, насколько я понял, предполагает задание строковых констант в ASCII их последующее конвертирование в UNICODE функций (макросом) tr(). В Windows API выбран другой путь - на этапе компиляции устанавливается тип строк. Дело в том, что старые ОС (win98,win95) не поддерживают юникода. А современные (w2k,win XP) основаны на юникоде. Поэтому, если мы пишем программу под все версии, то используем ASCII, а win 2000 win XP сами преобразут строки в вызовах, сохраняя одностороннюю совместимость. Если мы пишем исключительно под win2000, win xp, то сразу используем юникод и экономим на конвертации.

anonymous
()

Ja na Qt nikogda ne pisal, no muzhik po povodu MFC javno chego-to prognal! Po-mojemu, sudit on MFC po Master'u i po kodu, sozdavajemomu im. Nu, tak nilto zhe ne zastavl'ajet zapuskat etogo ujobka! (Zapuskajem NewProject->MFCAppWizard->tochno_ne_pomn'u_kakije_nastroiki->(Debug Configuration)->compile->run->"this program has performed ILLEGAL operation....... ;))

zelo_
()

Уже 5 лет использую MFC и сейчас изучаю QT как будушую алтернативу (ибо кроссплотформенная). MFC автор явно не знает - даже обсуждать нечего. По поводу Windows Forms - это не обертка "на кривой Win32 API" а обсолютно новая, в идеале кроссплатформенная библиотека, часть .NET Framefork.

p.s. да, во всех тредах где упоминался .NET на лоре: если человек пишет под dotNET, он не может юзать Win32 API - иначе, это неуправлемый dotNETом код, WIN32API и dotNET - эта РАЗНЫЕ ПЛАТФОРМЫ, господа, ну не надо писать глупостей, даже не узнав что это и зачем.

С уважением,oav

oav
()

Уже 5 лет использую MFC и сейчас изучаю QT как будушую алтернативу (ибо кроссплотформенная). MFC автор явно не знает - даже обсуждать нечего. По поводу Windows Forms - это не обертка "на кривой Win32 API" а обсолютно новая, в идеале кроссплатформенная библиотека, часть .NET Framefork.

p.s. да, во всех тредах где упоминался .NET на лоре: если человек пишет под dotNET, он не может юзать Win32 API - иначе, это неуправлемый dotNETом код, WIN32API и dotNET - эта РАЗНЫЕ ПЛАТФОРМЫ, господа, ну не надо писать глупостей, даже не узнав что это и зачем.

С уважением,oav

oav
()

logINу, сразу видно, что ты на GTK+ не писал, там это по-другому выглядит ;)

gregbg
()

>QT, насколько я понял, предполагает задание строковых констант в ASCII их последующее конвертирование в UNICODE функций (макросом) tr().

Неправильно ты понял. Qt хранит все! строки в уникоде. И функция tr() не занимается переводом их в уникод. Она занимается переводом строк на другой язык, переводом интерфейса, собственно (translate).

ANDI ★★
()
Ответ на: комментарий от oav

"под dotNET, он не может юзать Win32 API - иначе, это неуправлемый dotNETом код, WIN32API и dotNET - эта РАЗНЫЕ ПЛАТФОРМЫ, господа, ну не надо писать глупостей, даже не узнав что это и зачем"

Нпаконец-то разумные слова в этом дурдоме. Хотя это имхо глас вопиющего в пустыне. С фанатиками спорить бесполезно. .NET и MFC по-умолчанию говно только потому что это микрософт. А Qt это рулез только потому что это каким-то боком относится к линуху. Какие тут могут быть еще обсуждения?

Finder
()
Ответ на: комментарий от logIN

Обшибаешься, бОклан. GTK есть не Си, а всё, что угодно, потому как Си биндится к любым языкам без проблем. Как можно сравнивать хорошие языки вроде того же Питона со всяким отстоем вроде C++?!?

Antichrist
()

oav: >Уже 5 лет использую MFC и сейчас изучаю QT как будушую алтернативу (ибо кроссплотформенная). MFC автор явно не знает - даже обсуждать нечего.

И что, за пять лет ты не понял, какое это Г? Ясно же, что MFC написана без какого-либо понятия о проектировании. Навскидку два факта:

1. Двухшаговая инициализация объекта (полный маразм при наличии конструкторов).

2. Использование открытых членов-данных. Более того, рекомендация такого использования в новых классах! У меня глаза на лоб вылезли :)))

Так что согласен с этим Паскалем :)))

Другое дело, что в Microsoft не только дураки. Сделали вполне приличные библиотеки ATL и WTL.

hbee ★★★★
()
Ответ на: комментарий от logIN

>>"кстати, я тут программку некую фаял (чистый интерфейс - кнопочки и поля) так между гном\жтк и кутей чтобы перенести надо переписать очень немного..."

Программка была Hello World? Вот вот. <<

программка была расчетная: просто писалась _правильно_ - расчетная часть отдельно, интерфейсная - отдельно. Соответственно перенести с Qt на ЖТК пришлось переписать _очень немного_. Перенос был связан не с достоинствами\недостатками кути, а с тем, что еще несколько программ, (которые в частности генерили входные данные) были написаны на ЖТК.

anonymous
()

2hbee:
пример из учебника:
------------------
#include <stdio.h>

struct _t
{
	  _t() { printf("constructor\n"); throw 1; }
	  ~_t() { printf("destructor\n"); }
};

int main()
{
	
	try {
		_t t;
	} catch (...) {
		printf("exception\n");
	}

	return 0;
}
------------------
как ты думаешь, что будет выведено на экран? :)
это к вопросу о двухшаговой инициализация

qrot
()

ваще на motife надо писать

все-таки стандарт, да и удобная вещь вполне

anonymous
()
Ответ на: комментарий от hbee

Скажи, пожалуйста, ты на MFC писал? а Win32 API видел? что за "двухшаговая инициализация"?? Боюсь, ты архитектуры не знаешь

oav
()

2oav: если ты мне, то писал, видел, знаю :) пост был для hbee

qrot
()

И вообще двушаговая а не двуХшаговая.... p.s. эх..а на вопрос про кде в SuSe никто так и не ответил...

anonymous
()
Ответ на: комментарий от Antichrist

>Онанимусы LMD. Char вовсе никому не обязан быть 1 байт.
Не знаю как Char а вот char вроде бы 1 байт

В каком стандарте это не так ?

sS ★★★★★
()

2qrot:

Деструктор не вызовется? И что? :)

2oav:

Под двухшаговой инициализацией, или двушаговой, один чёрт :))), я понимаю код вроде:

C c;
c->Create(...);

которым изобилует MFC. А ты что? :)))

hbee ★★★★
()

тьфу, вместо -> точка... ну в данном случае это не важно :)))

hbee ★★★★
()
Ответ на: комментарий от sS

В ANSI :) char -- это минимальная единица адресации. Есть архитектуры (вроде MIPS) где char=4 байта.

И вообще, в C определяются только минимальные размеры типов. Типа char <= short <= int <= long <= long long char >= 8 бит short >= 16 бит int >= 16 бит long >= 32 бит long long >= 64 бит

anonymous
()
Ответ на: комментарий от hbee

ОК, тока надо разобраться что инициализируем и когда это нужно: C c; - инициализация экземпляра класса. (где угодно, там просто инится члены) c->Create() - создаем объект, который обарачивает класс. CWnd - окно. почему так? элементарно - для удобства программирования: class CMyMainWnd:public CFrameWnd { bla bla bla protected: CWnd m_MyChildWnd; }; чтобы было еслиб в конструкторе CWnd создавалась окно? ;)

аха! вот чтобы было: CWNd* m_pMyChildWnd; а в OnCreate m_pMyChildWnd = new CWnd; а в OnDestroy delete m_pMyChildWnd;

где удобнее? (несчитая туеву хучу пар-ов которые без доп-ой информации не известна на этапе компиляции) в Create'e?

по-мойму нормальный пример.

зы. извините за русский, времени нет, да и отвык от офф-лайн общения

oav
()

извините за глупый вопрос, а как обрыв строки ставить?

oav
()

2oav

То есть ты хочешь сказать, что как начали на костылях ходить, так и в трамвай не влезешь? :)))

Что ж, если людям удобно, хай живе MFC :))). Считай, что ты меня убедил.

hbee ★★★★
()

"Обрыв строки" - выбрать "User line breaks" или "Preformatted".

hbee ★★★★
()

2hbee: а то - есть у тебя гарантия что в конструкторе во время инициализации окна, к примеру, не произойдет исключения? если в конструкторе просто не возбуждается исключение при ошибке - как определить, что создание окна (а не объекта класса) прошла успешно?

qrot
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.