Посоветоваться хочу, наметилась тенденция связанная то ли со зрелостью технологий .NET/Qt, то ли с заклинаниями об окончаниями кризиса, но пошли косяком предложения от разных контор, переписывать компоненты, ранее написанные на MFC с помощью одной из вышеупомянутых технологий. Что такое в данном контексте "компонент" — не спрашивайте, ни один из предлагающих так и не смог мне внятно этого объяснить (HR-ы, фига ли). Вопрос собственно, стоит ли изучить MFC? В свое время я пользовал VCL, был счастлив и молод , так вот, слышал мнение что использование MFC — процесс весьма нетривиальный. С другой стороны, заказчики финансово завлекаютЬ и предлагают даже дать время на ознакомление с библиотекой. По книжке для освоения у меня даже сомнений никаких — Круглински форевер. Хочется услышать мнение работавших с этой библиотекой, насколько оно сложно?
Здравствуйте, Alex Dav, Вы писали:
AD>Здравствуйте, sourcerer, Вы писали:
S>>...Хочется услышать мнение работавших с этой библиотекой, насколько оно сложно?
AD>да как и все остальное — поковыряешься немного и поймешь. Основы конечно почитать хорошо бы — что бы понимать логику работы, а так обычное ООП.
Message Map's и завязка всего и вся на обмен сообщениями через WndProc это ООП?
В частности, получение текста путем посылки хендлу визуального элемента сообщения WM_GETTEXT это ООП?
Видать, это какое-то очень уж специальное ООП...
Здравствуйте, StandAlone, Вы писали:
SA>Видать, это какое-то очень уж специальное ООП...
ваше предложение?
насколько я помню — все элемны построенные по схемы наследования и копозиций классов — это не ООП?
Здравствуйте, StandAlone, Вы писали:
SA>Message Map's и завязка всего и вся на обмен сообщениями через WndProc это ООП? SA>В частности, получение текста путем посылки хендлу визуального элемента сообщения WM_GETTEXT это ООП? SA>Видать, это какое-то очень уж специальное ООП... :xz:
Так вроде бы в истинном ООП и нет методов, только сообщения. Так вроде бы даже у Буча написано
Здравствуйте, COFF, Вы писали:
SA>>В частности, получение текста путем посылки хендлу визуального элемента сообщения WM_GETTEXT это ООП? SA>>Видать, это какое-то очень уж специальное ООП...
COF>Так вроде бы в истинном ООП и нет методов, только сообщения. Так вроде бы даже у Буча написано
ОКОННЫЕ? Низкоуровневая деталь реализации конкретной ОС, выставленная наружу- это ООП? Стиль MFC даже на С с классами не тянет, нарушены практически все принципы, начиная с SRP и Separation of Concerns, заканчивая банальной инкапсуляцией... для сравнения достаточно посмотреть хотя бы на упомянутую VCL.
А MFC мне напоминает Photon GUI, с виджетами и описывающими их структурами, в QNX 4.25... но там хотя бы честный C.
Хотя Photon продуманее, логичнее и структурированнее на порядок, несмотря на период разработки и специфичность ОС.
Здравствуйте, StandAlone, Вы писали: SA>Message Map's и завязка всего и вся на обмен сообщениями через WndProc это ООП? SA>В частности, получение текста путем посылки хендлу визуального элемента сообщения WM_GETTEXT это ООП? SA>Видать, это какое-то очень уж специальное ООП...
CWnd::GetWindowText
А посылка сообщения с хэндлом к mfc мало относится, хотя порой приходится использовать.
Вообще я на нем интерфейсики ваяю и по сей день (ну не приемлет контора .net) и ничего, плевался и брыкался только первые три месяца
Здравствуйте, StandAlone, Вы писали:
SA>ОКОННЫЕ? Низкоуровневая деталь реализации конкретной ОС, выставленная наружу- это ООП? Стиль MFC даже на С с классами не тянет, нарушены практически все принципы, начиная с SRP и Separation of Concerns, заканчивая банальной инкапсуляцией... для сравнения достаточно посмотреть хотя бы на упомянутую VCL.
А почему нет? Windows API — само по себе объектно-ориентированное. Есть объекты — окна, есть сообщения которые им посылаются. При этом любой объект может получить любое сообщение и как-то на него прореагировать. Инкапсуляция полная — ты не поможешь повлиять на объект иначе как посылкой ему сообщения. А MFC — это просто тонкая прослойка над WinAPI, которая осуществляет отображение классов C++ на классы-окна. Цель полностью скрыть системные вызовы перед MFC и не ставилась, поэтому сложно вменять это MFC в вину. Зато ты можешь взять любое окно и связать его с классом MFC и работать с ним. На VCL это сделать не получится. Тут просто совсем другая идеология.
Здравствуйте, Handie, Вы писали:
AD>>да как и все остальное — поковыряешься немного и поймешь. Основы конечно почитать хорошо бы — что бы понимать логику работы, а так обычное ООП.
H>Эту "хрень" лучше не понимать, о то, не дай бог, поймете. MFC это пример совершенно бездарно сделанного фреймворка
Зато GUI на MFC не тормозит и жрёт минимум памяти. В отличие от Qt/.Net, которые полноценно вытягивают только довольно мощные машины.
Здравствуйте, IID, Вы писали:
IID>Зато GUI на MFC не тормозит и жрёт минимум памяти. В отличие от Qt/.Net, которые полноценно вытягивают только довольно мощные машины.
Допольно мощные это какие? PIII? (на PIII .NET уже без проблем работает) А ничего что они выпускались уже лет 10 назад? Или до 2028 года надо поддерживать 200-мегагерцовые процессоры?
MC>Допольно мощные это какие? PIII? (на PIII .NET уже без проблем работает) А ничего что они выпускались уже лет 10 назад? Или до 2028 года надо поддерживать 200-мегагерцовые процессоры?
К примеру Intel Atom он по мощности примерно как PIII получится. И памяти обычно рядом с ним вовсе не гигабайты. Для 2010 года — нормальная конфигурация
Здравствуйте, TarasCo, Вы писали:
MC>>Допольно мощные это какие? PIII? (на PIII .NET уже без проблем работает) А ничего что они выпускались уже лет 10 назад? Или до 2028 года надо поддерживать 200-мегагерцовые процессоры? TC>К примеру Intel Atom он по мощности примерно как PIII получится. И памяти обычно рядом с ним вовсе не гигабайты. Для 2010 года — нормальная конфигурация
Ну и абсолютно без проблем на нем будут .NET приложения работать. У нас в офисе раньше самые слабые компы были PIII-800 / 512Mb — все отлично шло.
COF>А почему нет? Windows API — само по себе объектно-ориентированное. Есть объекты — окна, есть сообщения которые им посылаются. При этом любой объект может получить любое сообщение и как-то на него прореагировать. Инкапсуляция полная — ты не поможешь повлиять на объект иначе как посылкой ему сообщения. А MFC — это просто тонкая прослойка над WinAPI, которая осуществляет отображение классов C++ на классы-окна. Цель полностью скрыть системные вызовы перед MFC и не ставилась, поэтому сложно вменять это MFC в вину. Зато ты можешь взять любое окно и связать его с классом MFC и работать с ним. На VCL это сделать не получится. Тут просто совсем другая идеология.
Да какая там объектность? Низкоуровневый процедурный API с колбэками. Вот типовой Win32 вызов
HWND CreateWindowEx(
DWORD dwExStyle,
LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
);
Может в конце 80x или начале 90x это был сильно прогрессивный API, то сейчас это устаревщий по дизайну низкоуровневый API.
Вот код — напомните мне все четыре параметра по памяти:
Код Qt читается изумительно прежде всего за счет объектности, перегрузки, неймспейсов, активного использования enum вместо BOOL/INT и т.д.
На Qt или .Net прога пишется в разы быстрее — не надо использовать уродский API с кучей параметров в простых вызовах и изобретать велосипед на маломальски "нестандартную" задачу (парсинг XML, чтение PNG, HTTP и другие стандартные ныне вещи).
А GDI это вообще песня. Когда есть Apple Quartz2D и Qt QPainter с антиалиасингами, трансформациями и сложными блендами GDI выглядит полнейшим анахронизмом.
SA>ОКОННЫЕ? Низкоуровневая деталь реализации конкретной ОС, выставленная наружу- это ООП? Стиль MFC даже на С с классами не тянет, нарушены практически все принципы, начиная с SRP и Separation of Concerns, заканчивая банальной инкапсуляцией... для сравнения достаточно посмотреть хотя бы на упомянутую VCL. SA>А MFC мне напоминает Photon GUI, с виджетами и описывающими их структурами, в QNX 4.25... но там хотя бы честный C. SA>Хотя Photon продуманее, логичнее и структурированнее на порядок, несмотря на период разработки и специфичность ОС.
Хорошо сказано, вместо функции обработки сообщений окон надо писать кучу методов класса которые обрабатывают те-же WM_SOME_SHIT, вот и вся разница.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, IID, Вы писали:
IID>>Зато GUI на MFC не тормозит и жрёт минимум памяти. В отличие от Qt/.Net, которые полноценно вытягивают только довольно мощные машины.
MC>Допольно мощные это какие? PIII? (на PIII .NET уже без проблем работает) А ничего что они выпускались уже лет 10 назад? Или до 2028 года надо поддерживать 200-мегагерцовые процессоры?
Во-первых P3 для ГУЯ на до-диезе объективно мало Работать-то оно будет, но тормозная отрисовка ГУИ будет заметна на глаз. А насчёт того какие компы надо поддерживать ответ ровно один: чем меньше тебе надо ресурсов — тем лучше.
1) ты на компе будешь не один. Если твоей проге нужно, например, всего 30% ресурсов компа — то 4 таких проги уже "непоместятся".
2) Юзеры ведь не дураки. Если гуй тормозит, или прога жрёт много ресурсов юзер посмотрит на аналогичный софт. И уйдёт на более шустрый аналог.
Исключение — корпоративный софт, под который фактически и покупается компьютер. Там хоть 110% ресурсов сожри — на лаги с прорисовкой, например, всем плевать. Лишь бы работало. А если совсем худо будет — тупо докупят железа.
Здравствуйте, IID, Вы писали:
IID>Во-первых P3 для ГУЯ на до-диезе объективно мало Работать-то оно будет, но тормозная отрисовка ГУИ будет заметна на глаз. А насчёт того какие компы надо поддерживать ответ ровно один: чем меньше тебе надо ресурсов — тем лучше. IID>1) ты на компе будешь не один. Если твоей проге нужно, например, всего 30% ресурсов компа — то 4 таких проги уже "непоместятся". IID>2) Юзеры ведь не дураки. Если гуй тормозит, или прога жрёт много ресурсов юзер посмотрит на аналогичный софт. И уйдёт на более шустрый аналог.
IID>Исключение — корпоративный софт, под который фактически и покупается компьютер. Там хоть 110% ресурсов сожри — на лаги с прорисовкой, например, всем плевать. Лишь бы работало. А если совсем худо будет — тупо докупят железа.
А с чего вы все взяли что есть какое-то ограничение на хардварь? Или вы вообще о тенденции говорите? Так тенденция известно какая — тратить деньги, а иначе многим кушать будет нечего. Я так понял что к текущему моменту MFC устарела безнадежно (при всем при этом видел книжку Рихтера "Windows with C/C++", но там чистое API в привязке к градиозному COM-серверу — .NET), и изучать её не стоит абсолютно, ну или за ОЧЕНЬ дополнительные деньги, да и странно мне — если есть спецификации (а я предполагаю, что они есть), то используя принцип "черного ящика" весь функционал пишется с помощью желаемой технологии. Зачем тогда знать эту самую MFC? Чувстствую кто-то шибко умный настропалил HR-ов, а ни и рады стараться.
Здравствуйте, Handie, Вы писали:
H>CreateEvent(NULL, TRUE, TRUE, NULL);
H>В Qt это бы выглядело так:
H>QEvent event(QEvent::ManualReset, QtEvent::Signaled);
Не вижу принципиальной разницы, если честно. И в том, и в том случае надо запоминать параметры — там четыре, здесь два. Кстати, в MFC это будет
CEvent event(FALSE, FALSE); Сюрприз? :)
H>Код Qt читается изумительно прежде всего за счет объектности, перегрузки, неймспейсов, активного использования enum вместо BOOL/INT и т.д.
Это все к ООП не имеет отношения — чистый синтаксис, кроме объектности, которая есть и в MFC.
H>На Qt или .Net прога пишется в разы быстрее — не надо использовать уродский API с кучей параметров в простых вызовах и изобретать велосипед на маломальски "нестандартную" задачу (парсинг XML, чтение PNG, HTTP и другие стандартные ныне вещи).
Это тоже к ООП не имеет отношения. :) Но, несмотря на это, QT конечно лучше чем MFC, с этим не спорю
COF>Не вижу принципиальной разницы, если честно. И в том, и в том случае надо запоминать параметры — там четыре, здесь два. Кстати, в MFC это будет COF>CEvent event(FALSE, FALSE); Сюрприз?
В первом случае надо лезть в доку, второй понятен без этого. Еще пример:
widget->repaint(true);
widget->repaint(false);
Объясните разницу
COF>Это все к ООП не имеет отношения — чистый синтаксис, кроме объектности, которая есть и в MFC.
Нет, Qt был спроектирован для людей, MFC — для компьютеров:
We believe APIs should be minimal and complete, have clear and simple semantics, be intuitive, be easy to memorize, and lead to readable code.
Be minimal: A minimal API is one that has as few public members per class and as few classes as possible. This makes it easier to understand, remember, debug, and change the API.
Be complete: A complete API means the expected functionality should be there. This can conflict with keeping it minimal. Also, if a member function is in the wrong class, many potential users of the function won't find it.
Have clear and simple semantics: As with other design work, you should apply the principle of least surprise. Make common tasks easy. Rare tasks should be possible but not the focus. Solve the specific problem; don't make the solution overly general when this is not needed. (For example, QMimeSourceFactory in Qt 3 could have been called QImageLoader and have a different API.)
Be intuitive: As with anything else on a computer, an API should be intuitive. Different experience and background leads to different perceptions on what is intuitive and what isn't. An API is intuitive if a semi-experienced user gets away without reading the documentation, and if a programmer who doesn't know the API can understand code written using it.
Be easy to memorize: To make the API easy to remember, choose a consistent and precise naming convention. Use recognizable patterns and concepts, and avoid abbreviations.
Lead to readable code: Code is written once, but read (and debugged and changed) many times. Readable code may sometimes take longer to write, but saves time throughout the product's life cycle.
Почти все пункты нарушены в MFC
COF>Это тоже к ООП не имеет отношения. Но, несмотря на это, QT конечно лучше чем MFC, с этим не спорю
MFC (и Win32) ужасен, меня всегда тошнило когда я видел или писал программы на нем
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, TarasCo, Вы писали:
MC>>>Допольно мощные это какие? PIII? (на PIII .NET уже без проблем работает) А ничего что они выпускались уже лет 10 назад? Или до 2028 года надо поддерживать 200-мегагерцовые процессоры? TC>>К примеру Intel Atom он по мощности примерно как PIII получится. И памяти обычно рядом с ним вовсе не гигабайты. Для 2010 года — нормальная конфигурация
MC>Ну и абсолютно без проблем на нем будут .NET приложения работать. У нас в офисе раньше самые слабые компы были PIII-800 / 512Mb — все отлично шло.
Работать-то будут. Речь была про гладкость и плавность интерфейса.
, так вот, слышал мнение что использование MFC — процесс весьма нетривиальный. С другой стороны, заказчики финансово завлекаютЬ и предлагают даже дать время на ознакомление с библиотекой. По книжке для освоения у меня даже сомнений никаких — Круглински форевер. Хочется услышать мнение работавших с этой библиотекой, насколько оно сложно?
