Здравствуйте, aik, Вы писали:


aik>Это выбор между 2 сортами г-на — или в инструментах линукса, или в целевом коде. С инструментами как то ещё можно что то сделать, а со старым mfc кодом останется только люто бухать, по-моему. Странно что mfc вообще ещё жив, 18 лет назад он уже на ладан дышал.

а на чем бы вы стали писать небольшую утилиту под win

Здравствуйте, sergey2b, Вы писали:

aik>>Это выбор между 2 сортами г-на — или в инструментах линукса, или в целевом коде. С инструментами как то ещё можно что то сделать, а со старым mfc кодом останется только люто бухать, по-моему. Странно что mfc вообще ещё жив, 18 лет назад он уже на ладан дышал.
S>а на чем бы вы стали писать небольшую утилиту под win

Ээээм. Да на питоне поди и стал бы, а редактор — да хоть студия, или far, или vim, или всякие notepad+. Как то давно не надо было, у меня утилиты консольные и для линукса, я смысла в винде для себя не вижу.

Здравствуйте, kaa.python, Вы писали:

aik>>В последнее время — это как долго? А то вот меня тоже рвало назад сильно, а теперь лучше уж кобол, чем вся эта херня снова, но ломка заняла года два.
KP>Главное – осилить Vim и/или Emacs, дальше уже легче Хотя на той же Windows я после *NIX не могу без слез смотреть на управление библиотеками при разработке, хорошо хоть vcpkg появился, стало на . *NIX похоже, а то было ну совсем ппц.

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

Здравствуйте, aik, Вы писали:

aik>Да на питоне поди и стал бы, а редактор — да хоть студия, или far, или vim, или всякие notepad+

Ещё VS Code. Удобный, шустрый, бесплатный. Куча плагинов. После него студия болотом кажется.

Здравствуйте, nekocoder, Вы писали:

D>>Вспоминаю это старое говно как страшный сон.
N>На это у меня и расчет. Что все перейдут на современные фреймворки, и старые проекты поддерживать будет некому.
Так не бывает. Где сейчас разработчики FoxPro? Как только технологии устаревают и перестают справляться с задачами — почти сразу же исчезают.

КОБОЛ — это во многом исключение из-за того, что свои нехитрые задачи он выполняет до сих пор.

Про MFC такого сказать уже нельзя — у неё нет перспектив работы в браузере, она не работает на мобильных устройствах и даже сама по себе уже не развивается.

Здравствуйте, nekocoder, Вы писали:

N>Где-то полтора года, и еще в прошлом года 3. Ломка стала сильнее в последнее время, потому что я дома работаю над своими проектами в Visual Studio, и контраст с разработкой под Linux просто отбивает все желание притрагиваться к этому самому Linux'у.
Может стоит на инструменты более правильно посмотреть? Что именно используется для разработки?

Здравствуйте, aik, Вы писали:

aik>Меня больше вымораживает обилие черных ящиков без вменяемой диагностики ошибок (т.е. или документация, или ассемблер, но почти всегда ничего в промежутке) и администрирование всякого типа обновлений или той же виндовой сетки, которая "просто работает", но если вдруг что то всё таки не работает — задолбаешься рыться в политиках, потому что система через логи ничего вменяемого не расскажет.

ааа, вот оно как Ну я только пишу, не админю, поэтому подобное меня, по большому счету, обошло стороной. Если надо для тестов какую-то проксю поднять, то это более-менее просто.

Здравствуйте, Cyberax, Вы писали:

C>Может стоит на инструменты более правильно посмотреть? Что именно используется для разработки?
Сейчас Sublime Text и голый make. Я пытался настроить в нем отладку и прочее, но махнул рукой и использую просто как редактор в итоге. Из-за всяких ограничений что-то другое поставить нельзя. Понятно что есть еще vim/emacs, но у меня они ничего кроме раздражения не вызывают.

Проблема не только в конкретных инструментах, проблема в целом в линуксовом подходе к разработке. При разработке под Windows все крутится вокруг Platform SDK, MSVS и MSDN. Platform SDK из коробки позволяет разрабатывать что угодно — десктопные приложения, драйвера, игры, сервисы.

Под юниксом тебе приходится разбираться с зоопарком библиотек (несколько десятков — легко) разработаных непонятно кем и иногда плохо документированых. Система сборки проекта — отдельная боль, неважно make это или cmake. Нет нормального отладчика, только корявый и тормозной gdb. Все заточено под работу из командной строки, если в студии можно полазить по настройками и найти что тебе нужно, то в Линуксе это постоянное гугление и чтение документации. IDE вроде Qt Creator слегка помогают, но только слегка (хотя бы потому что используют тот же gdb).

Мне не нравится тратить время на борьбу с инструментами вместо работы.

Здравствуйте, Cyberax, Вы писали:

C>Так не бывает. Где сейчас разработчики FoxPro? Как только технологии устаревают и перестают справляться с задачами — почти сразу же исчезают.

В принципе MFC-то вполне справляется со своими задачами — нативной разработкой под Windows. Я давно не занимался разработкой GUI, но вроде бы Microsoft не выпускало новых GUI фреймворков (нативных).

Но у меня вопрос не только про MFC, а вообще про использование технологий Microsoft (не кросплатформенных) — Windows API, COM и тому подобные, есть ли смысл идти в этом направлении, или же их ждет судьба FoxPro?

Понятно что будущее предсказать сложно, но у меня была надежда, что кто-то кто занимается десктопной разработкой под Windows поделится опытом, как там оно — используются технологии MS или все переехали на QT, Electron и прочие кросплатформенные вещи.

Здравствуйте, nekocoder, Вы писали:

N>Понятно что будущее предсказать сложно, но у меня была надежда, что кто-то кто занимается десктопной разработкой под Windows поделится опытом, как там оно — используются технологии MS или все переехали на QT, Electron и прочие кросплатформенные вещи.

У нас куча кроссплатформенного десктопного ПО. Везде Qt, Electron, С++ и кое-где Go (да, его тоже на десктопе используем). MFC только в тестовом приложении есть

Здравствуйте, aik, Вы писали:

aik>Ээээм. Да на питоне поди и стал бы, а редактор — да хоть студия, или far, или vim, или всякие notepad+. Как то давно не надо было, у меня утилиты консольные и для линукса, я смысла в винде для себя не вижу.

Для дома она, к сожалению, до сих пор очень полезна. Либо Windows либо macOS, если делаешь что-то отличное от просмотра видео и серфинга в интернете. Банально фоточки обработать – уже хотелось бы иметь если не C1, то хотя бы LR

Здравствуйте, sergey2b, Вы писали:

S>а на чем бы вы стали писать небольшую утилиту под win

Да что угодно.

Если так уж хочется именно WinAPI-контролы (например, взбрело в голову property sheet shell extension писать, или сделать маленький бинарник без лишних зависимостей), то хотя бы WTL, а не MFC.
WTL более тонкая надстройка над WinAPI, чем MFC, соответственно, с ней меньше грабель.

А вообще, проще же накидать контролы на форму, как когда-то в делфи, билдере или вижуал бейсике.
Поэтому Qt или WinForms. Второй путь — с использованием C# и C++/CLI прослойки, поэтому более замороченный, чем первый.

У MFC по сравнению со многими другими UI библиотеками есть такое преимущество, как готовая Document-View инфраструктура, которая даже работает для MDI приложений.
Но тоже такое себе — оно работает как задумано, и только так, шаг влево-шаг вправо дорого обходится.

Здравствуйте, nekocoder, Вы писали:

C>>Может стоит на инструменты более правильно посмотреть? Что именно используется для разработки?
N>Сейчас Sublime Text и голый make. Я пытался настроить в нем отладку и прочее, но махнул рукой и использую просто как редактор в итоге. Из-за всяких ограничений что-то другое поставить нельзя.
Каких ограничений? Что мешает воткнуть VS Code или CLion и использовать намного более вменяемый CMake?

N>Под юниксом тебе приходится разбираться с зоопарком библиотек (несколько десятков — легко) разработаных непонятно кем и иногда плохо документированых. Система сборки проекта — отдельная боль, неважно make это или cmake. Нет нормального отладчика, только корявый и тормозной gdb.
Ну вот не надо про отладчик. GDB намного мощнее всего, что есть в Windows (один step backwards чего стоит).

Из того, чего в Линуксе нет — это edit&continue для С/С++ кода.

N>Все заточено под работу из командной строки, если в студии можно полазить по настройками и найти что тебе нужно, то в Линуксе это постоянное гугление и чтение документации. IDE вроде Qt Creator слегка помогают, но только слегка (хотя бы потому что используют тот же gdb).
Вот про свойства не надо, в настройках проекта ничего полезного в MSVS не было. Всё сводилось к указанию пары ключей.

N>Мне не нравится тратить время на борьбу с инструментами вместо работы.
Ну так стоит их изучить?

Здравствуйте, nekocoder, Вы писали:


N> Ломка стала сильнее в последнее время, потому что я дома работаю над своими проектами в Visual Studio,

А зачем свои проекты, стартапишь, или просто "для души" ?

В последнем случае советовал бы таки найти интересную предметную область, и работать в своё удовольствие.

Но "скучный энтрепрайз" в качестве выбора оной выглядит странно. И тогда таки стоит рассмотреть возможность смены языка.
Есть области, где С++ оправдан (AAA gamedev, automotive, IoT, blockchain, ...), ну а энтрепрайз продолжает идти в сторону managed языков и web.

Здравствуйте, nekocoder, Вы писали:

N>Понятно что будущее предсказать сложно, но у меня была надежда, что кто-то кто занимается десктопной разработкой под Windows поделится опытом, как там оно — используются технологии MS или все переехали на QT, Electron и прочие кросплатформенные вещи.

Мы до сих пор сидим на WTL. Мой предшественник за каким-то лешим выбрал именно её, вместо MFC, поэтому закатываем солнце вручную.
А там моё имхо: если надо только под Windows и не надо сложных resizeable диалогов, то MFC или WTL — очень даже живее всех живых.
Для растягивающихся панелек и всякого рода динамических окошек отлично встроился htmlayout.

Вот если нужно кроссплатформенное, то окромя Qt альтернативы не вижу. Разве что тот же htmlayout (ныне sciter).

Здравствуйте, nekocoder, Вы писали:

C>>Так не бывает. Где сейчас разработчики FoxPro? Как только технологии устаревают и перестают справляться с задачами — почти сразу же исчезают.
N>В принципе MFC-то вполне справляется со своими задачами — нативной разработкой под Windows. Я давно не занимался разработкой GUI, но вроде бы Microsoft не выпускало новых GUI фреймворков (нативных).
Не справляется. В MFC нет средств разработки форм с элементами управления, например. Самой основной вещи для UI.

(называть этим Dialog Editor язык не поворачивается)

N>Но у меня вопрос не только про MFC, а вообще про использование технологий Microsoft (не кросплатформенных) — Windows API, COM и тому подобные, есть ли смысл идти в этом направлении, или же их ждет судьба FoxPro?
Технологии Microsoft в целом будут жить ещё долго. Тот же DirectX никуда не денется, например.

Просто надо смотреть на то, что используется.

Здравствуйте, sergey2b, Вы писали:

S>а на чем бы вы стали писать небольшую утилиту под win
Да можно просто сразу на WinAPI, чтоб не заморачиваться с обёртками.

Здравствуйте, nekocoder, Вы писали:

N>я дома работаю над своими проектами в Visual Studio, и контраст с разработкой под Linux просто отбивает все желание притрагиваться к этому самому Linux'у.
У меня аналогично тока про XCode вместо линуха.

Здравствуйте, Cyberax, Вы писали:

C>Ну вот не надо про отладчик. GDB намного мощнее всего, что есть в Windows (один step backwards чего стоит).
Вот уж в чём надобности никогда не было так это в этом.
А вот в нормальном гуе с watch windows — постоянно, а то приходится постоянно тайпать войну и мир просто чтоб посмотреть на переменную.

C>Вот про свойства не надо, в настройках проекта ничего полезного в MSVS не было. Всё сводилось к указанию пары ключей.
Там по крайней было сразу видно какие у тебя варианты есть и что они означают.

Здравствуйте, kaa.python, Вы писали:

KP>Главное – осилить Vim и/или Emacs, дальше уже легче