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

N>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM, MFC, ATL и прочих стать чем-то вроде Кобола в будушем?

Видел одного персонажа, который на МФЦ писал программы для одной дотационной организации из сферы ВПК. Так вот на что он потратил 10 лет на то, что делается на Делфи 1 год. Когда ему попытался это объяснить, у него началась истерика. Оно и понятно, пристроился он хорошо, кодит потихоньку, зарплата устраивает, тепло, сухо, нет ему замены (и соблазна мало платить поэтому). В планах у него и он их начал осуществлять — писать без МФЦ, на своих классах через Win API, мол, больше гибкости. Видимо, решил там навечно закрепиться.

Вопрос филосовский. С одной стороны очень мало сделал. С другой стороны поставил себя как незаменимый и вытребовал нормальное рабочее место, соотвественно программы качественные у него, международный уровень. А делай он на чём-нибудь более простом в плане разработки, уж давно бы нашли ему замену в виде студента, способного скомпилировать приложение, не зависающее на запуске. А потом на его месте будет другой студент и так далее. Работодатель же не соображает, что программа если запустилась — это не значит, что она работает.

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

C>>Каких ограничений? Что мешает воткнуть VS Code или CLion и использовать намного более вменяемый CMake?
N>Это же не домашний проект, это работа, тут нельзя просто взять и переделать. Проект был начат в те времена, когда CMake под стол ходил. Поставить другой софт нельзя из-за режима безопасности.
Ну так надо, значит, из такого маразма просто уходить.

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

C>>Ну так стоит их изучить?
N>А мне не нравится их изучать. Мне нравится когда все из коробки удобно работает.
Ну так и взять тогда стоит коробку — CMake+CLion. Там всё ОК.

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

S>меня от перезда в китай в свое время остановило, что на работе все сидят рядом с друг другом на растоянии вытянутой руки

Я пока тоже не готов морально ехать в Китай, разве что в Шанхай, но туда не зовут

S>и в хорошую больницу надо занимать очередь с вечера и после открытия дверей бежать в регистратуру на перегонки

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

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

N>>Это же не домашний проект, это работа, тут нельзя просто взять и переделать. Проект был начат в те времена, когда CMake под стол ходил. Поставить другой софт нельзя из-за режима безопасности.
C>Ну так надо, значит, из такого маразма просто уходить.
Моя работа это лучшее из всех доступных мне вариантов. Есть много хороших вещей которые я не променяю на расширенную техническую свободу.

C>GDB умеет это всё. Скорее всего, у вас там что-то ещё кривое.
При попытке посмотреть контейнер он тупо вываливает внутренние поля класса вместо элементов. У нас относительно старый gdb, может в новых версиях пофиксили. Но студия-то нормально их показывает уже лет 15 как.

C>Ну так и взять тогда стоит коробку — CMake+CLion. Там всё ОК.
CMake и "все ок" в одном предложении не сочетаются. Достаточно взять любой мало-мальски крупный проект на гитхабе и заглянуть в его CMake файлы. По сути, это еще один язык программирования который придется изучить.

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

C>>Ну так надо, значит, из такого маразма просто уходить.
N>Моя работа это лучшее из всех доступных мне вариантов. Есть много хороших вещей которые я не променяю на расширенную техническую свободу.
Ну так значит, что нравится сидеть в болоте.

C>>GDB умеет это всё. Скорее всего, у вас там что-то ещё кривое.
N>При попытке посмотреть контейнер он тупо вываливает внутренние поля класса вместо элементов. У нас относительно старый gdb, может в новых версиях пофиксили. Но студия-то нормально их показывает уже лет 15 как.
https://stackoverflow.com/questions/11606048/how-to-pretty-print-stl-containers-in-gdb

C>>Ну так и взять тогда стоит коробку — CMake+CLion. Там всё ОК.
N>CMake и "все ок" в одном предложении не сочетаются. Достаточно взять любой мало-мальски крупный проект на гитхабе и заглянуть в его CMake файлы.
Тем не менее, это сейчас практически стандарт.

N>По сути, это еще один язык программирования который придется изучить.
И что? Если использовать CMake как простой MSVS-проект, то там будет десяток директив нужно знать.

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

C>Ну так значит, что нравится сидеть в болоте.

N>>При попытке посмотреть контейнер он тупо вываливает внутренние поля класса вместо элементов. У нас относительно старый gdb, может в новых версиях пофиксили. Но студия-то нормально их показывает уже лет 15 как.
C>https://stackoverflow.com/questions/11606048/how-to-pretty-print-stl-containers-in-gdb
Спасибо. Отличный пример убогости линуксовых инструментов.

C>Тем не менее, это сейчас практически стандарт.
С этим я не спорю. Я ищу способ работать в стороне от этих стандартов.

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

N>>>При попытке посмотреть контейнер он тупо вываливает внутренние поля класса вместо элементов. У нас относительно старый gdb, может в новых версиях пофиксили. Но студия-то нормально их показывает уже лет 15 как.
C>>https://stackoverflow.com/questions/11606048/how-to-pretty-print-stl-containers-in-gdb
N>Спасибо. Отличный пример убогости линуксовых инструментов.
Что там убогого? Обычные скрипты для рендеринга. Причём доступные и для своих коллекций (у меня, например, для моего интрузивного списка есть).

C>>Тем не менее, это сейчас практически стандарт.
N>С этим я не спорю. Я ищу способ работать в стороне от этих стандартов.
Закуклиться и игнорировать мир?

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

C>Что там убогого? Обычные скрипты для рендеринга. Причём доступные и для своих коллекций (у меня, например, для моего интрузивного списка есть).
Тут мы наверное друг друга не поймем. Для меня после MSVS это дикость, что приходится разбираться и писать скрипты для элементарных вещей.

N>>С этим я не спорю. Я ищу способ работать в стороне от этих стандартов.
C>Закуклиться и игнорировать мир?
Вроде того.

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

N>>Спасибо. Отличный пример убогости линуксовых инструментов.
C>Что там убогого? Обычные скрипты для рендеринга. Причём доступные и для своих коллекций (у меня, например, для моего интрузивного списка есть).

Ну они по уму сразу с gdb должны идти или ставиться из apt/dnf/yum. Как и плагины к виму. Если ты всю жизнь получал софт из коробки, и набора тебе хватало (странновато, но предположим что хватало) — то в линуксе начинается ломка. Вопрос вкусов, помню это ощущение. Да и сейчас я плагины для vim беру где попало, что не так чтоб комильфо.

У меня .vimrc 182 строки — 2 функции по 30 строк, остальное — настройки, это вот насколько оно "готово" к использованию из коробки. Но я и студию после установки ещё по полчаса настраивал под себя — убирал хреновы тулбары, табы и прочий ненужный графический мусор, менял шорткаты, настройки. Тыктыктык мышой полчаса. Меня vim штырит уже только потому, что "rsync -r .vim* there:~/" делает это всё для vim за пару секунд.

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

C>Что там убогого? Обычные скрипты для рендеринга. Причём доступные и для своих коллекций (у меня, например, для моего интрузивного списка есть).
А ты когда нить пробовал ими смотреть на большие коллекции?

C>Закуклиться и игнорировать мир?
Это вы господа окуклились и не желаете видеть то, что доступно уже 10+ лет как.
Смотришь как большинство заядлых *никсоидов работают — это просто какой то каменный век: кремниевые топоры и палки-копалки, связанные лианами.
Очень напоминает мультик про Флинтстоунов:

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

aik>Меня vim штырит уже только потому, что "rsync -r .vim* there:~/" делает это всё для vim за пару секунд.

Студийный конфиг ж тоже можно было экспортировать и импортировать обратно. У меня дома он просто в репе лежит сразу.

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

N>- Разрабатывая под Windows у тебя всегда есть Visual Studio, нет нужды мучаться с отдельными текстовыми редакторами и костылями, системами сборки, gdb, и прочими "радостями" разработки под Linux.

Но вопрос ведь так не стоит. Если тебе надо приложение под Linux, то MFC и ATL тебе ну вообще никак не помогут. С другой стороны, никто не мешает тебе разрабатываться и отлаживаться в среде Windows с VS на C++ 11+ стандартов (где есть смарт-пойтеры, обёртки и прочие радости), примешав boost где это надо, а потом всё это легко портировать на Linux. Главное — не писать в непортабельном стиле if (error == 10061).

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

C>>Что там убогого? Обычные скрипты для рендеринга. Причём доступные и для своих коллекций (у меня, например, для моего интрузивного списка есть).
N>Тут мы наверное друг друга не поймем. Для меня после MSVS это дикость, что приходится разбираться и писать скрипты для элементарных вещей.
Их не надо писать, они уже есть в поставке. Разобраться придётся один раз.

N>>>С этим я не спорю. Я ищу способ работать в стороне от этих стандартов.
C>>Закуклиться и игнорировать мир?
N>Вроде того.
Можно. Но конец будет печальный.

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

сколько лет пишу и для linux, и для woe — но я не окошечник, поэтому позицию выражу так — библиотеки это крайне слабый аргумент на вкусную зарплату, вот совсем никак, они меняются как перчатки. Там где старый код, сколько видел нигде не используется mfc и прочие обертки, делают свою или напрямую пишут на winapi, тот же MS судя по исходникам даже во время популярности mfc его не использовал, у них свой framework для офиса к примеру, системные утили и окошковые приложения написаны только пользуясь winapi.

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

Вывод: я бы даже гроша ломаного на mfc не поставил

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

_>Я не против .NET Core. Только вот как будут менеджеры думать:
_>- Искать отдельно разработчиков backend на C# & ASP.NET Core и разработчиков frontend на js фреймворке?
_>- Искать Fullstack (C# ASP.NET Core + js фреймворк)?
_>- Запускать проект на node.js + клиентский js фреймворк?

_>Есть подозрение, что первый пункт уже отпадает по-тихоньку... всем нужен "универсальный солдат" и по фиг, что он и бэкенд сжелает фиговый и frontend — так себе.

На больших проектах объемы такие, что к фронту и беку еще отдельно идут разработчики бд, дизайнеры и т.д. Можно все повесить на универсалов (fullstack), но качество хромает.
В болото где все делает один чел лучше просто не соваться.
И я уже видел проект переписанный с node.js на dotnet core по причине нехватки производительности и сложности поддержки.

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

BE>На больших проектах объемы такие, что к фронту и беку еще отдельно идут разработчики бд, дизайнеры и т.д. Можно все повесить на универсалов (fullstack), но качество хромает.
BE>В болото где все делает один чел лучше просто не соваться.
BE>И я уже видел проект переписанный с node.js на dotnet core по причине нехватки производительности и сложности поддержки.
Может случайно есть вести с полей, каков итог перехода на dotnet core ?

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

_NN>Может случайно есть вести с полей, каков итог перехода на dotnet core ?
Нормально, работает.

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

CC>Да можно просто сразу на WinAPI, чтоб не заморачиваться с обёртками.

не, WTL заметно упрощает жизнь по сравнению с голым WINAPI.

Последний годится только для совсем уж маленьких поделок. Задолбает слать руками эти все сообщения, разбирать и собирать lParam, wParam и следить за ресурсами

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

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

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

WPF.

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

D>Пример с потолка, если ты изучишь процесс написания ПО для ЧПУ станков, то у тебя будет огроменный бонус перед обычными программистами на с++. И если вдруг кому то нужно будет написать такое ПО, то тебя найдут даже из другого города, главное дать такую возможность потенциальному клиенту.

Я могу привести пример не с потолка, а из моего собственного трудового опыта:
Так, с Марта 2011 по Октябрь 2015 — я занимался разработками SCADA системы на C++ (MFC).
Когда в компании по разработке стало совсем трудно (экономически) — я пошёл искать новую работу.
На те вакансии, где требовался разработчик SCADA — меня даже не приглашали на собеседование

Пригласили — на разработку игр (в gamedev), хотя я этим никогда и не занимался.
К слову — так себе местечко было, в 2016 нашёл что-то поприличнее.

Вот тогда-то я и занялся изучением Qt.
Только после этого и почувствовал востребованность

P.S. Вот Вы, уважаемый Denwer, здесь пишете про станки с ЧПУ.

А вдруг выясняется, что разработчик на C++ — там нафиг никому не нужен (нужно совсем другое):
https://jobs.tut.by/resume/3a7442af00032d4db40039ed1f56567a43374d?query=%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%81%D1%82+%D1%87%D0%BF%D1%83

Вот выдержка из резюме опытного разработчика программ для станков с ЧПУ:

Освоил CAD,CAM Cimatron, SolidWorks, SolidCAM: проектирование и разработка программ.

Я совсем не собираюсь уменьшать профессионализм этого разработчика, просто специфики разработки на C++ здесь нет.

P.P.S. Здесь та же ситуация, как и для разработчика SCADA систем — нужен просто грамотный "конфингуровщик" имеющегося софта.
Для данной работы знаний C/C++ и Software-development — совсем не нужно.
Нужно — владение производственными понятиями (чего у среднего C/C++ разработчика — нет).
Нужно — знание специальных программных средств, нацеленных на данную специфическую нишу.
Hint:
Разработка системы на C/C++ займёт месяцы, возможно годы.
При использовании специализированного софта, создание (читай — конфигурирование) нового продукта займёт максимум неделю/две...