Думаю, WTL мог бы жить дольше, только если бы раскрутился раньше.
Когда пришло понимание того, как писать на С++, и в частности, как писать программы с UI на C++ c использованием WinAPI контролов, пришла и идея о том, что UI на C++ с использованием WinAPI контролов писать не надо.
Ну а у MFC осталось больше наследия, которое ещё и лучше защищено от портирования тем самым непониманием того, как надо было писать на С++.
Я даже сомневаюсь, что когда-то умрет. Слишком много приложений уже на нем написано, если завтра Microsoft объявит о прекращении поддержки MFC, завоют у них очень много клиентов, так как многие крупные клиенты Microsoft'а используют программы из 90хх годов, которые еще на древнейшем MFC написаны, а фирм, которые эти программы написали, уже не существует.
Здравствуйте, AlexGin, Вы писали:
AG>Полностью MFC естественно же, не умрёт AG>Просто станет чем-то вроде того же кобола, на котором ещё лет 10-12 назад что-то ваяли для старых систем.
Зря так думаешь.
MFC -- замечательная промышленная библиотека для разработки UI под Windows.
Собственно, другой -то и вообще нет. Нет альтернатив.
QT — да, примерно такого же масштаба, но она кроссплатформная и более тяжёлая. В смысле -- ЕЩЁ более тяжёлая.
Здравствуйте, AlexGin, Вы писали:
AG>Мы используем для C++ и MFC разработок MSVS 2015 — и она достаточно удобна (и я бы сказал — стабильна). AG>Посему, уважаемый aloch, насчёт новых глючных студий — возможно дело не в студиях, а в чем-то другом.
Дело — в студиях. В 2013 поломали CString::AllocSysString(). Для пустых строк оно... бросало исключение. Помимо кривых рук автора говорит о качестве тестирования.
Починили только в 2015 (джва года ждать!).
Разбираться, что там еще они поломают совсем не хочется.
Здравствуйте, Alexander G, Вы писали:
AG>Когда пришло понимание того, как писать на С++, и в частности, как писать программы с UI на C++ c использованием WinAPI контролов, пришла и идея о том, что UI на C++ с использованием WinAPI контролов писать не надо.
UI на C++ вообще писать не надо. Зачем все эти мучения для кнопок на экране? На языке, в котором нет событий и свойств у классов?
AG>Ну а у MFC осталось больше наследия, которое ещё и лучше защищено от портирования тем самым непониманием того, как надо было писать на С++.
А как надо было писать MFC на Microsoft C/C++ 7.0 (первый компилятор С++ от MS) в котором не было ни шаблонов, ни исключений? Что под Win31 работало на одном мегабайте памяти? и еще под DOS?
Здравствуйте, Alexander G, Вы писали:
AG>Думаю, WTL мог бы жить дольше, только если бы раскрутился раньше.
Времени на раскрутку у него было предостаточно. Вот только последняя версия практически не отличается от версии 2002 года.
WTL — это "закат солнца вручную", со всеми плюсами и минусами. Для небольших утилит очень удобно, а приложений покрупнее, скажем, с MDI и кучей панелей, с более изощренной обработкой команд всё придется колхозить вручную.
В то же время в MFC всё есть из коробки.
AG>Ну а у MFC осталось больше наследия, которое ещё и лучше защищено от портирования тем самым непониманием того, как надо было писать на С++.
Есть такое дело.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, aloch, Вы писали:
A>Здравствуйте, Alexander G, Вы писали:
AG>>После перехода на VS 2015, таки начали пугать прекращением поддержки не-юникодной MFC:
AG>>
AG>>MBCS support in MFC is deprecated and may be removed in a future version of MFC.
A>В 2013 MBCS выкинули и ее нужно было ставить отдельно. В 2015 — "все вернули взад", видимо крупные клиенты все им объяснили.
A>С другой стороны, у меня все, что C++, собирается VC++ 2012, и мне не совсем нужны все эти новые глючные студии, а тем более то, во что превратился C++. Все новое — C#.
Мы используем для C++ и MFC разработок MSVS 2015 — и она достаточно удобна (и я бы сказал — стабильна).
Посему, уважаемый aloch, насчёт новых глючных студий — возможно дело не в студиях, а в чем-то другом.
Здравствуйте, flаt, Вы писали:
AG>>Более умер, внезапно, WTL.
F>А жаль.
ИМХО, не с кем не спорю.
Была еще прекрасная библиотека OWL, но она умерла в середине 90-х еле-еле переползя с 16 бит на 32, Borland не стал двигать VCL и OWL одновременно. Мне на тот момент всё нравилось в Borland C (4-4.5), легкий и простой OWL, даже редактор со встроенным grep-ом и построенный на основе WordPerfect-а был на голову выше Visual Studio 4-5, а MFC и студия на тот момент мне показались убожеством.
А WTL не умер, просто в своем развитии в качестве легковесной обертки он достиг предела, свою дальнейшую жизнь он нашел в MFC(+ATL/WTL), что в общем не мешает использовать голый WTL без всякого MFC. Для небольших программ такое раньше катило, сейчас нет, MFC изрядно почистили и она уже не тянет за собой большого рантайма.
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, flаt, Вы писали:
F>>А жаль.
AG>Думаю, WTL мог бы жить дольше, только если бы раскрутился раньше.
WTL-ю не повезло выйти в примерно одно время с C#. Именно он не дал ему развиться.
Здравствуйте, aloch, Вы писали:
A>А как надо было писать MFC на Microsoft C/C++ 7.0 (первый компилятор С++ от MS) в котором не было ни шаблонов, ни исключений? Что под Win31 работало на одном мегабайте памяти? и еще под DOS?
Под пониманием я имею в виду и "понимание" со стороны компилятора тоже.
Вот что точно технически было возможно, но "мужики-то не знали" — отделение UI от логики и Unit-тесты.
Что касается "мегабайта под дос пешком", так в основном этот MFC код написан уже в конце девяностых — начале нулевых, когда железо позволяло, а не позволяла уже инертность мышления.
Здравствуйте, aloch, Вы писали:
A>А как надо было писать MFC на Microsoft C/C++ 7.0 (первый компилятор С++ от MS) в котором не было ни шаблонов, ни исключений? Что под Win31 работало на одном мегабайте памяти? и еще под DOS?
(мимоходом, для сравнения)
A>ни шаблонов, ни исключений
В Ada 83 были и шаблоны(дженерики, ок) и исключения. И работало оно на контроллерах, там памяти было меньше 1 МБ.
Здравствуйте, Alexander G, Вы писали:
AG>Что касается "мегабайта под дос пешком", так в основном этот MFC код написан уже в конце девяностых — начале нулевых, когда железо позволяло, а не позволяла уже инертность мышления.
MFC 1.0 — 1992 год. Начали в MS все это (компилятор C++, MFC и прочее), я думаю, года за два до релиза. Отнюдь не конец 90 начало нулевых
Здравствуйте, SkyKnight, Вы писали:
SK>Я даже сомневаюсь, что когда-то умрет. Слишком много приложений уже на нем написано, если завтра Microsoft объявит о прекращении поддержки MFC, завоют у них очень много клиентов, так как многие крупные клиенты Microsoft'а используют программы из 90хх годов, которые еще на древнейшем MFC написаны, а фирм, которые эти программы написали, уже не существует.
После перехода на VS 2015, таки начали пугать прекращением поддержки не-юникодной MFC:
MBCS support in MFC is deprecated and may be removed in a future version of MFC.
Здравствуйте, Alexander G, Вы писали:
AG>После перехода на VS 2015, таки начали пугать прекращением поддержки не-юникодной MFC:
AG>
AG>MBCS support in MFC is deprecated and may be removed in a future version of MFC.
В 2013 MBCS выкинули и ее нужно было ставить отдельно. В 2015 — "все вернули взад", видимо крупные клиенты все им объяснили.
С другой стороны, у меня все, что C++, собирается VC++ 2012, и мне не совсем нужны все эти новые глючные студии, а тем более то, во что превратился C++. Все новое — C#.
Здравствуйте, SkyKnight, Вы писали:
SK>Здравствуйте, VladFein, Вы писали:
SK>Я даже сомневаюсь, что когда-то умрет. Слишком много приложений уже на нем написано, если завтра Microsoft объявит о прекращении поддержки MFC, завоют у них очень много клиентов, так как многие крупные клиенты Microsoft'а используют программы из 90хх годов, которые еще на древнейшем MFC написаны, а фирм, которые эти программы написали, уже не существует.
+100500
Полностью MFC естественно же, не умрёт
Просто станет чем-то вроде того же кобола, на котором ещё лет 10-12 назад что-то ваяли для старых систем.
AG>Когда пришло понимание того, как писать на С++, и в частности, как писать программы с UI на C++ c использованием WinAPI контролов, пришла и идея о том, что UI на C++ с использованием WinAPI контролов писать не надо. AG>Ну а у MFC осталось больше наследия, которое ещё и лучше защищено от портирования тем самым непониманием того, как надо было писать на С++.
Наверное, ты знаешь какую-то СТРАШНУЮ ТАЙНУ!!!
АААА!!
Здравствуйте, MasterZiv, Вы писали:
MZ>Здравствуйте, AlexGin, Вы писали:
AG>>Полностью MFC естественно же, не умрёт AG>>Просто станет чем-то вроде того же кобола, на котором ещё лет 10-12 назад что-то ваяли для старых систем.
MZ>Зря так думаешь. MZ>MFC -- замечательная промышленная библиотека для разработки UI под Windows.
+100500
С этим я не спорю, MFC — замечательная вешь для Windows GUI.
Но и она, естественно, не без недостатков.
MZ>Собственно, другой -то и вообще нет. Нет альтернатив.
Вот тут не совсем так:
С 2002-го альтернатива от той же самой компании: .NET (C#; WinForms).
Также на сегодняшний день в стеке .NET технологий есть ещё и WPF.
В Java — альтернативы не вижу (уж очень "топорный" в этом случае GUI для Windows приложений).
Насчёт Qt — главное (IMHO): она намного более дружественна и удобна для программиста.
Также Qt обеспечивает куда более понятные и компактные (не обременённые лишними техническими сущностями) исходники на C++, нежели MFC.
Это я прочуствовал сам, т.к. более 10 лет занимался разработкой на MFC и чуть более года — открыл для себя мир Qt
Те факты, что Qt кроссплатфоменна и в ней более богатый набор GUI компонентов, нежели в MFC, я оставил за собками.
MZ>QT — да, примерно такого же масштаба, но она кроссплатформная и более тяжёлая. В смысле -- ЕЩЁ более тяжёлая.
Учитывая тот прогресс по hardware, который имеется у нас сегодня, я бы не называл словом "тяжёлые" даже .NET и Java —
c присущим им автоматическим GC; с тяжеловесними POD типами; с большими библиотеками фреймворков.
Что же касается MFC и Qt (которых объединяет базовый C++), то это вообще легковесные технологии,
позволяюшие разрабатывать сложные математические алгоритмы, работающие в real-time.
З.Ы. Кстати, при разработке для Windows мне в Qt доступны все те же WinAPI функции, что и при разработке в MFC.
Здравствуйте, AlexGin, Вы писали:
AG>Но и она, естественно, не без недостатков.
Ну, ничего промышленного без недостатков вообще не.
MZ>>Собственно, другой -то и вообще нет. Нет альтернатив. AG>Вот тут не совсем так: AG>С 2002-го альтернатива от той же самой компании: .NET (C#; WinForms). AG>Также на сегодняшний день в стеке .NET технологий есть ещё и WPF.
.NET тут не конкурент, это -- отдельная тема, никак не связанная с программированием на C++.
AG>Насчёт Qt — главное (IMHO): она намного более дружественна и удобна для программиста. AG>Также Qt обеспечивает куда более понятные и компактные (не обременённые лишними техническими сущностями) исходники на C++, нежели MFC. AG>Это я прочуствовал сам, т.к. более 10 лет занимался разработкой на MFC и чуть более года — открыл для себя мир Qt
Да как поглядеть. Например, MVC на MFC, наверное, попроще выглядит.
Потом, QT -- это сигналы и слоты, которые нестандартные, и их надо изучить.
Другое дело, что QT имеет большие возможности и плюс ещё переносимость, так что я бы для проектов с 0-ля выбирал его.
MZ>>QT — да, примерно такого же масштаба, но она кроссплатформная и более тяжёлая. В смысле -- ЕЩЁ более тяжёлая. AG>
Что тут вызывает вопросы ? У тебя есть сомненния, что QT тяжелее MFC ? Она по фичам тупо больше, например,
поддерживает multimedia и базы данных (в MFC БД -- три класса, и то малоюзабельные).
На счёт "легковестности" этих технологий ты неправ.
Здравствуйте, MasterZiv, Вы писали:
MZ>Что тут вызывает вопросы ? У тебя есть сомненния, что QT тяжелее MFC ?
Нет сомнений — Qt бесспорно тяжелее, чем MFC.
Только эта тяжесть может быть заметна в относительно редких случаях.
MZ>Она по фичам тупо больше, например, MZ>поддерживает multimedia и базы данных (в MFC БД -- три класса, и то малоюзабельные).
Да, в MFC поддержка БД считай что — совсем никакая
Для моих проектов на MFC, для работы с ODBC я использовал OTL: http://otl.sourceforge.net/home.htm
В Qt поддержка БД хорошая, хотя иногда (на выборке больших объемов данных) — OTL отрабатывает побыстрее.
MZ>На счёт "легковестности" этих технологий ты неправ.
А в чём же я здесь неправ?
Все технологии, базируемые на C++, на сегодня можно считать вполне легкими.
На дворе уже 2017, а ты именуешь "тяжеловесными" технологии, которые пойдут на среднем компе 10-15 летней давности.
Здравствуйте, AlexGin, Вы писали:
MZ>>На счёт "легковестности" этих технологий ты неправ. AG>А в чём же я здесь неправ? AG>Все технологии, базируемые на C++, на сегодня можно считать вполне легкими. AG>На дворе уже 2017, а ты именуешь "тяжеловесными" технологии, которые пойдут на среднем компе 10-15 летней давности.
Вот в этом ты и неправ.
Легковестность оценивают по сложности программирования, а не запуска.