Здравствуйте, Александр, Вы писали:
А>Коллеги, у кого уже встала проблема с MFC и отменой Windows? А>Есть ли какие то мысли, переписать весь MFC на STL?
Что ты имеешь в виду под "переписать MFC на STL" ? MFC — это достаточно тонкий слой над WinAPI, с адаптацией под C++. Там 90% работы делает GDI и остальные API. STL — это достаточно низкоуровневая кроссплатформенная библиотека для C++. Там нет ничего от WinAPI. Как можно одно переписать на другом . Если только реализовать свой, довольно увесистый, кусок OS.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, Александр, Вы писали:
А>>Коллеги, у кого уже встала проблема с MFC и отменой Windows? А>>Есть ли какие то мысли, переписать весь MFC на STL?
V>Что ты имеешь в виду под "переписать MFC на STL" ? MFC — это достаточно тонкий слой над WinAPI, с адаптацией под C++. Там 90% работы делает GDI и остальные API. STL — это достаточно низкоуровневая кроссплатформенная библиотека для C++. Там нет ничего от WinAPI. Как можно одно переписать на другом . Если только реализовать свой, довольно увесистый, кусок OS.
Да, не совсем точно выразил тему. MFC переписать на STL c GUI это совсем неподъёмная тема.
Вдобавок, GUI в STL совсем нету. Имелось ввиду, такие примитивы, как CArray, CString, СMap, COleVariant etc.
Здравствуйте, Александр, Вы писали:
А>Коллеги, у кого уже встала проблема с MFC и отменой Windows?
Пока отмены виндов не заметил, но и на MFC никогда не писал. Писал на WTL, если что-то чисто под винду, но всегда писал на плюсах и на стандартных классах, ну, плюс какие-то адаптеры делал для WTL. Идея использовать MFC/WTL/что-то ещё везде — мне и 25 лет назад казалась не самой хорошей.
А>Есть ли какие то мысли, переписать весь MFC на STL?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Александр, Вы писали:
А>>Коллеги, у кого уже встала проблема с MFC и отменой Windows?
M>Пока отмены виндов не заметил, но и на MFC никогда не писал. Писал на WTL, если что-то чисто под винду, но всегда писал на плюсах и на стандартных классах, ну, плюс какие-то адаптеры делал для WTL. Идея использовать MFC/WTL/что-то ещё везде — мне и 25 лет назад казалась не самой хорошей.
А>>Есть ли какие то мысли, переписать весь MFC на STL?
M>Нет конечно, кто оплатит?
Здравствуйте, Videoman, Вы писали:
V>Что ты имеешь в виду под "переписать MFC на STL" ? MFC — это достаточно тонкий слой над WinAPI, с адаптацией под C++. Там 90% работы делает GDI и остальные API. STL — это достаточно низкоуровневая кроссплатформенная библиотека для C++. Там нет ничего от WinAPI. Как можно одно переписать на другом . Если только реализовать свой, довольно увесистый, кусок OS.
MGC — это не довольно тонкий слой над WinAPI (на самом деле — очень таки жирный, вплоть до того, что там многое из WinAPI тупо сделано по-своему), но и всякие CString (полагаю, есть и CVector и пр), которые у некоторых производителей/разработчиков софта проросли повсюду, и на них всё заточено
Здравствуйте, Marty, Вы писали:
M>Это вполне можно, было бы желание и бабло на эту работу. За несколько лет и пару-тройку десятков лямов я бы сам бы взялся за эту работу
Здравствуйте, Александр, Вы писали:
А>Имелось ввиду, такие примитивы, как CArray, CString, СMap, COleVariant etc.
Строки и контейнеры в MFC — шаблонные классы.
Можно просто взять соответствующие заголовки и с ними компилировать зависимый код.
Зачем заменять реализацию этих контейнеров на реализацию через STL?
С вариантом посложнее будет, т.к. COleVariant — обертка над виндовым VARIANT и пачкой функций API.
Или я не правильно понял задачу?
Может, наоборот, существующий код хочется переписать на контейнеры и строки STL?
Тогда сложность зависит от объема и навороченности кода.
Например, у CString и std::basic_string весьма отличается интерфейс, как и у контейнеров.
Такая переделка может вылиться в полное переписывание кода.
Здравствуйте, Александр, Вы писали: А>Есть ли какие то мысли, переписать весь MFC на STL?
Разве MFC поставляется без исходников? Если без гуи, то вин-специфичного там будет совсем немного. Просто взять исходники, поправить специфичное, и ура.
Здравствуйте, Videoman, Вы писали:
V>MFC — это достаточно тонкий слой над WinAPI, с адаптацией под C++.
Нет. MFC это было много чего, в т.ч. каркас для создания document-based приложений. Автор имеет в виду, скорее всего, ещё одну часть MFC — шаблонные коллекции.
Здравствуйте, Shtole, Вы писали:
S>Нет. MFC это было много чего, в т.ч. каркас для создания document-based приложений. Автор имеет в виду, скорее всего, ещё одну часть MFC — шаблонные коллекции.
Что "Нет" !? Все относительно. Я в своё время лет 5 безвылазно сидел на MFC и его исходники знаю чуть ли не наизусть. Да, там много чего понакручено сверху, в том числе своя отрисовка некоторых элементов окна, свои нотификации, кастомные элементы, свои диалоговые процедуры, но это всё мелочь по сравнению объемом работы которое выполняет GDI и WinAPI. MFC без WinAPI просто ничего не может и не имеет смысла.
Здравствуйте, Videoman, Вы писали:
S>>Нет. MFC это было много чего, в т.ч. каркас для создания document-based приложений. Автор имеет в виду, скорее всего, ещё одну часть MFC — шаблонные коллекции.
V>Что "Нет" !? Все относительно. Я в своё время лет 5 безвылазно сидел на MFC и его исходники знаю чуть ли не наизусть. Да, там много чего понакручено сверху, в том числе своя отрисовка некоторых элементов окна, свои нотификации, кастомные элементы, свои диалоговые процедуры, но это всё мелочь по сравнению объемом работы которое выполняет GDI и WinAPI. MFC без WinAPI просто ничего не может и не имеет смысла.
Я же сказал, что именно «нет». Ещё раз повторить?
>MFC — это достаточно тонкий слой над WinAPI
Это неправда. MFC стостоял из нескольких достаточно независимых частей. Дальнейшее пишу по памяти, но на неё я никогда не жаловался.
1. C++'ные хелперы. Это, в первую очередь, CString и шаблонные коллекции: CArray, CList и CMap.
2. WinAPI-related классы. Обёртки (CWnd, наследники CWnd, CDC, всякие CBitmap и прочее), но не только обёртки. Там была, насколько помнится, даже такая штука, как RAII вокруг WinAPI-вызовов с часами-курсором.
3. Реализация Model-View-Controller, про которую я написал выше (она же Doc/View). Это CArchive, CDocument, CView и его наследники.
Между 2 и 3 был набор... как бы назвать... клеевых классов, которые, с одной стороны, опирались на WinAPI, с другой стороны не имели смысла без Doc/View.
Помимо этих трёх частей были ещё классы для работы с СУБД и классы для работы с COM, но первыми я никогда не пользовался, а вторые могу перепутать с ATL, поэтому о них промолчу.
Кстати, никогда не видел никого, кто хорошо бы разбирался в MFC. Ну, кроме программистов из CodeJock и из BCG, которую Microsoft потом купил. Чтобы сериализация была сделана, как авторами задумывалось, документы нормально прописаны, связи между моделью и представлениями настроены, и т.д. Каждый раз, как MFC-проект попадался, так половина костыли, а половина — велосипеды. Кое-кто так и по 10 лет писал, не то, что по пять.
Я же говорю, понятия толстый/тонкий здесь относительны. Для кого-то MFC это "толстый" слой. Для меня это тонкий слой абстракция, т.к. WinAPI он практически не скрывает и если его выдернуть из под MFC, то ни CDocument ни CView без него жить не смогут, т.к. внутри все Update-ы базируются на всё том же цикле сообщений и гоняют всё те же события. Для меня "толстый" слой, это QT, где весь механизм свой и он портируем на другие платформы.
Что из перечисленного может пригодится без WinAPI ? Ну разве что С++ обертки. И-то, они заточены на Windows. Вот где и зачем еще нужен метод строки?
BOOL LoadString(HINSTANCE hInstance, UINT nID, WORD wLanguageID);
Да нигде. Все эти обертки устаревший хлам, написанный на шаблонах С++, когда стандарт был еще в зачаточном состоянии, когда никто еще не понимал как этим правильно пользоваться, с классами унаследованными от CObject, густо обмазанный макросами, без поддержки перемещения, константных выражений и т.д. В общем, по современным меркам, полный легаси-говнокод.
Здравствуйте, Александр, Вы писали:
А>Коллеги, у кого уже встала проблема с MFC и отменой Windows? А>Есть ли какие то мысли, переписать весь MFC на STL?
Какая итоговая цель ?
Запустить в Linux/macOS? Тут возможен вариант с Wine.
Или просто убить время ?
. Если только реализовать свой, довольно увесистый, кусок OS.
