MFC vs Qt Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Rocky]

А я вот пока к студии больше склоняюсь в выборе инструмента для данной программы. Ибо там отладчик быстрее и удобнее

Так... Знаешь, я лет 5 писал с помощью студии.. (начиная с 6-й). Отладчик там может в чем-то и удобнее, но минусов в самой IDE намноооооого больше чем в QtCreator. MFC - говнотехнология, которая изжила себя наверное раньше, чем появилась.

Пиши тогда уж на асме сразу. Это очень круто. Хотя это дело твое на чем писать.

А заявление Rocky - это юношеский максимализм, такой же, как выдают линуксоиды про винду.

Это не максимализм. Предполагалось, что человек с иронией прочитает ее и немного улыбнется. А ты хочешь сказать, что все линуксойды страдают юнешским максимализмом и не любят винду только из-за этого? Это полный бред.

Сообщение отредактировал Rocky - 29.1.2011, 23:48

[Алексей1153]

Litkevich Yuriy, позволь я таки отвечу. И не буду больше разжигать это дело.

Это не максимализм. Предполагалось, что человек с иронией прочитает ее и немного улыбнется.

я уже настолько начитался подобных глупых высказываний, что предпочитаю вообще не реагировать. Но глаза открыть тебе охота (тебе же это и будет полезно)
1) я лет 5 сидел в студии 6 и 4 года в студии 9. Так что не надо мне расписывать про то, как и где там удобно
2) MFC это не говнотехнология, как ты наивно полагаешь, а необходимость. Это оболочка над WinAPI рутиной, которая по сути ничем не отличается от чистого API, посколько после компиляции буддут точно такие же вызовы API, ничуть не снижая производительности. Но MFC позволяет экономить время и силы, являясь оболочкой, превращающей чистый Си в почти ООП. Надеюсь, ты знаешь, как нежно дружат чистый Си и ООП. Отсюда и нападки на MFC. А мелкософтовцы молодцы - сделали почти невозможное.
А умирать MFC не собирается, а кроме того - поддерживается, включая и в последних версиях студии (в 10 - точно есть). Пока люди пишут программы под винду, MFC не умрёт.
3) за что линуксоиды не любят винду. А кто их знает Наверное за то же самое, за что я не люблю линукс. У всех разные цели и предпочтения.
4) отвечать на этот пост не нужно. Холиваров не будет!

Сообщение отредактировал Алексей1153 - 30.1.2011, 14:49

[Rocky]

Litkevich Yuriy, раздели пожалуйста тему... Я не могу пропустить обвинения в глупости в свой адрес.

Это оболочка над WinAPI рутиной, которая по сути ничем не отличается от чистого API, посколько после компиляции буддут точно такие же вызовы API, ничуть не снижая производительности.

Скажи, а ты пробовал писать мало-мальски нормальный OpenGL/DirectX-проект с использованием MFC? Попробуй. А потом перепиши его на чистом WinAPI. Потом сделай бенчмарки и удивись результатам.

Но MFC позволяет экономить время и силы, являясь оболочкой, превращающей чистый Си в почти ООП

А можно по-подробнее? Я что-то не понял при чем тут чистый С. Я ващет думал что MFC написан на С++. А... ты имеешь в виду что функции WinAPI написаны на С... Понятно. А, пардон, Qt тогда что? Для винды это не обертка над WinAPI? Та же самая обертка, только сделана лучше и продуманее. А почему я должен использовать какие-то непонятные громоздкие (практически недокументированные) С-структуры в функциях "Объекто-Ориентированного" MFC? Почему для реализации некоторых вещей, я должен использовать callback-вызовы и связанные с ними глобальные функции? Это по-твоему отличная ОО среда?

Насчет экономии времени и сил. Я несколько лет работал в конторе, для которой писал программу для спектрального анализа на MFC. В силу своей специфики там очень много всего (количесвто строчек не показатель конечно, но сотни полторы тысяч строк было). Написание самого кода на MFC заняло у меня около 1.5 лет. Потому что при попытке сделать что-то свое наталкиваешься на стену и ограничения MFC. А дальше 2 варианта: либо переписывать участки кода на чистом WinAPI (в итоге проект получается "грязным" и "некрасивым"), либо реализовывать то что нужно через такую ж. А на Qt все то же самое получилось за 4 месяца. И код стал намного более прозрачный, легче поддерживаемый. И объем стал на порядок меньше.

Отсюда и нападки на MFC

Нет. Нападки на MFC не отсюда. Я могу перечислить с десяток "особенностей" работы с MFC (это то, что осталось в моей памяти спустя 2.5 года не использования MFC). Эти "особенности" приводят к ночным посиделкам возле отладчика. Кому как, а я лучше с женой это время проведу. А то, что ты при знании Qt все равно склоняешься к написанию программы на MFC говорит о том, что ты не являешься спецом ни там, ни там.

А умирать MFC не собирается, а кроме того - поддерживается, включая и в последних версиях студии (в 10 - точно есть).

То, что его включают в новые версии фрэйморка еще не значит, что он поддерживается. "Поддержка" Qt3 тоже есть. И есть много людей, которые пишут с использованием Qt3. А добавляется ли что-то новое в Qt3 и фиксятся ли баги не в курсе? Что нового появилось в MFC с Visual Studio 6 по VS 2008 (2010)? Хоть один новый класс/контрол? Даже если что-то новое и появилось в VS 2010, то это уже похоже на агонию (10 лет не было абсолютно ничего нового). Скажешь что все итак супер? А почему тогда такое огромное количество дополнительных классов, контролов да и целых оберток над MFC? Я например не хочу и не буду использовать закрытый код дяди Васи в своих проектах. Хрен его знает что он там делает. Я лучше свой буду писать. Только зачем?

А ты когда последний раз был в книжном магазине? Какую новую книгу по MFC ты видел? Я например в качестве мини-хобби люблю ходить в магазины компьютерной литературы. Видимо, каждый раз до меня кто-то по MFC все скупает.. Жаль.

Да, и вообще-то мелкомягкие продвигают С# и платформу .NET (win forms и иже с ними) как средство разработки под windows. Но никак не MFC. То, что она включается в текущие версии студии лишь благодаря тому, что написано огромное количество программ с использованием MFC. Держу пари, что внутри MFC куча механизмов, которые для тебя (как и для большинства людей в мире) являются абсолютно непрозрачными.

за что линуксоиды не любят винду. А кто их знает Наверное за то же самое, за что я не люблю линукс. У всех разные цели и предпочтения.

Клевое высказывание. Я не люблю линукс. Точка. У тебя видимо стереотип сложности настройки/работы сей ОС. Ну-ну.

И вообще насчет студии. Вот ты за деньги разрабатываешь программные продукты. А студию ты купил? Или крякнутой пользуешься? А MSDN (который отдельно продается)?

ЗЫ.
Я не спорю, сама IDE удобная. Можно даже аттачиться к запущенным процессам и трассировать исходник. Отладчик - да, супер. Edit and continue - вообще вещь. Только gdb тоже можно настроить чтобы был думаю не хуже чем студийный. Но вот трактование стандарта С++ мелкомягкими - это пипец. Это хорошо, если ты соображаешь что делаешь.

Сообщение отредактировал Rocky - 31.1.2011, 10:47

[Алексей1153]

А можно по-подробнее?

Я не могу пропустить обвинения в глупости в свой адрес.

я такого и не говорил

Rocky, никто также не говорил, что везде следует MFC толкать, всё зависит от цели. А по производительности - это где-то у тебя ошибки были, значит, так как скорости теряться просто негде

А можно по-подробнее? Я что-то не понял при чем тут чистый С. Я ващет думал что MFC написан на С++. А... ты имеешь в виду что функции WinAPI написаны на С... Понятно. А, пардон, Qt тогда что? Для винды это не обертка над WinAPI? Та же самая обертка, только сделана лучше и продуманее. А почему я должен использовать какие-то непонятные громоздкие (практически недокументированные) С-структуры в функциях "Объекто-Ориентированного" MFC? Почему для реализации некоторых вещей, я должен использовать callback-вызовы и связанные с ними глобальные функции? Это по-твоему отличная ОО среда?

1) WinAPI написан на чистом C
2) Qt - это не оболочка, это библиотека. Если ты не заметил, в Qt окна рисуются графикой (только диалоги есть нативные ОС окна).
3) не хочется использовать недокументированное - не используй. Я не использую
4) при чём тут колбэки, я не понял, хотя бояться их - тоже непонятное дело. Они работают как раз гораздо быстрее сообщений винды или сигналов Qt
5) про какую среду ты говоришь ?

>>Насчет экономии времени и сил.
я сравниваю разработку на чистом АПИ и на MFC


>>Я могу перечислить с десяток "особенностей" работы с MFC
давай, я хоть узнАю про них. А с отладчиком все сидят, особенно, когда опыта ещё нет (только не подумай снова, что я тебя в неопытности обвиняю ) Опыт - он либо есть, либо его нет, в этом нет ничего обидного. Посидел с отладчико - получил опыт. В следующий раз сидеть будешь гораздо меньше)

Книги давно не покупаю, всё из справочников и из форумов черпается. Мне и читать то некогда стало

>>Да, и вообще-то мелкомягкие продвигают С# и платформу .NET
мн не нравится дотнет и шарп. Кто на нём пишет - писают кипятком от ООПшности, но как только более или менее нетривиальная задача возникает - заплакали, полезли АПИ вызовы делать... А Qt по графике обскакивает дотнет с лёгкостью.


>>У тебя видимо стереотип сложности настройки/работы сей ОС. Ну-ну.
не стереотип, а факт )

>>И вообще насчет студии. Вот ты за деньги разрабатываешь программные продукты. А студию ты купил? Или крякнутой пользуешься? А MSDN (который отдельно продается)?

конечно же версия сломанная. Ты же мне денег не пришлёшь, чтобы я её купил ) Про МСДН - не понял. Заходишь на сайт http://msdn.microsoft.com/ru-ru/library/ms123401.aspx, там всё бесплатно. По крайней мере ни разу не просили платить

>>Но вот трактование стандарта С++ мелкомягкими - это пипец.
примеры в студию

------------
а вообще - что так эмоционально реагируешь ? Тебя никто не обвиняет ни в чём.

Сообщение отредактировал Алексей1153 - 31.1.2011, 11:05

[Rocky]

я такого и не говорил

Ок

Qt - это не оболочка, это библиотека

А MFC - это оболочка или библиотека?

при чём тут колбэки, я не понял, хотя бояться их - тоже непонятное дело. Они работают как раз гораздо быстрее сообщений винды или сигналов Qt

Я их не боюсь. Могу конечно ошибаться (давно это было), но попробуй написать перебор всех окон в системе? Каким принципам ООП это будет не соответствовать?

про какую среду ты говоришь ?

Имел ввиду написание программ с помощью MFC. Может не самое удачное слово конечно.

я сравниваю разработку на чистом АПИ и на MFC

А, пардон, значит не так понял.

>>Я могу перечислить с десяток "особенностей" работы с MFC
давай, я хоть узнАю про них.

Ты меня троллишь? =)
1. При работе с ресурсами попробуй самовольно поменять идентификаторы в resource.h. Ну не нравится мне что они назначются не по порядку или начиная с 32000. Будут возникать косяки в самых разных местах. Потому что потом будут возникать коллизии идентификаторов.
2. Коллизии идентификаторов возникают даже, если не влезать в resource.h.
3. Если солюшен состоит и 5 проектов например, 4 из которых - это динамически подключаемые dll, а 1 - сам исполняемый модуль, который их подключает, не дай бог идентификаторы ресурсов будут где-то пересекаться. Проявления у меня были разные. Т.е. если идентификатор кнопки в одной dll имеет значение 5000, и в другой dll тоже 5000, то при нажатии на такую кнопку вообще все рушилось. И было абсолютно непонятно что и где и с какого момента отлаживать. Приходилось писать доп. прогу типа ResourceRedactor, который парсил resource.h и назначал уникальные номера.
4. Почему нельзя получать доступ к элементам управления окна не из экзэемпляра самого окна? Нужно дублировать данные в мемберах класса (видимо особенности механизма DDX/DDV). Если пробовать получить, возникают run-time ошибки.
5. Если я хочу создать свой класс (графический), то мне оказывается помимо new нужно еще и Create делать. А при удалении сначала Destroy, а потом delete. А попробуй создать вручную класс диалога. Например полностью в конструкторе другого класса. Это вообще возможно? Как реализовывать этот DDX?
6. Если у меня проект использует юникод, а я пытаюсь подключить к нему библиотеку не в юникоде - тоже будут проблемы. И далеко не очевидно как их решать.
7. Почему-то, где-то перед показом окна я должен переопределять обработчик OnInitDialog, а где-то OnInitialUpdate.
8. Используется устаревашая архитектура документ/вид. Как с каждым видом ассоциировать свои данные? Как разделять эти данные? И почему я вообще должен следовать таким принципам? Хочу сам создавать архитекуру приложения. Нельзя.
9. При создании нового класса с помощью ClassWizard (правда его после 6-й студии вроде убрали, забыл как называется в новых студиях эта штука) создается куча непонятного.... непонятных вещей. Попытки ручного добавления каких-то записей внутрь макросов DDX чреваты.
10. Попробуй не включить или включить не самой первой строкой в своем cpp stdafx.h. Возникает очень "понятная" ошибка.
11. Использование MFC совместно с COM - тоже не самые приятные воспоминания. Почему то даже при создании пустого проекта уже возникают ошибки линковки (причем как-то через раз). Зависело вроде от настроек multi threading. Типа несколько ф-й winmain (dllmain) в одном объектнике как-то получалось.
12. При работе с БД через ODBC (другие не пробовал, не знаю), возникают неочевидные ошибки рантайма при попытке считать одну и ту же запись 2 раза (причем на момент, когда я с ней столкнулся, почему-то нигде не было про это написано).
13. Я часто использую COM-подобный метод подключения внешних библиотек. Основан на создании интерфейса (со всякими AddRef/Release), реализации его в dll, и экспортируемой функции-фабрики классов из этой dll, возвращающей указатель на реализацию этого интерфейса в dll. Если в этом хидере интерфейса есть 30 методов, и в какой-то момент я решу удалить 27 например, то почему-то далеко не всегда (как я понял - "через раз") происходит смещение виртуальных таблиц. Т.е. при вызове 27-го по счету метода (после удаления), у меня вызывается 28-й. В итоге все рушится. Попытки deep clean ситуацию не проясняли. Видимо, что-то пишется куда-то еще. При использовании Qt такого не наблюдалось - тут все прозрачно.

А так....
1. Нет менеджеров компоновки и связанные с этим проблемы (например, при изменении шрифта программы или надписей в StaticText, сам текст в статиках может накладываться друг на друга - и про это нужно помнить и следить).
2. Нельзя добавлять содержимое к многим контролам прямо на форме.
3. Попытки сделать например CListCtrl с редактируемыми ячейками приводят к значительным потерям времени. А уж если я хочу чекбоксы туда вставить - вообще нужно свой custom control делать. Либо искать готовый.
4. Если я хочу изменить всего лишь цвет текста staticText, мне нужно изменить ему идентфикатор, поставить обработчик специальный, там ловить этот идентификатор, создавать нужную кисть, назначать ему эту кисть.... Слишком много всего.
5. В "форме атоматического добавления обрабочтков сообщений" приведены далеко не все нужные сообщения.
6. Нет поддержки xml. Работа с xml осуществляется через АПИ msxml.dll например.
7. Нет поддержки стилей, элементам управления нельзя задавать текст в html-формате.

Может, конечно, что-то и не убедительно я описал, звиняйте. 2 года назад было больше всего в голове. Основная мысль: MFC - была отличная библиотека лет 5-7 назад. Но когда я чутка подрос, и полюбил свободу - я понял, что MFC ограничивает меня - это раз. Я должен делать так, как решили разработчики библиотеки. И не отвечает моим требованиям - два. Она зависла на уровне 2000 годов. И к тому же, почему я должен таскать с собой всю платформу .NET для запуска маааленькой програмки? И далеко не все сейчас используют висту или семерку, в которой она предустановлена. А чтобы поставить ее, я должен убедиться, что установлен ли еще инсталлер специальный. И иметь доступ к интернету (что есть далеко не везде). Последнее вероятно относится не к MFC а к самой IDE.... В Qt-тоже не все гладко конечно.. Но мне нравится. А еще более основная мысль - вообще не следует быть фанатом чего-то одного. Ни ЯП и IDE.

>>У тебя видимо стереотип сложности настройки/работы сей ОС. Ну-ну.
не стереотип, а факт )

Это требует отдельного обсуждения =)

конечно же версия сломанная. Ты же мне денег не пришлёшь, чтобы я её купил ) Про МСДН - не понял. Заходишь на сайт http://msdn.microsoft.com/ru-ru/library/ms123401.aspx, там всё бесплатно. По крайней мере ни разу не просили платить

Ну вот. Я например использовал триал. И каждые 3 месяца ее переставлял. Хотя я все-таки предпочитаю использовать либо open-source, либо покупать. Хотя чаще конечно open-source. По-поводу MSDN - да, есть онлайн. Тебе повезло если у тебя нормальный провайдер. У меня бывает вот срочно нужен интернет, а пров грит "извините, 3 дня инета не будет". Поэтому я предпочитаю чтобы дома и под рукой было все, что нужно.

>>Но вот трактование стандарта С++ мелкомягкими - это пипец.
примеры в студию

Ну, мне например хватило следующего:

std::map<int, double> test_map;
test_map[0] = 1.0;
test_map[1] = 1.1;
test_map[2] = 1.2;
test_map[3] = 1.3;
test_map[4] = 1.4;

std::map<int, double>::iterator itTest = test_map.find(2);
if (itTest != test_map.end()) itTest->first = 10;

Вот такой код приводит к очень большим проблемам. То же касается std::set например.

а вообще - что так эмоционально реагируешь ? Тебя никто не обвиняет ни в чём.

Да нервный я стал совсем... Извини если что не так =) Видимо к психиатору пора ((((((

[Алексей1153]

Rocky, уж звыняй, много печатать не могу, рабочий процесс идёт!

А MFC - это оболочка или библиотека?

это библиотека-оболочка Библиотека - это же шота собранное в кучку. А тут собраны классы-вропперы , которые сгруппировали вызова АПИ-функций по смыслу

но попробуй написать перебор всех окон в системе? Каким принципам ООП это будет не соответствовать?

эээ... А зачем перебор окон должен почему то соответствовать ООП ? Ну напиши класс, инкапсулируй туда статическую функцию и список найдёнышей. Будет ООПшнее некуда!

про какую среду ты говоришь ?
Имел ввиду написание программ с помощью MFC. Может не самое удачное слово конечно.

вот меня тут пинают за оговорки (вроде студия==MFC, креатор ==Qt). Ну и как бы MFC - это не среда, это набор классов и функций. Разработчики сделали попытку превратить Си-рассыпуху в нечто более удобное и ООПшное. Сомневаюсь, что можно было сделать лучше. Но ведь писать на WinAPI приходится, а значит должен быть инструмент ухода от рутины, как это стал MFC (ну и множество других библиотек, я все и не знаю). Аналогия тут - машинныекоды(мамамия!)-ассемблер (ага, уже читабельно!) - макроассемблер (вау!)


Неа, не троллю.

При работе с ресурсами попробуй самовольно поменять идентификаторы в resource.h.

регулярно этим занимаюсь. И что ?

Коллизии идентификаторов возникают даже, если не влезать в resource.h.

у меня не возникали. Более того , если я студийный счётчик собью в resource.h, - ни шестёрка, ни девятка даже бровью не ведут, исправляют ди и всё. Ну не знаю - не было у меня таких проблем!



(дописал ))) )

3 - у каждого проекта свой ресурсный файл. У меня 3 проекта в одном решении - не пересекаются вроде

4 - как это нельзя ? GetDlgItem(ID). Но нельзя сохранять и использовать указатели и хендлы контролов, которые описаны шаблоном диалога. А вот свои собственные, созданные без DDX - пожалуйста

5 - Create - создаёт объект Windows HWND . Если ты можешь сделать это иначе - вперёд

6 - переведи однобайтовый в юникод. (WCHAR, wstring, _T("") )

7 - OnInitDialog - мембер класса CDialog, OnInitialUpdate - класса CView. В Qt тоже есть методы, не общие для всех классов

8 - я не использую. Я класс документа не заполняю никогда, у меня всё во вьюхе

9 - в девятке визард убогий. Но к MFC это никак не относится - делай вручную, да и всё ) Всё лишнее можно и удалить после создания класса. А глюки при правке - это уж, извините, не правки виноваты, а когда не знаешь, как это делается

10 - Но никогда вручную править DDX не приходилось - я не пользуюсь UpdateData() , только GetDlgItem(). А промоушены визард расставляет нормально

11 - COM не приходилось использовать.

12 - работал с FireBird через CDataBase + CRecordSet. У меня всё работало ) А для mysql вызываю их нативные функции, без посредников

13 - не знаю, о чём речь, не могу сказать. Скорее всего поможет полный ребилд



1 - менеджеры компоновки в студии особо не нужны, там всё кнопками выравнивается в редакторе форм

2 - какое содержимое ?

3 - да, придётся один раз написать свой класс. Всё за тебя не напишут (повторюсь, что MFC - это лишь скромный вроппер АПИ)

4 - CWnd::OnCtlColor

5 - это ты про студию №6 ? В девятке всё есть. Ну а чего нету - смотришь в МСДН, копируешь обработчик. Или ещё проще - в оконной процедуре лови сообщение сразу

6 - я применял Markup113 . Могу приложить, если интересно

7 - это см пункт 3. Когда нужна графика - выбирай другой инструмент, тот же Qt


Дотнет таскать с собой не надо, конечно же. Мне тоже не нравится этот монстр. К счастью, это не единственная платформа в мире для винды )))


>>Ну вот. Я например использовал триал. И каждые 3 месяца ее переставлял.
это твои личные садо-мазо-программистские склонности Но в данной теме это не нужно обсуждать, я думаю.


>>itTest->first = 10;Language: cpp
компилятор не даст поменять ключ без неявного приведения. Ты точно это пробовал ?
и к каким проблемам привело ?

Сообщение отредактировал Алексей1153 - 31.1.2011, 13:32

[Rocky]

Ну и как бы MFC - это не среда

Вот пристал =) Я имел ввиду что не среда в смысле IDE ессно, а в смысле окружение программного кода.

4 - как это нельзя ? GetDlgItem(ID).

Т.е. хочешь сказать что я могу получить текст из CEdit например но не из класса который инкапсулирует объект этого CEdit? Ок, чисто ради интереса освежу в памяти этот момент... Тока надо бы найти 6-ю студию. Но я помню свое удивление, когда я понял, что в Qt можно делать так:

class Ui_MainWindowClass
{
   public:
    QPushButton *btn;
};

class MainWindow : public Ui_MainWindowClass
{
...
};

MainWindow::MainWindow()
{
   btn = new QPushButton();
}

int main(...)
{
   MainWindow *p = new MainWindow();
   p->btn->setWindowText(...);
}

3 - у каждого проекта свой ресурсный файл. У меня 3 проекта в одном решении - не пересекаются вроде

В том-то и дело что разные ресурсные файлы. Но там может дело было в том, что я на форму из основного приложения клал формы то с одной, то с другой dll (делая при этом их чайлдами главной формы)

5 - Create - создаёт объект Windows HWND . Если ты можешь сделать это иначе - вперёд

Ну как-бы да. Но ведь я не пишу:

QPushButton *p = new QPushButton(...);
p->Create(....);

работал с FireBird через CDataBase + CRecordSet. У меня всё работало )

MS Access + ODBC (класс не вспомню уже какой). Вот при таком (читать как псевдокод):

query.record(0);
query.record(0);

все падало. 2 раза нельзя считывать.

менеджеры компоновки в студии особо не нужны, там всё кнопками выравнивается в редакторе форм

Ну конечно. Разворачиваем окно и что с кнопками? Сами ресайзятся? Сделай локализацию. Помести в CStaticText "вот такую строку" типа для русской локали. А потом поменяй на английскую. И задай в тот же статик "this string is situated in static-text-class!!!". И что будет с CStaticText? Сам изменится в размерах и сделает zoomToFit? Или текст обрежется? Да, вот что еще вспомнил... Помести в тот же CStaticText строку из например 1000 символов. И запусти. До 2003 студии включительно при попытке отображения диалогового окна с таким CStaticText программа падала.

2 - какое содержимое ?

Я могу например заранее не влезая в код сформировать список CListCtrl? Имею ввиду прямо на форме.

4 - CWnd::OnCtlColor

Да, именно он ).

>>itTest->first = 10;
компилятор не даст поменять ключ без неявного приведения. Ты точно это пробовал ?
и к каким проблемам привело ?

Ну, 2008 студия глотает без проблем. Повторюсь, то же относится к std::set. К каким проблемам... Ну, например может не правильно работать std::map::find после такого. И оно понятно почему.

Сообщение отредактировал Rocky - 31.1.2011, 14:14

[Алексей1153]

Вот пристал =)

замечу, это не я пристал. Кто попросил отделить тему и продолжил задавать вопросы ?

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

не только хочу сказать, но только так и возможно - по ID контрола. Даже межпроцессорно, но только тут надо чистый АПИ применять, а то реакции не будет. Ещё один момент отмечу: CEdit инкапсулирует HWND и всё. Хендл окна. Но в классе добрые разработчики прописали много полезных функций - какие то являются вропперами API, какие-то уникальны для CEdit

Ещё один фокус: к примеру, имеется хендл HWND h. Неважно, как его создали, но важно, что это виндовый нативный класс edit control. Можно сделать так:

CEdit e; //e.m_hWnd==0;
e.attach(h); //e.m_hWnd==h;

<...> //работаем с 'e' как с обычным готовым CEdit

e.detach();//e.m_hWnd==0;

усё

все падало. 2 раза нельзя считывать.

не нашёл у себя использования метода record(0); - может и нет такого в этих классах, которые я упомянул
А снапшот, к примеру, нельзя читать в произвольном порядке, только в одном направлении
А чтоб не падало, лови исключения

Ну конечно. Разворачиваем окно и что с кнопками? Сами ресайзятся?

сгруппировать ID в массивы и вручную размещать по нужной сетке в OnWindowPosChanged();

класс CStaticText не знаю.

>>Я могу например заранее не влезая в код сформировать список CListCtrl? Имею ввиду прямо на форме.
это можно и нужно делать в OnInitDialog. Ну представь - а где будут храниться введённые тобой строки, если окна ещё нет ? Даже в конструкторе класса этот контрол ещё не создан

>>Ну, 2008 студия глотает без проблем.
я попробовал в 2008 - ругается на попытку изменить константный мембер



более того, попробовал в шестёрке - тот же результат

: error C2166: l-value specifies const object

[Rocky]

сгруппировать ID в массивы и вручную размещать по нужной сетке в OnWindowPosChanged();

Ну так тебе самому это нужно делать. Руками. А в Qt за эти следят менеджеры компоновки.

не нашёл у себя использования метода record(0); - может и нет такого в этих классах, которые я упомянул

Я ж написал что это псевдокод. Такого метода может и нет. Смысл в том что это "запись полученная из БД в результате запроса SQL".

А чтоб не падало, лови исключения

Дело не в том чтобы ловить исключения. Напишите в MSDN что так делать нельзя. Напишите спецификацию исключений этой функции. Этого ведь нет.

>>Я могу например заранее не влезая в код сформировать список CListCtrl? Имею ввиду прямо на форме.
это можно и нужно делать в OnInitDialog. Ну представь - а где будут храниться введённые тобой строки, если окна ещё нет ?

Ну а где они хранятся в редакторе форм QtDesigner? Что же это за Visual Studio, в которой я не могу прямо на форме заполнить комбобокс? Или список какой-нить?

>>Ну, 2008 студия глотает без проблем.
я попробовал в 2008 - ругается на попытку изменить константный мембер

Весьма странно. Хотя может это дистр такой у меня? Приду домой проверю.

[Алексей1153]

Ну так тебе самому это нужно делать. Руками. А в Qt за эти следят менеджеры компоновки.

Вот, кстати! Ты недоумеваешь, зачем и почему существует MFC и не собирается умирать. А ведь он делает с АПИ то же самое - избавляет от многой рутины ( как и все прелести Qt) . Ну а полной аналогии и соотвествия между библиотеками не ищи - они устроены по разному и для разного предназначены.

Напишите в MSDN что так делать нельзя. Напишите спецификацию исключений этой функции. Этого ведь нет.

без конкретных примеров я тут ничего не могу прокомментировать

Ну а где они хранятся в редакторе форм QtDesigner?

сначала они записываются в XML, а при компиляции попадают непосредственно в конструктор диалога (вернее, вызов setup происходит оттуда)

Сообщение отредактировал Алексей1153 - 31.1.2011, 15:14

[DEADHUNT]

Ну, мне например хватило следующего:

std::map<int, double> test_map;
test_map[0] = 1.0;
test_map[1] = 1.1;
test_map[2] = 1.2;
test_map[3] = 1.3;
test_map[4] = 1.4;

std::map<int, double>::iterator itTest = test_map.find(2);
if (itTest != test_map.end()) itTest->first = 10;

Вот такой код приводит к очень большим проблемам. То же касается std::set например.

нельзя изменять ключ у существующего элемента(тем более у типа first есть модификатор const, поэтому без явного приведения типов твой код не скомпилируется), у тебя код не правильный с точки зрения логики и стандарта, VC++ тут не причём.

Сообщение отредактировал DEADHUNT - 31.1.2011, 16:22

[Rocky]

нельзя изменять ключ у существующего элемента(тем более у типа first есть модификатор const, поэтому без явного приведения типов твой код не скомпилируется), у тебя код не правильный с точки зрения логики и стандарта, VC++ тут не причём.

Ну я ж не из головы его выдумал. Естественно неправильный. Попробую найти в исходниках где так делал (если найду - на тот момент я не использовал системы контроля версий)...

[Алексей1153]

Ну я ж не из головы его выдумал. Естественно неправильный. Попробую найти в исходниках где так делал (если найду - на тот момент я не использовал системы контроля версий)...

не нужно искать. Вполне возможно, что тебе просто запомнилось что-то не так (наверняка эмоции били через край ). Я же попробовал - компилятор не пропускает. Вряд ли у тебя была другая версия студии

Сообщение отредактировал Алексей1153 - 31.1.2011, 18:08

[Iron Bug]

ничо вы тут холивары развели
а я поддержу мнение Rocky, не в смысле, что я за Qt (я просто с ним не работаю), а против MFC. из моего многолетнего опыта программирования (профессионально и для себя) я поняла, что те, кто писал MFC, видимо, никогда ею не пользовались сами. иначе они бы давно поправили то море багов и недочётов (да даже просто банальных глупостей!), которое там имелось, имеется и, видимо, так и будет существовать до конца мелкософта.
ну и как системный программист, конечно же, я предпочитаю линюкс. и я ещё раз в этом убедилась, написав тут недавно по работе драйвер под семёрку: мелкософт зарывается в индусский говнокод. и он повсюду. он не только в MFC, он даже в самих основах системы. там полно багов, нестыковок и нелогичных ни с какой точки зрения решений. в общем, удовольствия для программиста мало, а для юзера - нестабильность, лишние деньги и необходимость приобретать неоправданно мощное железо. единственное, за счёт чего держится мелкософт - за счёт распространённости и того, что под них написано много прикладного ПО, чисто исторически. но уже идёт процесс: сторонние фирмы начали присматриваться к линюксу и писать свои софтины под него. если мелкософт не перестанет писать говнокод - они окончательно забредут в тупик и лопнут. видимо, поэтому Гейтс отошёл от дел и перевёл свои сбережения в туристический бизнес.

[Алексей1153]

Iron Bug,

а против MFC.

ну это твоё личное право. Но вот любопытно, как связано написание драйверов и глюки MFC ?

Про производительность - это опять загибон. Как напишешь - так и будет тормозить. У меня не тормозит

[Rocky]

Iron Bug, спасибо =)

Да, насчет std::map я погорячился... Ну а вот это как?

std::set<int> test_set;
test_set.insert(0);
test_set.insert(1);
test_set.insert(2);
test_set.insert(3);
test_set.insert(4);

std::set<int>::iterator itTest1 = test_set.find(2);
if (itTest1 != test_set.end()) *itTest1 = 7;

std::set<int>::iterator itTest2 = test_set.find(7);
if (itTest2 != test_set.end()) 
{
    //вот сюда мы не попадем
    qDebug() << *itTest2;
}

Сообщение отредактировал Rocky - 31.1.2011, 19:38

[Алексей1153]

напиши комментарии - я не знаю, что должно произойти (этим классом не доводилось пользоваться)

Сообщение отредактировал Алексей1153 - 31.1.2011, 19:44

[Rocky]

напиши комментарии - я не знаю, что должно произойти

В смысле? К чему писать? Там же итак коммент есть....

std::set - ассоциативный массив (коллекция). В нем ни в коем случае нельзя изменять данные напрямую. К чему это приводит я там коммент оставил... По названиям ф-й думаю если работаешь с std::map должно быть понятно.

[Алексей1153]

std::map я понимаю, что такое ключ - тоже.


почитал МСДН, вижу, что ты неправильно работаешь с классом:

The STL container class set is used for the storage and retrieval of data from a collection in which the values of the elements contained are unique and serve as the key values according to which the data is automatically ordered. The value of an element in a set may not be changed directly. Instead, you must delete old values and insert elements with new values
.

may not - значит не нужно, но не запрещено.
must delete old values - обязательно должен удалить старое значение, а потом только insert elements with new values

И это, кстати, не ассоциативный массив, а просто набор уникальных элементов, отсортированных по предикату

Сообщение отредактировал Алексей1153 - 31.1.2011, 20:00

[Rocky]

Так блин... Я знаю что это неправильно. Но почему nmake такое пропускает даже ворнинга не выдает???? Я знаю это сейчас, а по началу были очень большие грабли.

почитал МСДН, вижу, что ты неправильно работаешь с классом:

Извини не удержусь.... капитан очевидность )))))))))))))))))))))))))))))))) Я ж специально привел неправильный пример чтобы показать, что компилятор мелкомягких допускает такие вещи....
Это должно быть forbidden. gcc ведь ругается на такие конструкции.
И более того, чтобы понимать почему это должно быть forbidden нужно понимать как вообще устроен std::set


-----
UPD

4. Почему нельзя получать доступ к элементам управления окна не из экзэемпляра самого окна?

4 - как это нельзя ? GetDlgItem(ID).

Создал тестовый MFC/SDI проект. VS 2008. Открыл в ресурсах диалоговое окно "About - IDD_ABOUTBOX". Перетащил мышью на форму кнопку. У нее идентификатор IDC_BUTTON1. Файл test2.cpp:

void Ctest2App::OnAppAbout()
{
    CAboutDlg aboutDlg;
    CWnd *pWnd = aboutDlg.GetDlgItem(IDC_BUTTON1); //вот тут ошибка (пока не понятно почему)
    pWnd->SetWindowTextW(_T("bla-bla-bla"));          //и вот тут ошибка (потому что pWnd  == NULL)
    aboutDlg.DoModal();
}

Почему так??? Я ведь создал экземпляр класса. Я ожидаю, что получу доступ ко всем его открытым методам/членам. Так почему же ошибка???? Ах, вспомнил. Дело в том, что нужно помнить, что вызов CDialog::DoModal() инициирует вызов функции CDialog::OnInitDialog(), в котором и создаются элементы управления этого диалогового окна. Таким образом, чтобы инициализировать элементы управления диалогового окна, единственное где я могу это сделать - только из самого окна. Нужно писать функцию Init(), которую вызывать сразу после создания экземпляра класса, в нее передавать нужные параметры классу. Но в самой Init() еще нельзя выводить эти данные в элементы управления, потому что CDialog::OnInitDialog() еще не был вызван. Таким образом, даже если мне эти данные и нафиг не нужны потом, я должен их сохранять в мемберах. Вот одно это уже убивает. Если здесь есть обходной путь, расскажи пожалуйста... Я честно не знаю. =)

Сообщение отредактировал Rocky - 31.1.2011, 21:01

[Алексей1153]

Rocky, я понял - это map без mapped_value

А по моему, это ты допускаешь такие ошибки, а не компилятор

[Iron Bug]

Но вот любопытно, как связано написание драйверов и глюки MFC ?

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

[Алексей1153]

CAboutDlg aboutDlg;
CWnd *pWnd = aboutDlg.GetDlgItem(IDC_BUTTON1); //вот тут ошибка (пока не понятно почему)

всё понятно - ты не создал диалог

поясню, ты только выделил память под HWND , и присвоил ему 0

А создавать объект окна не стал

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

любимая песня линуксоидов, причём обычно бездоказательная, а просто "патамушта"



Сообщение отредактировал Алексей1153 - 31.1.2011, 21:06

[Rocky]

Цитата(Rocky @ 31.1.2011, 23:00)
CAboutDlg aboutDlg;
CWnd *pWnd = aboutDlg.GetDlgItem(IDC_BUTTON1); //вот тут ошибка (пока не понятно почему)
всё понятно - ты не создал диалог

Как это не создал? Я так понимаю DoModal его создает? Или нет? А как его создать до того, как сделать его модальным и вывести?

[Алексей1153]

Rocky, DoModal - да , создаёт объект окна диалога и делает его модальным. А Create создаёт и не делает модальным

А как его создать до того, как сделать его модальным и вывести?

это не сделаешь никак, но это и не требуется

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

[Iron Bug]

ну а если говорить про STL, то у мелкософта с со студии 2005 и до сих пор(!) есть глюк: у vector, deque (возможно, ещё с какими-то объектами, подобными этим) есть страшная бага: при работе в разных потоках с началом и хвостом они портят собственные внутренние указатели и затирают содержимое. обойти это разруливанием мьютексами невозможно (я про это писала тут: http://www.forum.crossplatform.ru/index.ph...st&p=40815). причём мелкософт знает о баге и обещает (может быть) поправить её в студии 2011. а пока - увы! просто нельзя юзать STL шаблоны в полном объёме.

[Алексей1153]

Iron Bug, с вектором активно работаю в нескольких потоках, ничего не рушится. Может, ты просто какой-то фокус над ними совершаешь ? А с декью я не работал ни разу, но я ту тему помню

[Rocky]

Rocky, я понял - это map без mapped_value

Что-то вроде того. Да.

А по моему, это ты допускаешь такие ошибки, а не компилятор

Эм... ну как бы готов поспорить. Это называется нестрогое соответствие стандарту. Я понимаю что сам дурак. Но можно ведь поставить защиту от его самого? Сейчас да, я более внимательно изучаю документацию и более тщательно подхожу к разработке... Но когда такие вещи делал, еще учился можно сказать. И никак не ожидал такого.

[Алексей1153]

Iron Bug, к твоей нежной любови к мелкософту можно подойти со следующей стороны: много людей пользуются виндой и не стремятся бежать под клёвый-растакой линукс, почему-то. Затем. Они пользуются софтом - приложения, драйвера. Им это надо. А раз им это надо, на них можно зарабатывать деньги - писать им этот софт. И можно ругаться сколько хочешь, но пока они платят за софт, мы всё равно будем писать под этот кривой-растакой_мать_его_за_ногу виндовс

Но когда такие вещи делал, еще учился можно сказать.

все учатся...

а вот как компилятор защитит тебя от следующего:

std::map<int,int> m;
m[1]=10;
m[2]=20;
m[3]=30;
std::map<int,int>::iterator it2=m.find(2);
m.erase(1);

int i=it2->second; //тук! скорее всего упали

[Iron Bug]

пока они платят за софт, мы всё равно будем писать под этот кривой-растакой_мать_его_за_ногу виндовс

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

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

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

Сообщение отредактировал Iron Bug - 31.1.2011, 21:49

[Rocky]

Iron Bug, к твоей нежной любови к мелкософту можно подойти со следующей стороны: много людей пользуются виндой и не стремятся бежать под клёвый-растакой линукс, почему-то. Затем. Они пользуются софтом - приложения, драйвера. Им это надо.

Знаешь, те кто говорит что "мне нравится винда/итак все устраивает" (имею ввиду десктопные версии) скорее всего сильно малограмотные, не думающие, и ни к чему не стремящиеся люди.

Что касется меня, я, к великому сожалению, не смог отказаться от винды полностью (но я ее ненавижу). Потому что в данный момент пишу под symbian ^ 3, а в линуксе можно разве что в эмуляторе симбы сидеть. Ну либо тратить время и допиливать SDK нокии. И плюс допиливаю программу для спектрального анализа, в которой требуется подключение USB-контроллера, драйвер к которому разрабы написали только под винду.

Вообще, мне это напоминает анекдот (правда он про айфоны - но в данном случае тоже пойдет). Примерно так: Стив Джобс разработал новую модель автомобиля. Но он не умеет поворачивать и ездить задним ходом! "Ну и что?" - сказали пользователи нового автомобиля - "Это нам и не нужно!"...

а вот как компилятор защитит тебя от следующего:

Ну тут очевидно никак. А в моем примере - мог бы. g++ ведь может. Всего-то нужно - соблюдайте строго стандарт. Да, вот навводили они функций "непонятных" типа _sscanf_s_l(...). Поэтому даже если ты просто пишешь прогу, без использования MFC/WinAPI можешь нарваться потом на грабли при переносе кода. А вот ниасилил я стандарт. Да и нету у меня его, он денег стоит. И понатыкал в код таких вот штук - все, получай!... Можно ведь этого избежать. Но это уже к MFC не относится... как и то что выше... Вообще, отклонились что-то

Сообщение отредактировал Rocky - 31.1.2011, 21:55

[Алексей1153]

в общем, будущее покажет

покажет - увидим

если ты будешь активно юзать шаблоны, которые обращаются к началу и хвосту объекта

какого объекта ? Или ты имеешь в виду begin() \ rbegin() ? Так я их и так активно пользую - всё нормально

[Rocky]

А может обсудим какие плюсы/минусы у MFC и QT? Может нормальную статейку потом забабахаем?

[Алексей1153]

(но я ее ненавижу).

равнодушие - это было бы самое страшное

[Алексей1153]

А может обсудим какие плюсы/минусы у MFC и QT? Может нормальную статейку потом забабахаем

не, я писать не буду, мне некогда и незачем. А ты, если хочешь написать, сначала определись - относительно чего плюсы и минусы )

[Влад]

.... у vector, deque (возможно, ещё с какими-то объектами, подобными этим) есть страшная бага: при работе в разных потоках с началом и хвостом они портят собственные внутренние указатели и затирают содержимое. обойти это разруливанием мьютексами невозможно....

Тут дело, насколько я понимаю, вообще не в потоках, а в ошибке в конкретной реализации deque, что и признала MS. Что же касается разных потоков, то текущий Стандарт вообще не дает никаких (!!!) гарантий о потоковой безопасности любых контейнеров STL. Вывод: работа с одним контейнером из разных потоков без блокировок - добровольное хождение по минному полю.

Ну а что касается реализации STL от MS (Dunkumware?), то, если нужно справиться с данной конкретной ошибкой - ее-то как раз очень просто заменить на SGI, STLPort или любую другую по твоему выбору. Их есть штук шесть разных реализаций, по-моему....

[Алексей1153]

Вывод: работа с одним контейнером из разных потоков без блокировок

это как так ? Без блокировок в этом случае категорически нельзя. Разве что лабу в школе сдать сгодится