Re[7]: Перспектива старых технологий (MFC, COM, ...) десктоп - О работе

По сути я думаю следующее: если есть знание C++, его надо просто поддерживать в актуальном состоянии добавив понимание алгоритмов. По мне так C++ в связке с *NIX (т.е. *NIX-инструментарий и базовые концепты *NIX) должно за глаза хватить до пенсии, а если еще добавить некое понимание сетей, так вообще, жить можно очень хорошо.

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

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

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

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

Вспоминаю это старое говно как страшный сон. Переходи на Qt. Тут и работы больше и от нее блевать не хочется. И если вдруг у тебя будет момент, когда твой заказчик просто скажет — мне нужная такая вот аппликуха, а ты сам выбери на чем писать. То выбирая Qt тебе не придется рассказывать заказчику что каждое новое сложное окно в MFC пишется по 2 дня, а то и больше.

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

KP>По сути я думаю следующее: если есть знание C++, его надо просто поддерживать в актуальном состоянии добавив понимание алгоритмов. По мне так C++ в связке с *NIX (т.е. *NIX-инструментарий и базовые концепты *NIX) должно за глаза хватить до пенсии, а если еще добавить некое понимание сетей, так вообще, жить можно очень хорошо.

Я в последнее время пишу под Linux, и мне это сильно не нравится. Хочу обратно в Windows с Visual Studio.

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

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

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

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

COM так точно живее всех живых.

Например DirectX и относительно новые Direct2D/DirectWrite это всё COM based скажем так.
Да, там нет всего что известно как ActiveX, но IUnknown и IUnknown::QueryInterface никуда не делся и активно используется.
Ибо альтернативы этому в общем-то и нет.

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

N>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM, MFC, ATL и прочих стать чем-то вроде Кобола в будушем? В теории, даже несмотря на старость технологий, на них существует множество проектов которые нужно поддерживать. Да и новые десктопные приложения под Windows создаются.

N>Я подумываю о том, чтобы специализироваться в этом направлении.

Работаю на проекте, где означенные технологии используются.
Причём, проект активно развивается, больше фич девелопмента, чем багфикса.
С MFC в теории хотелось бы съехать, но надо пилить новые фичи, и фиксить баги, на смену шила на мыло бюджета нет (и, скорее всего, не скоро будет).
С СОМ ещё сложнее, по крайней мере, с той частью, которую заэкспозили для кастомеров.

Но! Нет ничего невозможного, когда-нибудь переедем на Qt, когда будет совсем острая бизнес-необходимость.
Поэтому, лучше закопаться в прикладную предметную область, такое будет кормить дольше, а к технологиям относиться утилитарно.

Здравствуйте, 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>Мне не нравится тратить время на борьбу с инструментами вместо работы.
Ну так стоит их изучить?

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

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

Мы до сих пор сидим на WTL. Мой предшественник за каким-то лешим выбрал именно её, вместо MFC, поэтому закатываем солнце вручную.

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

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

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

N>Минусы:
N>- В общем-то минус один: шанс что ниша схлопнется и я останусь без работы.

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

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

aik>В последнее время — это как долго? А то вот меня тоже рвало назад сильно, а теперь лучше уж кобол, чем вся эта херня снова, но ломка заняла года два.

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

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

N>Я в последнее время пишу под Linux, и мне это сильно не нравится. Хочу обратно в Windows с Visual Studio.

Очень рекомендую глянуть на CLion, лично на мой вкус после этого MSVS выглядит довольно бледно. Если, конечно, проблема только в среде разработки.

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

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

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

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

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

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

N>Минусы:
N>- В общем-то минус один: шанс что ниша схлопнется и я останусь без работы.

Тут вопрос в другом: а сколько будет жить сама ОС Windows и MS? У тебя как бы посыл в том, что Windows будет жить вечно, как и сама MS... Однако это может быть не так.

Я бы опаслася складывать все яйки в одну корзинку, особенно проприетарную...

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

CC>>Вот уж в чём надобности никогда не было так это в этом.
C>Значит не отлаживал сложные алгоритмы (остановить на ASSERT, а потом прокрутить назад — супер).
Наоборот, только очень простые вещи могут позволить откат назад.
Как оно прокрутит назад вызов функции которая анмапит память например? Отобрать страницу у системы которая уже скорее всего стёрта и принадлежит другому процессу?
Или асинхронщину? Или IO?

CC>>А вот в нормальном гуе с watch windows — постоянно, а то приходится постоянно тайпать войну и мир просто чтоб посмотреть на переменную.
C>Я использую CLion для установки точек останова и ком. строку для остального.
Очевидно ты не понял про что я.
Как в gdb всегда видеть нужные мне локальные переменные с их значениями на каждом шаге? С подсветкой какие из них поменялись за этот шаг?
В gdb чтоб пройти по указателям внутрь объекта попутно глядя не только на следующий поинтер но и на другие поля приходится тайпать много команд и засирать вывод простынями текста. После нормальных отладчиков это реально раздражает.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

aik>Это потому, что vim/emacs на всю голову контуженые. Очень мощные и настолько же контуженые

Мне доводилось наблюдать за тем, как работают опытные пользователи vim и emacs. Печатают десятью пальцами, стук стоит, на экране что-то мелькает, а работа-то движется медленно. Потому что задачи, которые занимают большинство времени, это не "удалить 10е слово во второй строке сверху", а что-то более визуальное. Перетащить эту строку вон туда, закоментировать этот кусок кода, тот кусок перетащить в другой файл (который надо открыть), скопировать длинное имя переменной и воткнуть его вон в то выражение. Все это в нормальных редакторах делается быстрее. Даже не вспоминаю об отсутствующих функциях IDE.

aik>Корявого я ещё могу простить, но тормозной gdb?! Запускается же микросекунду, и ещё пару миллисекунд грузит дебагсимволы, и работает быстро.
При переходе вверх по стеку или разворачивании объектов у меня он подвисал секунд на 30 (а иногда и насовсем).

aik>Точнее, оно заточено под скрипты, ну и интерфейс командной строки сильно упрощает написание оболочек типа cgdb. Можно запустить gdb со скриптом, он сам будет останавливаться где надо, печатать бэктрейсы, переменные, потоки, чертей лысых и продолжать, если надо. Перед прогой добавляешь "gdb -ex myscript --args" и понеслась.
Для меня звучит как дикость. Проще принтфами отлаживать. Я не против скриптов, чтобы пользоваться ими для каких-то особо сложных задач. Но когда приходится писать их для обычных повседневных операций, то нет, спасибо, не подходит.

aik>У меня память дырявая, так что я читаю доку, пишу скриптик или правлю конфиг, кладу в свой гит и в комментариях оставляю по-больше "тагов", чтоб потом найти, а вот постоянно гуглить как то не возникает нужды.
У меня тоже дырявая. Но работе в MSVS это никак не мешает, там по крайней мере все базовые вещи, которыми пользуешься каждый день, находятся элементарно.

Здравствуйте, 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>Закуклиться и игнорировать мир?
Вроде того.

Раньше я думал что "Программист на <языкнейм>" это дно, но в него снизу стучится "Программист на <библиотеканейм>"

Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM, MFC, ATL и прочих стать чем-то вроде Кобола в будушем? В теории, даже несмотря на старость технологий, на них существует множество проектов которые нужно поддерживать. Да и новые десктопные приложения под Windows создаются.

Я подумываю о том, чтобы специализироваться в этом направлении.

Плюсы:
— Все эти вещи уже старые и зрелые, каких-то радикальных изменений в этой области уже не будет. Освоив COM, MFC и Windows API, можно пользоваться ими до конца жизни.
— Разрабатывая под Windows у тебя всегда есть Visual Studio, нет нужды мучаться с отдельными текстовыми редакторами и костылями, системами сборки, gdb, и прочими "радостями" разработки под Linux.
— Нет необходимости изучать и поддерживать зоопарк библиотек. Ты ставишь SDK, и все.

Минусы:
— В общем-то минус один: шанс что ниша схлопнется и я останусь без работы.

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

N>Я в последнее время пишу под Linux, и мне это сильно не нравится. Хочу обратно в Windows с Visual Studio.

В последнее время — это как долго? А то вот меня тоже рвало назад сильно, а теперь лучше уж кобол, чем вся эта херня снова, но ломка заняла года два.

Хотя на той же Windows я после *NIX не могу без слез смотреть на управление библиотеками при разработке, хорошо хоть vcpkg появился, стало на . *NIX похоже, а то было ну совсем ппц.

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

N>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM
А что не так с COM? Разве её чем-то заменили на винде? Вроде как он был так и остался.

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

KP>ааа, вот оно как

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

"оно как" что? вот мне свезло работать с драйвером nvidia/cuda под линукс — обфусцированный бинарь и приехали — если он упал, то стек из символов _nv123456xx, а если не упал — то какой ioctl вернул что то не то, но либа (тоже бинарь) не скажет что именно то не так, любись как знаешь. я каждый день вспоминаю винду и как то вот да пошла эта студия к чертям, если сырцов ни к чему интересному не достать, и ведь интерес у меня даже не стырить суперноухау, а тупо отладить.

админство я имел ввиду то, что вот у жены комп с виндой, а у меня 2 виртуалки с 7 и 10, и куча линукс машин, и самба пахала везде, кроме физической виндовз машины, где я админ и где система ни за что не скажет что не так, а только permission denied и пустота в логах. четыреста советов из Гугла, но вредную политику я в итоге откопал сам.

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

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

BE>>Я 10 лет проработал на делфи. Последние годы ездил по стране гоняясь за условно высокими зарплатами. Сейчас перешел на шарп и весьма этим доволен, т. к. не я бегаю за работой, а работа за мной. И в деньгах при переходе не сильно потерял.

_>Кхм... помнится лет 13 тому назад как раз были заявления от дельфистов, что дельфи — форева!
_>Сейчас похожие возгласы раздаются из стана .NET: .NET — форева! Но .NET уже попахивает так же как и Delphi в 2005.
_>Я бы на твоем месте подтянул знания по ява скрипт (какому-нибудь UI фреймворку), node.js, GO, что бы снова не ездить 10 лет за условно высокими зп в .NET

.Net Framework свое отжил. DotNet Core развивается и весьма не плохо. Так что .net еще поживет. А вот Java ИМХО стагнирует. За Golang нужно следить и какую-то мелочь для себя на нем делать. За ним будущее. Насколько успешное сказать сложно.

Съехали с MFC, ATL и почти съехали с COM.
Оставили гибрид С++ и UI на шарпе.
Так что идейка так себе

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

D>>ЗЫ: Если хочешь стать востребованным и незаменимым, изучи предметную область, а не язык программирования или бибилиотеку.
AG>

AG>А вот здесь — не соглашусь!
AG>Если ты разработчик широкого профиля, при этом уже не совсем молод (за 45...50) — то при переходе в новую
AG>предметную область — ты будешь просто распылять силы — гоняться за двумя зайцами

AG>Экспертом в новой предметной области — скроее всего уже не станешь, а вот шанс вложиться на изучение того же Qt — упустишь

Само по себе знание языка программирования (с++) или какой либо бибилиотеки (Qt) не дает быть востребованным. А вот если знаешь какую то предметную область, кроме как самого программирования — вот тут у тебя большие плюсы. Само программирование в вакууме не существует, всегда приходиться разбиратсья с предметной областью. Пример с потолка, если ты изучишь процесс написания ПО для ЧПУ станков, то у тебя будет огроменный бонус перед обычными программистами на с++. И если вдруг кому то нужно будет написать такое ПО, то тебя найдут даже из другого города, главное дать такую возможность потенциальному клиенту.

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

KP>Вся работа уезжает в Азию, так как будущее именно тут, в Азии. Белые проиграли

В разработке обычного ПО в основном Азия приезжает к работе

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

aik>>Это потому, что vim/emacs на всю голову контуженые. Очень мощные и настолько же контуженые

N>Мне доводилось наблюдать за тем, как работают опытные пользователи vim и emacs. Печатают десятью пальцами, стук стоит, на экране что-то мелькает, а работа-то движется медленно. Потому что задачи, которые занимают большинство времени, это не "удалить 10е слово во второй строке сверху", а что-то более визуальное. Перетащить эту строку вон туда, закоментировать этот кусок кода, тот кусок перетащить в другой файл (который надо открыть), скопировать длинное имя переменной и воткнуть его вон в то выражение. Все это в нормальных редакторах делается быстрее. Даже не вспоминаю об отсутствующих функциях IDE.

Да не, это как раз vim/emacs делают не хуже, просто совсем (совсем) по-другому. Из отсутствующих средств IDE — это что оно не умеет ходить по реально скомпиленым символам, типа pdb. Т.е. даже есть какие то зачатки, но у меня не завелось, а cscope — он терпим, но он работает со статичным кодом, а не с бинарями.

aik>>Корявого я ещё могу простить, но тормозной gdb?! Запускается же микросекунду, и ещё пару миллисекунд грузит дебагсимволы, и работает быстро.
N>При переходе вверх по стеку или разворачивании объектов у меня он подвисал секунд на 30 (а иногда и насовсем).

Хм. Я удивлен. Ну окей.

aik>>Точнее, оно заточено под скрипты, ну и интерфейс командной строки сильно упрощает написание оболочек типа cgdb. Можно запустить gdb со скриптом, он сам будет останавливаться где надо, печатать бэктрейсы, переменные, потоки, чертей лысых и продолжать, если надо. Перед прогой добавляешь "gdb -ex myscript --args" и понеслась.
N>Для меня звучит как дикость. Проще принтфами отлаживать. Я не против скриптов, чтобы пользоваться ими для каких-то особо сложных задач. Но когда приходится писать их для обычных повседневных операций, то нет, спасибо, не подходит.

Да не, ты не понял. Он сделан таким, чтоб кому надо — мог сверху навернуть вундерфафлю с блэкджеком. Когда мне становилось тоскливо от интерфейса — я брал няшный консольный cgdb фронтэнд. А мог бы и другой взять, гуёвый, просто когда у тебя отлаживаемая машина в другом полушарии — с гуями как то не очень. Повседневный скрипт — это что то типа:

b exit
b hw_error
b raise
b abort
b __assert_fail
b unassigned_mem_read
b unassigned_mem_write
b unassigned_mem_accepts
b ohci_die
commands 1 2 3 4 5 6 7 8 9
    bt
end

т.е. пачка предустановленных бряков, которые я кидаю на отлаживаемые машины. Простой скрипт, простой gdb, очень удобно.

aik>>У меня память дырявая, так что я читаю доку, пишу скриптик или правлю конфиг, кладу в свой гит и в комментариях оставляю по-больше "тагов", чтоб потом найти, а вот постоянно гуглить как то не возникает нужды.
N>У меня тоже дырявая. Но работе в MSVS это никак не мешает, там по крайней мере все базовые вещи, которыми пользуешься каждый день, находятся элементарно.

Ежедневные вещи для всего находятся за минуту. Но скриптами и конфигами можно довольно просто поменять дефолтное поведение раз и навсегда, и потом копировать его на другие машины очень легко. Со студией каждый релиз — новый формат xml. И количество кликов мышью в виндософте меня невероятно злит, причём, цинизм ситуации в том, что это как раз в винде то на всё есть клавиатурный шорткат, а в линуксе простейшая хрень типа выделить произвольный кусок текста в консоли — требует мыши, но шорткаты в винде сделаны настолько трёхэтажными на "отвяжись", что ими мало кто пользуется, а линуксовые долбанутые, но — короткие.

Правда, есть шанс что если б я имел дело с десктопным софтом — я бы пел другую песню.

Здравствуйте, 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-проект, то там будет десяток директив нужно знать.

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

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

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

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

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

BI>С другой стороны поставил себя как незаменимый и вытребовал нормальное рабочее место,
BI>соотвественно программы качественные у него, международный уровень.
Мне кажется, второе из первого не следует.

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

_>И тут бац... какая-нибудь новомодная ОСь от гугла для компов и ноутов в том числе, вначале хомячки переходят, а потом и корпорации. И это может случиться и ранее 10-15 лет

без софта корпорации не перейдут. все эти siemens nxы, разного рода sapы и прочие ансисы — такое на новомодную ось если и перейдет, то в течении очень длительного срока и без всяких бац.

AG>Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми

Если взять какую-нибудь зрелую разработку на тему создания типовых окон, например редактор метаданных + конструктор форм в 1с (абстрагируемся от неудачных сторон, вроде птичьего языка "для неграмотных") — что в ней за 30 лет оказалось зыблемым? Совершенствуется, обеспечивая преемственность старых наработок. А не как у микрософта, каждые несколько лет новая банда перегораживает доступ к кормушке, выгоняет предыдущую группу, и выкидывайте все свои вложения в старую технологию — начинайте с 0 изучать новую, и переписывайте все свои наработки под неё.
O>>Вне зависимости, какая технология взята за основу. И заказы будут перетекать к той группе "разработчиков на МФЦ", у которой наработанные надстройки мощнее, и точнее подходят под задачи, и как следствие Окна делаются быстрее.
AG>Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC.
Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?

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

Z>>Так ведь не важно что она технически совершеннее (что кстати не факт,
S>Факт. Вы же сами говорите что в CMake нет таких банальных вещей как кроссплатформенная поддержка PCH.
Фактически, это единственное в CMake, чего нет из коробки (руками PCH делается без проблем).

S>Qbs уже давно вышел из бета стадии. Если интересно, то по приведенным выше ссылкам есть описания промышленного использования qbs (команды 40+ разработчиков).
S>Самое главное, что он точно может собирать саму Qt.
Можно крупные проекты на QBS? Уровня Calligra и Krita.

Z>>Ведь новую систему нужно протестировать в куче мест, написать ее поддержку для IDE,
S>QtCreator поддерживает qbs уже давно. Причем эта поддержака по определению лучше чем CMake, т.к. CMake всего лишь генератор.
Не лучше. CLion не поддерживает QBS вообще, например. XCode тоже.

Тогда как CMake прекрасно генерирует для них проекты.

Z>>написать документацию
S>Есть. Не идеальная, но явно лучше чем у CMake, т.к. многие вещи куда очевиднее.
Так как подключить Boost и OpenCL?

Z>>и вот тогда встает вопрос а нужно ли более совершенная система или лучше старую улучшить?
S>Вопрос не корректный. Система нужна и она уже есть. Вопрос только стоит ли на нее переходить или нет. Универсального ответа на этот вопрос конечно же нет.
Я пока что не вижу никаких причин использовать сырую местечковую QBS.

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

AG>Даже не спорю я, что группа опытных дядек с MFC окажется намного круче — как в плане теоретической подготовки, так и в плане практики.
Не окажется. Так как на MFC сидят только самые упоротые, которые пишут код от забора до обеда.

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

V_>Только нужна ли с этим работа? Или все автоматом генерируется, ибо генерилку уже написал человек, знакомый с COM

Интеропы генерятся автоматом — человек не нужен, знакомство с COM тоже.

N>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM, MFC, ATL и прочих стать чем-то вроде Кобола в будушем? В теории, даже несмотря на старость технологий, на них существует множество проектов которые нужно поддерживать. Да и новые десктопные приложения под Windows создаются.
Варианты развития событий, при которых придётся досуха выжимать остатки жизни из всей старой рухляди какая найдётся, — ведут в раздел "политика".

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

N>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM, MFC, ATL и прочих стать чем-то вроде Кобола в будушем? В теории, даже несмотря на старость технологий, на них существует множество проектов которые нужно поддерживать. Да и новые десктопные приложения под Windows создаются.

N>Я подумываю о том, чтобы специализироваться в этом направлении.

N>Минусы:
N>- В общем-то минус один: шанс что ниша схлопнется и я останусь без работы.

Непонятно, насколько аналогия с коболом верна. Возможно, кобол востребован постольку, поскольку его целевая аудитория специфична.
Довод спорный, но covariate shift тут возможен.

КОличество программистов на коболе тоже величина неизвестная . ВОзможно, их вообще было не слишком много, а сейчас людей, которые знают и мфц и COM на несколько порядков
больше, чем изначально кобол-программеров. В этом случае даже через 30 лет цена на них не будет слишком уж высока.

Технологии, который ты посчитал раритетными — для мфц это так, но тот же COM и сейчас популярен, на нем ты свою ценность поднять не сможешь.

Самое главное, рынок — для столько специфичной ниши тебе надо быть там, где она наиболее широка — т.е. в США. Любая другая страна будет иметь в десятки и сотни раз меньше вакансий.

P.S.
А еще есть ИИ, который в перспективе перепишет программу с языка/технологии X на язык Y.

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

AG>Поэтому, лучше закопаться в прикладную предметную область, такое будет кормить дольше, а к технологиям относиться утилитарно.

Так получилось, что я большую часть карьеры был так называемым generalist developer (разработчиком общего назначения), и вероятно им же останусь. По моему опыту, поверхностное знание какой-то предметной области преимуществ не дает, поскольку справедливо считается, что любой разработчик может быстро освоить на поверхностном уровне что угодно. Стать же экспертом в какой-то области дело непростое.

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

D>Вспоминаю это старое говно как страшный сон. Переходи на Qt.

Сейчас я как раз пишу под Linux, хотя и без Qt, всякие невизуальные вещи. Хотелось бы вернуться в Windows разработку. Как ни странно, мне технологии Microsoft нравятся больше, чем Qt и прочие современные фреймворки (хотя я и могу понять, почему другие их не любят). Возможно потому что именно с них я начинал, синдром утенка и все такое.

D>И если вдруг у тебя будет момент, когда твой заказчик просто скажет — мне нужная такая вот аппликуха, а ты сам выбери на чем писать. То выбирая Qt тебе не придется рассказывать заказчику что каждое новое сложное окно в MFC пишется по 2 дня, а то и больше.
Я больше смотрю в сторону неспешного энтерпрайза, где сложное окно будет писаться много месяцев.

N>и прочие современные фреймворки
N>Я больше смотрю в сторону неспешного энтерпрайза, где сложное окно будет писаться много месяцев.
Даже если только автоматизировать в общем виде свои повторяющиеся задачи, за несколько лет "фреймворк" сам собой образуется. Вне зависимости, какая технология взята за основу. И заказы будут перетекать к той группе "разработчиков на МФЦ", у которой наработанные надстройки мощнее, и точнее подходят под задачи, и как следствие Окна делаются быстрее.

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

D>Вспоминаю это старое говно как страшный сон.
+
На это у меня и расчет. Что все перейдут на современные фреймворки, и старые проекты поддерживать будет некому.

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

D>>И если вдруг у тебя будет момент, когда твой заказчик просто скажет — мне нужная такая вот аппликуха, а ты сам выбери на чем писать. То выбирая Qt тебе не придется рассказывать заказчику что каждое новое сложное окно в MFC пишется по 2 дня, а то и больше.
N>Я больше смотрю в сторону неспешного энтерпрайза, где сложное окно будет писаться много месяцев.

Осталось теперь клиентом убедить, что нужно проект писать на MFC, где окна пишутся в десятки раз дольше чем на Qt. И что через 5 лет ему программистов найти будет очень сложно из за их вымирания.

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

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

D>>Вспоминаю это старое говно как страшный сон.
N>+
N>На это у меня и расчет. Что все перейдут на современные фреймворки, и старые проекты поддерживать будет некому.

А почему не ориентироваться на новые проекты? Писать новый проект с чистого листа всегда приятнее. Плюс переход на Qt не привяжет к винде, хоть линукс, хоть мак ось. Тем самым сильно расширяешь потенциальных заказчиков.

ЗЫ: Если хочешь стать востребованным и незаменимым, изучи предметную область, а не язык программирования или бибилиотеку.

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

D>А почему не ориентироваться на новые проекты? Писать новый проект с чистого листа всегда приятнее.
Цель — найти стабильную нишу, чтобы спокойно доработать до пенсии. Для интереса у меня есть домашние проекты, от работы этого не требуется.

D>Плюс переход на Qt не привяжет к винде, хоть линукс, хоть мак ось.
Да, Qt это очевидный и вероятно беспроигрышный вариант. Но я сейчас изучаю немейнстримовые варианты, вдруг удастся найти что-то более подходящее для моих целей.

D>>Вспоминаю это старое говно как страшный сон.
N>+
N>На это у меня и расчет. Что все перейдут на современные фреймворки, и старые проекты поддерживать будет некому.

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

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

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

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

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

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

Хотя на той же Windows я после *NIX не могу без слез смотреть на управление библиотеками при разработке, хорошо хоть vcpkg появился, стало на . *NIX похоже, а то было ну совсем ппц.

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

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

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

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

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

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

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

ааа, вот оно как

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

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

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

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

C>>Ну вот не надо про отладчик. GDB намного мощнее всего, что есть в Windows (один step backwards чего стоит).
CC>Вот уж в чём надобности никогда не было так это в этом.
Значит не отлаживал сложные алгоритмы (остановить на ASSERT, а потом прокрутить назад — супер).

CC>А вот в нормальном гуе с watch windows — постоянно, а то приходится постоянно тайпать войну и мир просто чтоб посмотреть на переменную.
Я использую CLion для установки точек останова и ком. строку для остального.

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

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

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

N>>Как вы думаете, есть ли шанс у старых виндоусных технологий/фреймворков вроде COM
K>А что не так с COM? Разве её чем-то заменили на винде? Вроде как он был так и остался.

Не только остался, но и по сути-то предложить нечего им — идея-то неплохая

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

N>Я подумываю о том, чтобы специализироваться в этом направлении.

У нас до сих пор куча софта написанного поддерживается, никаких MFC/COM/ATL... только простынки кода на WinAPI. Да, жесть, но нужно страдать! И в каждый новый проект тащится тонны этого старого кала, потому как никакие сторонние библиотеки использовать нельзя. Как говорит мой начальник: ты должен испытывать боль и страдания!

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

RW>Не только остался, но и по сути-то предложить нечего им — идея-то неплохая
Тогда почему его называют легаси? Он же актуален будет ещё долго совместно с АТЛ, хотя ниша будет довольно узкая.

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

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

RW>>Не только остался, но и по сути-то предложить нечего им — идея-то неплохая
K>Тогда почему его называют легаси? Он же актуален будет ещё долго совместно с АТЛ, хотя ниша будет довольно узкая.

ATL это просто обертка, COM они никак не могут выкинут ибо вся операционка им пронизана — от шелла до офиса, а там ребята не то что консерваторы, а "работает — не трогай" что и правильно, поэтому и смешна эта шелуха и истерики вокруг шарпов и прочего, нормальному программисту набить руку в новом языке нет сложности.

N>- В общем-то минус один: шанс что ниша схлопнется и я останусь без работы.

вот этого я боюсь(возраст) и поэтому бегаю между технологиями

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

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

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

для win api контролов много и все же не один диалог а как миниму три

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

BE>Я 10 лет проработал на делфи. Последние годы ездил по стране гоняясь за условно высокими зарплатами. Сейчас перешел на шарп и весьма этим доволен, т. к. не я бегаю за работой, а работа за мной. И в деньгах при переходе не сильно потерял.

Кхм... помнится лет 13 тому назад как раз были заявления от дельфистов, что дельфи — форева!
Сейчас похожие возгласы раздаются из стана .NET: .NET — форева! Но .NET уже попахивает так же как и Delphi в 2005.
Я бы на твоем месте подтянул знания по ява скрипт (какому-нибудь UI фреймворку), node.js, GO, что бы снова не ездить 10 лет за условно высокими зп в .NET ;)

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

D>А почему не ориентироваться на новые проекты? Писать новый проект с чистого листа всегда приятнее. Плюс переход на Qt не привяжет к винде, хоть линукс, хоть мак ось. Тем самым сильно расширяешь потенциальных заказчиков.
+100500
Я и сам перешел на Qt с MFC почти три года назад

Теперь же возню с MFC вспоминаю — разве что в ужасных снах!

D>ЗЫ: Если хочешь стать востребованным и незаменимым, изучи предметную область, а не язык программирования или бибилиотеку.

А вот здесь — не соглашусь!
Если ты разработчик широкого профиля, при этом уже не совсем молод (за 45...50) — то при переходе в новую
предметную область — ты будешь просто распылять силы — гоняться за двумя зайцами

Экспертом в новой предметной области — скроее всего уже не станешь, а вот шанс вложиться на изучение того же Qt — упустишь

P.S. Важно понимать, что Новые Технологии — тебе Друзья (а не Враги). Тем более такие технологии — которые лежат близко к тебе.
Всё-таки Qt лежит достаточно близко к настольной разработке, с которой ты уже знаком по работе с MFC

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

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

Ну-ну...
На монстроидальном железе, поддерживать которое — сложно и дорого.
Нужно целую электростанцию, чтобы запитать комп на КОБОЛ-е

Не говоря уже о том, сколько площади занимает этот комп...

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

При чем здесь работа в броузере?
Сейчас и настольные приложения развиваются: Qt; Electron и т.д.

Да, MFC был популярен лет 15...20 назад.
Но по уровню вхождения — он был сложнее, нежели Delphi и билдер (популярные в то время).

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

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

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

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

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

C>>Ну вот не надо про отладчик. GDB намного мощнее всего, что есть в Windows (один step backwards чего стоит).
_NN>Уже завезли, и даже заявляют, что C++ поддерживают.
Близко, но не совсем. Step back отматывает исполнение назад, можно поменять значение переменной и продолжить исполнение.

Ещё рулит https://rr-project.org/ , но мне его использовать обычно просто нет смысла в моих проектах.

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

S>для win api контролов много и все же не один диалог а как миниму три
Чот у меня парсер ошибку выдал на этой фразе.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

KP> Банально фоточки обработать – уже хотелось бы иметь если не C1, то хотя бы LR

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

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

BE>.Net Framework свое отжил. DotNet Core развивается и весьма не плохо. Так что .net еще поживет. А вот Java ИМХО стагнирует. За Golang нужно следить и какую-то мелочь для себя на нем делать. За ним будущее. Насколько успешное сказать сложно.

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

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

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

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

C>>>Ну вот не надо про отладчик. GDB намного мощнее всего, что есть в Windows (один step backwards чего стоит).
_NN>>Уже завезли, и даже заявляют, что C++ поддерживают.
C>Близко, но не совсем. Step back отматывает исполнение назад, можно поменять значение переменной и продолжить исполнение.
Так ?

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

C>>Значит не отлаживал сложные алгоритмы (остановить на ASSERT, а потом прокрутить назад — супер).
CC>Наоборот, только очень простые вещи могут позволить откат назад.
CC>Как оно прокрутит назад вызов функции которая анмапит память например?
Сохраняет копию перед unmap'ом.

CC>Или асинхронщину? Или IO?
IO — никак.

CC>Как в gdb всегда видеть нужные мне локальные переменные с их значениями на каждом шаге? С подсветкой какие из них поменялись за этот шаг?
display?

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

CC>>Как оно прокрутит назад вызов функции которая анмапит память например?
C>Сохраняет копию перед unmap'ом.
Копию чего? Состояния всей системы?
Потому что если сохранить только блок памяти и поинтер а потом прикинуться что он мапнут то повторный анмап приведёт к ошибке и привет.

CC>>Или асинхронщину? Или IO?
C>IO — никак.
Асинхронные операции тоже никак, потому что это надо иметь опять таки снапшот всего на очень fine grain временном разрешении.

CC>>Как в gdb всегда видеть нужные мне локальные переменные с их значениями на каждом шаге? С подсветкой какие из них поменялись за этот шаг?
C>display?
Это совсем не то, более того совсем неудобно.
Пример понагляднее: вот смотрю я в корку, ничего есессно не шагаю — там всё уже упало, надо постмортем делать.
Лажу по фреймам, потокам, смотрю на всякие состояния в куче потоков и стеков.
Как мне сделать чтоб было так же удобно как и в вижле? Типа такого (первый попавшийся пример из гугла):

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

N>Понятно что есть еще vim/emacs, но у меня они ничего кроме раздражения не вызывают.

Это потому, что vim/emacs на всю голову контуженые. Очень мощные и настолько же контуженые

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

Корявого я ещё могу простить, но тормозной gdb?! Запускается же микросекунду, и ещё пару миллисекунд грузит дебагсимволы, и работает быстро.

N> Все заточено под работу из командной строки, если в студии можно полазить по настройками и найти что тебе нужно,

Точнее, оно заточено под скрипты, ну и интерфейс командной строки сильно упрощает написание оболочек типа cgdb. Можно запустить gdb со скриптом, он сам будет останавливаться где надо, печатать бэктрейсы, переменные, потоки, чертей лысых и продолжать, если надо. Перед прогой добавляешь "gdb -ex myscript --args" и понеслась.

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

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

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

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

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

C>Ну так стоит их изучить?
А мне не нравится их изучать. Мне нравится когда все из коробки удобно работает.

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

AG>А зачем свои проекты, стартапишь, или просто "для души" ?
Больше для души. Может через много лет они дойдут до стадии что их можно будет показывать другим людям.

AG>В последнем случае советовал бы таки найти интересную предметную область, и работать в своё удовольствие.
AG>Но "скучный энтрепрайз" в качестве выбора оной выглядит странно. И тогда таки стоит рассмотреть возможность смены языка.
Тут возникает конфликт "зарплата против интересности". Чтобы заниматься интересной работой за хорошие деньги, надо быть умным и энергичным. Если же ты не очень умный и энергичный (вроде меня), то приходится выбирать: или интересная работа за копейки, или рутина за приличные деньги.

AG>Есть области, где С++ оправдан (AAA gamedev, automotive, IoT, blockchain, ...), ну а энтрепрайз продолжает идти в сторону managed языков и web.
Да, это верно. Работы в энтерпрайзе под дотнет хватает. Мне было интересно разведать не совсем мейнстримовый вариант: Windows + некросплатформенный С++.

Как мне кажется, в ближайшем будущем Windows ничего не угрожает. Какую-то часть рынка вероятно отъедят планшеты на iOS/Android, но небольшую.

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

BE>Хреновая это идея.
BE>Я 10 лет проработал на делфи. Последние годы ездил по стране гоняясь за условно высокими зарплатами. Сейчас перешел на шарп и весьма этим доволен, т. к. не я бегаю за работой, а работа за мной. И в деньгах при переходе не сильно потерял.
BE>Случись, например, замена x86 на ARM и где будет MFC c ATL?
BE>А так как C++ жив и еще жить будет долго, то потратить вечерами пол-года на изучение Qt и можно пилить нормальный современный десктоп.
Спасибо. Видимо таки придется изучать QT (я его не люблю за кодогенерацию).

BE>Иди уйти в embedded.
C embedded по отзывам в США плохо, платят мало, и работа уезжает в Китай.

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

BE>>Иди уйти в embedded.
N>C embedded по отзывам в США плохо, платят мало, и работа уезжает в Китай.

Вся работа уезжает в Азию, так как будущее именно тут, в Азии. Белые проиграли

	Давайте возьмем машинное обучение, главную звезду и его команду, к примеру

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

KP>>Вся работа уезжает в Азию, так как будущее именно тут, в Азии. Белые проиграли

N>В разработке обычного ПО в основном Азия приезжает к работе

Такое ощущение может складываться когда живешь за пределами Азии. По факту тут народ часто не хочет куда-то ехать, так как на месте (в том же Китае) перспективы лучше. Ну а так как в одном Китае сильно за миллиард, то даже если небольшой процент решит ехать, то ощущение "Азия едет к нам" конечно же будет.

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

N>>В разработке обычного ПО в основном Азия приезжает к работе

KP>Такое ощущение может складываться когда живешь за пределами Азии. По факту тут народ часто не хочет куда-то ехать, так как на месте (в том же Китае) перспективы лучше. Ну а так как в одном Китае сильно за миллиард, то даже если небольшой процент решит ехать, то ощущение "Азия едет к нам" конечно же будет.

Не едут они по простой причине: центр софтостроения в США, а США может выдать только 85к рабочих виз в год (и все эти 85к отрывают с руками). Если брать лидеров индустрии (всякие Гуглы и Майкрософты), то азиатов в этих компаниях большинство, и домой уезжают единицы.

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

N>Не едут они по простой причине: центр софтостроения в США, а США может выдать только 85к рабочих виз в год (и все эти 85к отрывают с руками). Если брать лидеров индустрии (всякие Гуглы и Майкрософты), то азиатов в этих компаниях большинство, и домой уезжают единицы.

Ладно-ладно, ты прав. Центр разработки ПО есть, был и будет США и весь Китай туда хочет. Полагаю, железячники так же думали когда-то

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

KP>Ладно-ладно, ты прав. Центр разработки ПО есть, был и будет США и весь Китай туда хочет. Полагаю, железячники так же думали когда-то

мы вчера были на конкурсе русской музыки в NY
80% конкурсантов китайцы, 20 остальные корейцы, японцы и немного белых включая exUSSR

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

зоые языки говорят что когда мао дзедун понял что сша и ussr обогнали китай по вооружению,
сказал что — мы пойдем другим путем и приказал гражданам быть патриотами и делать больше детей

Здравствуйте, 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 файлы. По сути, это еще один язык программирования который придется изучить.

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

Здравствуйте, 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 ?
Нормально, работает.

Здравствуйте, 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++ займёт месяцы, возможно годы.
При использовании специализированного софта, создание (читай — конфигурирование) нового продукта займёт максимум неделю/две...

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

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

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

Так даже в ddd (самый древний GUI для gdb) это было,
а в Qt Creator и CLion подавно есть.
И в принципе в самом gdb это возможно сделать в простейшем случае,
допустим каждый раз когда срабатывает breakpoint вы хотите посмотреть переменные:

while 1==1
p a
p b
continue
end

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

То есть хочется увидеть настройки проекта какие возможности конфигурации доступны?
Для проектов основанных на CMake для этого в большинстве IDE есть отдельный диалог,
обычно в виде таблице, где написано название опциии, зачем она нужна и ее значение,
типа такого:

https://www.johnlamp.net/screenshots/cmt-3/advanced.png

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

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

aik>>Это потому, что vim/emacs на всю голову контуженые. Очень мощные и настолько же контуженые

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

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

aik>>>Это потому, что vim/emacs на всю голову контуженые. Очень мощные и настолько же контуженые

N>>Мне доводилось наблюдать за тем, как работают опытные пользователи vim и emacs. Печатают десятью пальцами, стук стоит, на экране что-то мелькает, а работа-то движется медленно. Потому что задачи, которые занимают большинство времени, это не "удалить 10е слово во второй строке сверху", а что-то более визуальное. Перетащить эту строку вон туда, закоментировать этот кусок кода, тот кусок перетащить в другой файл (который надо открыть), скопировать длинное имя переменной и воткнуть его вон в то выражение. Все это в нормальных редакторах делается быстрее. Даже не вспоминаю об отсутствующих функциях IDE.

aik>Да не, это как раз vim/emacs делают не хуже, просто совсем (совсем) по-другому. Из отсутствующих средств IDE — это что оно не умеет ходить по реально скомпиленым символам, типа pdb. Т.е. даже есть какие то зачатки, но у меня не завелось, а cscope — он терпим, но он работает со статичным кодом, а не с бинарями.

Э... 21 век, есть же youcompleteme, rtags, clangd,
emacs и vim давно умеют по lsp протоколу работать.
Есть там и дополнение по полностью корректной модели построенной с помощью clang,
и правильный переход по символу под курсором и рефакторинг типа переименования класса,
переменной функции.

Какой cscope, еще ctags вспомните.

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

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

aik>>>Корявого я ещё могу простить, но тормозной gdb?! Запускается же микросекунду, и ещё пару миллисекунд грузит дебагсимволы, и работает быстро.
N>>При переходе вверх по стеку или разворачивании объектов у меня он подвисал секунд на 30 (а иногда и насовсем).

aik>Хм. Я удивлен. Ну окей.

У gdb недавно был баг (ну относительно давно, полгода, может год) в результате у них сложность
работы с символами стала квадратичной, и у меня например coredump программы использующей Qt открывался
несколько минут (в основном конечно из-за отладочной информации самого Qt),
возможно если nekocoder использовал gdb с таким багом плюс ленивую загрузку символов (lazy loading) то можно увидеть
такое поведение, но в текущей версии они конечно это поправили.

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

BE>>И я уже видел проект переписанный с node.js на dotnet core по причине нехватки производительности и сложности поддержки.
_NN>Может случайно есть вести с полей, каков итог перехода на dotnet core ?
Живёт вполне себе, кстати. Знаю несколько проектов, которые переехали с .NET на .NET Core для деплоймента на Линуксе.

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

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

C>>Закуклиться и игнорировать мир?
CC>Это вы господа окуклились и не желаете видеть то, что доступно уже 10+ лет как.
Не, я сам использую CLion и графический отладчик в нём. Но и текстовый gdb вполне себе неплох, я его чаще всего через SSH использую.

CC>Смотришь как большинство заядлых *никсоидов работают — это просто какой то каменный век: кремниевые топоры и палки-копалки, связанные лианами.
Которые невозбранно раздавливают всё впереди себя, разрывая в клочья копролиты типа MSVS.

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

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

N>>>С этим я не спорю. Я ищу способ работать в стороне от этих стандартов.
C>>Закуклиться и игнорировать мир?
N>Вроде того.
Ну тогда надо уходить в Java и Enterprise. Там код ещё лет 20 будет работать без существенных изменений.

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

CC>>Смотришь как большинство заядлых *никсоидов работают — это просто какой то каменный век: кремниевые топоры и палки-копалки, связанные лианами.
C>Которые невозбранно раздавливают всё впереди себя, разрывая в клочья копролиты типа MSVS.

Пока ни одного такого не видел. Покуда я на MSVC + rsync + build over ssh подобных затаптывал только в путь.

... << RSDN@Home 1.0.0 alpha 5 rev. 0>>

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

Z>Э... 21 век, есть же youcompleteme, rtags, clangd,
Z>emacs и vim давно умеют по lsp протоколу работать.

Конечно умеют, о чём речь. Но вот только у меня vim и dnf не устанавливает ни одного плагина для этих чудных тулзей (хз что там с емаксом, но похоже что тоже установка через "git clone"). Отдельно тулза (везуха если через dnf/apt), отдельно плагин, и потом чуть повоевать с шорткатами, ну и разобраться — у каждой же вундервафли совершенно свой подход ко всему. Слишком много выбора, но ни одного чтоб работал из коробки. То ли дело студия — 1 редактор, 1 дебагер, ходит по символам сразу, 95% народу счастливы сразу и даже не подумают что то добавлять, а в линуксе нельзя на дефолтной хрени сидеть комфортно.

Раз ты в теме — какой из этих хреней можно подсунуть vmlinux + модули с дебажной инфой, чтоб vim/emacs стал по символам ходить?

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

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

Z>>Э... 21 век, есть же youcompleteme, rtags, clangd,
Z>>emacs и vim давно умеют по lsp протоколу работать.

aik>Конечно умеют, о чём речь. Но вот только у меня vim и dnf не устанавливает ни одного плагина для этих чудных тулзей (хз что там с емаксом, но похоже что тоже установка через "git clone"). Отдельно тулза (везуха если через dnf/apt), отдельно плагин, и потом чуть повоевать с шорткатами, ну и разобраться — у каждой же вундервафли совершенно свой подход ко всему. Слишком много выбора, но ни одного чтоб работал из коробки. То ли дело студия — 1 редактор, 1 дебагер, ходит по символам сразу, 95% народу счастливы сразу и даже не подумают что то добавлять, а в линуксе нельзя на дефолтной хрени сидеть комфортно.

Ну это не про emacs/vim,
в Qt Creator/CLion/KDevelop сразу из коробки все работает.
CLion например и уже собранный cmake включает и gdb, и всякие анализаторы кода
от системы только компилятор потребуется.

Но к слову в emacs встроен свой пакетный менеджер, поэтому "git" для него не актуален,
просто открываешь в его GUI список и кликаешь мышкой по нужным.

aik>Раз ты в теме — какой из этих хреней можно подсунуть vmlinux + модули с дебажной инфой, чтоб vim/emacs стал по символам ходить?

Ну те утилиты которые я использую никак dwarf информацию из elf не используют,
в принципе это наверное возможно, но ждать генерации кода и линковки, чтобы в измененном файле .cpp
файле заработала autocompletion это по-моему чересчур.
Я бы работал с исходниками ядра так, ставите https://github.com/rizsotto/Bear и https://github.com/Andersbakken/rtags
после этого запускаете сборку bear make -j33 , а после rc -J. , в результате получите проиндексированные
исходники и индекс будет сам перестраиваться при любом редактировании,
сборку при этом конечно нужно будет через "bear" всегда запускать, чтобы информация о новых модулях автоматически
в обновлялась.

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

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

CS>COM так точно живее всех живых.

CS>Например DirectX и относительно новые Direct2D/DirectWrite это всё COM based скажем так.
CS>Да, там нет всего что известно как ActiveX, но IUnknown и IUnknown::QueryInterface никуда не делся и активно используется.
CS>Ибо альтернативы этому в общем-то и нет.

Только нужна ли с этим работа? Или все автоматом генерируется, ибо генерилку уже написал человек, знакомый с COM

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

Z>Ну те утилиты которые я использую никак dwarf информацию из elf не используют,
Z>в принципе это наверное возможно, но ждать генерации кода и линковки, чтобы в измененном файле .cpp
Z>файле заработала autocompletion это по-моему чересчур.

Мне по символам ходить надо, чтоб знать что конкретно то скомпилилось без разглядывания дизассемблера. autocompletion — гораздо менее интересная фича.

Z>Я бы работал с исходниками ядра так, ставите https://github.com/rizsotto/Bear и https://github.com/Andersbakken/rtags
Z>после этого запускаете сборку bear make -j33 , а после rc -J. , в результате получите проиндексированные
Z>исходники и индекс будет сам перестраиваться при любом редактировании,
Z>сборку при этом конечно нужно будет через "bear" всегда запускать, чтобы информация о новых модулях автоматически
Z>в обновлялась.

А, ну я так и думал

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

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

aik>А, ну я так и думал

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

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

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

C>Тем не менее, это сейчас практически стандарт.
Популярность относительна: его много простых опенсорсных проектов используют, но он никогда не будет стандартом из-за своей врожденной убогости.
Гугл свою GN запилил, народ мезон хвалит, кто пробовал qbs никогда добровольно не выберет CMake.
То, что CMake может решать задачи сборки для простых и маленьких проектов не значит, что он будет работать для больших. Скорее наоборот. В реальной жизни организация проектов может быть очень сложная по многим причинам и CMake там не подходит.

C>И что? Если использовать CMake как простой MSVS-проект, то там будет десяток директив нужно знать.
Для поделок и простых проектов выглядит более-менее, но чуть шаг в сторону реальной жизни — начинается Содом и Гоморра (и да, это для "modern CMake" также верно).

Простой пример:
find_package(PythonInterp) устанавливает переменную PYTHON_EXECUTABLE
find_package(Python COMPONENTS Interpreter) устанавливает переменную Python_EXECUTABLE

Команды не чувствительны к регистру, а переменные — чувствительны

Язык который выглядит как декларативный, но в котором порядок выражений важен

Очень показательный факт: для решения сколько-нибудь сложных задач рекоммендуют книгу!
Если система спроектированна нормально, то кроме документации и нормальных примеров ничего не надо.

P.S. Буду признателен если вы мне покажете проект уровня Chromium/Qt/QtCreator c использованием CMake.

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

C>После CMake — это дикость лазить по десяткам окошек, когда можно просто посмотреть файл сборки.
Ну например если надо опции сборки указать в IDE, то таки надо сначала заставить IDE распарсить CMakeLists.txt, а потом еще по окошкам лазить, при этом нет увернности что не со старым cache-файлом система работает

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

S>Гугл свою GN запилил, народ мезон хвалит, кто пробовал qbs никогда добровольно не выберет CMake.
Ой, ну вот не надо. Ninja — это низкоуровневая замена Make, его можно использовать прямо с CMake. GN — поделка аналогичная CMake (так как у CMake есть фатальный недостаток). QBS — местечковое гуано.

Из реально перспективного есть только Мезон, но пока он немного сырой ещё.

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

Язык у CMake уродливый, но свою задачу оно решает.

S>Команды не чувствительны к регистру, а переменные — чувствительны

S>Язык который выглядит как декларативный, но в котором порядок выражений важен

То ли дело MSVS (с которым здесь сравнение идёт). Открыл окно свойств, руками нашёл Include Directories, поправил путь до Python'а. Потом зашёл в libraries, поправил путь до библиотек и включил нужный lib-файл. И так для каждого проекта.

Суперочевидно и декларативно!

S>Очень показательный факт: для решения сколько-нибудь сложных задач рекоммендуют книгу!
S>Если система спроектированна нормально, то кроме документации и нормальных примеров ничего не надо.
Как на QBS найти и подключить OpenCL? Ой, никак. Ручками пилить.

Ну ладно с OpenCL. А как насчёт банального Boost? Ой, тоже никак. Пилите, Шура, гирю.

Но примеры крутые, да.

S>P.S. Буду признателен если вы мне покажете проект уровня Chromium/Qt/QtCreator c использованием CMake.
https://community.kde.org/Guidelines_and_HOWTOs/CMake или https://blog.kitware.com/cmake-ctest-and-cdash-at-netflix/

На данный момент CMake является наиболее популярной системой сборки для С++, и вполне заслуженно.

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

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

S>>Гугл свою GN запилил, народ мезон хвалит, кто пробовал qbs никогда добровольно не выберет CMake.
C>Ой, ну вот не надо. Ninja — это низкоуровневая замена Make, его можно использовать прямо с CMake. GN — поделка аналогичная CMake (так как у CMake есть фатальный недостаток).
Ну так про то и речь, что даже как генератор Makefile CMake не является стандартом.

C>QBS — местечковое гуано.
Не читал, но осуждаю (С) Не ожидал от тебя такого

Вообще-то это универсальное средство сборки, которое изначально проектировалось для сборки любых сложных проектов. Это первое средство сборки с которым приятно работать, где видно что разработчики думали.

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

C>Язык у CMake уродливый, но свою задачу оно решает.
Ну вот поэтому стандартом он не будет. Решать-то можно и Makefile'ами.

C>То ли дело MSVS (с которым здесь сравнение идёт). Открыл окно свойств, руками нашёл Include Directories, поправил путь до Python'а. Потом зашёл в libraries, поправил путь до библиотек и включил нужный lib-файл. И так для каждого проекта.
Не-не, я возражаю исключительно против утверждения, что CMake это стандарт.
XML-солюшены от MSVS это вообще ужас-ужас. И дело даже не в редактировании через окошки, а в git diff в первую очередь.

C>Как на QBS найти и подключить OpenCL? Ой, никак. Ручками пилить.
Написать модули, которые будут искать библиотеки не проблема, только на практике смысла в этом большого нет: в реальном мире слишком много частных случаев и пути прописать руками обычно куда проще и быстрее.
QBS находит Qt и компиляторы, это не проблема.

C>Ну ладно с OpenCL. А как насчёт банального Boost? Ой, тоже никак. Пилите, Шура, гирю.
Так в вашем CMake точно также! Из коробки работают только самые простые примеры

Попробуйте на винде подключить boost собрынный MSVC и MinGW

S>>P.S. Буду признателен если вы мне покажете проект уровня Chromium/Qt/QtCreator c использованием CMake.
C>https://community.kde.org/Guidelines_and_HOWTOs/CMake или https://blog.kitware.com/cmake-ctest-and-cdash-at-netflix/
Опять поделки и статьи в духе как все круто! Блин, дайте ссылку на репозиторий! В чем проблема-то если CMake так хорош?

C>На данный момент CMake является наиболее популярной системой сборки для С++, и вполне заслуженно.
Да не интересны простые проекты. Дайте пример проекта уровня Chromium или Qt.

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

BE>На больших проектах объемы такие, что к фронту и беку еще отдельно идут разработчики бд, дизайнеры и т.д. Можно все повесить на универсалов (fullstack), но качество хромает.
Все зависит от уровня необходимых компетенций для того или иного проекта.
Большинство проектов — это обычный CRUD + клиенты (веб, мобилки), возможно несколько несложных отчетиков. И за чем там гуру в бд на постоянку? Или сейчас уже знаешь как работают индексы в бд — уже гуру?
Или знаешь Android Guide — гуру в разработке под Android?
Я понимаю, что DBA для той или иной базы полезен для нетривиальных настроек СУБД (PCTFree & PCTUsed в Oracle и тд.). Но он отработает денек на проект и все.
HighLoad? Да на фига он нужен стартапу, который может и не взлетит?
Сейчас программирвание осталось искусством для избранных. Для остальных: подключить библиотеки, создать схему бд, сверстать layout, написать логику на клиенте и сервере (какая бы логика не была сложной, она не будет сложнее, чем то, чем занимаются "избранные"), и обспечить взаимодействие клиента и сервера.
В чем сложность?

BE>В болото где все делает один чел лучше просто не соваться.
Один человек — делает весь проект?

BE>И я уже видел проект переписанный с node.js на dotnet core по причине нехватки производительности и сложности поддержки.
В чем сложность поддержки на node.js?

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

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

_>>Тут вопрос в другом: а сколько будет жить сама ОС Windows и MS? У тебя как бы посыл в том, что Windows будет жить вечно, как и сама MS... Однако это может быть не так.

N>Мне не надо вечно, мне надо лет 10-15 :)
N>Как мне кажется, в ближайшем будущем Windows ничего не угрожает. Какую-то часть рынка вероятно отъедят планшеты на iOS/Android, но небольшую.

И тут бац... какая-нибудь новомодная ОСь от гугла для компов и ноутов в том числе, вначале хомячки переходят, а потом и корпорации. И это может случиться и ранее 10-15 лет

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

C>>Ой, ну вот не надо. Ninja — это низкоуровневая замена Make, его можно использовать прямо с CMake. GN — поделка аналогичная CMake (так как у CMake есть фатальный недостаток).
S>Ну так про то и речь, что даже как генератор Makefile CMake не является стандартом.
В С++ нет стандартов сборки, но CMake де-факто ближе всего к нему.

C>>QBS — местечковое гуано.
S>Не читал, но осуждаю (С) Не ожидал от тебя такого

Ага.

S>Вообще-то это универсальное средство сборки, которое изначально проектировалось для сборки любых сложных проектов. Это первое средство сборки с которым приятно работать, где видно что разработчики думали.
bash — тоже универсальное средство сборки. Как и POSIX make. И что?

C>>CMake сейчас используется в крупнейших проектах. И любая система постройки для крупного проекта будет сложной.
S>Между сложной и уродливой, состоящей из костылей, есть большая разница для повседневной работы.
Все крупные системы состоят из костылей разной степени сложности. Я пока не видел ни одной полностью красивой системы сборки, которая выживает встречу с проектом на десяток миллионов строк кода.

C>>Язык у CMake уродливый, но свою задачу оно решает.
S>Ну вот поэтому стандартом он не будет. Решать-то можно и Makefile'ами.
Не на уровне CMake.

C>>Как на QBS найти и подключить OpenCL? Ой, никак. Ручками пилить.
S>Написать модули, которые будут искать библиотеки не проблема, только на практике смысла в этом большого нет: в реальном мире слишком много частных случаев и пути прописать руками обычно куда проще и быстрее.
Да-да. Это называется "ленивое программирование" — его фанаты Лиспа любят. Т.е. заявляем, что что-то можно легко сделать и не делаем.

S>QBS находит Qt и компиляторы, это не проблема.
Ну вот покажи как он найдёт OpenCL. В примерах же должно быть!!!!111111!!!

C>>Ну ладно с OpenCL. А как насчёт банального Boost? Ой, тоже никак. Пилите, Шура, гирю.
S>Так в вашем CMake точно также! Из коробки работают только самые простые примеры

Попробуйте на винде подключить boost собрынный MSVC и MinGW

https://cmake.org/cmake/help/v3.8/module/FindBoost.html — в стандартной поставке уже давно.

А ещё ведь есть: https://github.com/Orphis/boost-cmake

И как в "красивом" QBS сделать аналогичный подключаемый модуль, который мог бы подобным образом подключать библиотеки Буста?

Подозреваю, что никак. Вообще.

C>>https://community.kde.org/Guidelines_and_HOWTOs/CMake или https://blog.kitware.com/cmake-ctest-and-cdash-at-netflix/
S>Опять поделки и статьи в духе как все круто! Блин, дайте ссылку на репозиторий! В чем проблема-то если CMake так хорош?
Ээээ... ВЕСЬ проект KDE строится через CMake. Например: https://github.com/KDE/krita или https://github.com/KDE/calligra

C>>На данный момент CMake является наиболее популярной системой сборки для С++, и вполне заслуженно.
S>Да не интересны простые проекты. Дайте пример проекта уровня Chromium или Qt.
QT — вообще мизерный проект по объёму. Даже смешно как-то.

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

S>>Не читал, но осуждаю (С) Не ожидал от тебя такого

C>Ага.
Ну так о чем разговаривать

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

S>>>Не читал, но осуждаю (С) Не ожидал от тебя такого

C>>Ага.
S>Ну так о чем разговаривать

Ну так а зачем читать-то? Очевидно, что чисто местечковая поделка. Банального Boost'а там нет даже.

К остальным пунктам претензий нет?

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

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

Приложения от M$ написаны на WPF (и уже не первый год).
Так как WinApi — такой же вчерашний день, как MFC.

И для WinApi, и для MFC — недостаток один: приходится писать много не очевидного (с точки зрения пользовательской задачи) кода.

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

Как в каких компаниях. Где-то так, где-то иначе.
Знание предметной области — также нужно, но без фанатизма. Предметного эксперта девелопер софта всё-равно не заменит.

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

На сегодня эта технология действительно применяется редко где.
Лет двадцать назад — была очень популярна.

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

BI>Вопрос филосовский. С одной стороны очень мало сделал. С другой стороны поставил себя как незаменимый и вытребовал нормальное рабочее место, соотвественно программы качественные у него, международный уровень.

У меня лично есть немалые сомнения насчёт выделенного.

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

a) Пока труд этого человека устраивает Заказчика/Работодателя — он будет там трудиться.
b) Программа может запускаться и работать. Это не отменяет понятия ТЕХНИЧЕСКИЙ ДОЛГ:
https://habr.com/post/119490
https://dev.by/news/o-tehnicheskom-dolge-v-softvernyh-proektah
c) Современные студенты (которые хоть что-то соображают и умеют) — в основном амбициозны и достаточно требовательны в своих запросах.
Посему — совсем НЕ ФАКТ, что пойдут работать в подобное место.

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

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

C>>QBS — местечковое гуано.
S>Не читал, но осуждаю (С) Не ожидал от тебя такого

S>Вообще-то это универсальное средство сборки, которое изначально проектировалось для сборки любых сложных проектов. Это первое средство сборки с которым приятно работать, где видно что разработчики думали.

Здесь стоить заметить что команда Qt отказалась от продолжения
разработки Qbs в пользу улучшения поддержки CMake.

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

O>Даже если только автоматизировать в общем виде свои повторяющиеся задачи, за несколько лет "фреймворк" сам собой образуется.

Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми

O>Вне зависимости, какая технология взята за основу. И заказы будут перетекать к той группе "разработчиков на МФЦ", у которой наработанные надстройки мощнее, и точнее подходят под задачи, и как следствие Окна делаются быстрее.

Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC.

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

Z>Здесь стоить заметить что команда Qt отказалась от продолжения
Z>разработки Qbs в пользу улучшения поддержки CMake.
Это не совсем верное утверждение по двум причинам:
1. Это довольно большая компания и решения там принимает не "команда разработчиков", а менеджмент, часто по маркетинговым/политичиским причинам (source: был у них в штаб-квартире пару недель назад). Ну и в общедоступной переписке много чего есть по этому вопросу. В обсуждаемом случае решение в пользу CMake продавливал мантейнер QtCore который вообще в Intel работает.
2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6.
3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей.

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

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

Z>>Здесь стоить заметить что команда Qt отказалась от продолжения
Z>>разработки Qbs в пользу улучшения поддержки CMake.
S>Это не совсем верное утверждение по двум причинам:
S>1. Это довольно большая компания и решения там принимает не "команда разработчиков", а менеджмент, часто по маркетинговым/политичиским причинам (source: был у них в штаб-квартире пару недель назад). Ну и в общедоступной переписке много чего есть по этому вопросу. В обсуждаемом случае решение в пользу CMake продавливал мантейнер QtCore который вообще в Intel работает.

Похоже на передергивание карт, этот сотрудник Intel имеет власть принимать решения единолично,
или все-таки у него была поддержка среди остальной команды?

S>2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6.

Это же еще более крутой поворот? У них же в дереве исходников куча примеров и тестов, которые по сути обычные
Qt программы, и собирая все это с помощью CMake, они по сути будут кучу проблем исправлять и делать доступным
остальным пользователям CMake, например кроссплатформенную поддержку precompiled headers, которую никак не интегрируют в CMake.

S>3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей.

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

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

И иногда NIH синдром все-таки пересиливают, что несомненно радует.

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

Z>Похоже на передергивание карт, этот сотрудник Intel имеет власть принимать решения единолично,
Z>или все-таки у него была поддержка среди остальной команды?
Welcome to the real world. Вес мнения разных людей очень разный, большинство никто вообще не спрашивал.

S>>2. Решение "не в пользу улучшения поддержки СMake", а в пользу СMake в качестве системы сборки для Qt6.
Z>Это же еще более крутой поворот?
Нет. Они не будут заниматься разработкой CMake за пределами поддержки в QtCreator.

Z>У них же в дереве исходников куча примеров и тестов, которые по сути обычные
Z>Qt программы, и собирая все это с помощью CMake, они по сути будут кучу проблем исправлять и делать доступным
Z>остальным пользователям CMake, например кроссплатформенную поддержку precompiled headers, которую никак не интегрируют в CMake.
Они выбрали CMake именно чтобы не заниматься решением таких проблем самим.

S>>3. Все признали, что технически qbs лучше CMake, но CMake доступнее (out of the box everywhere) и знакомее для пользователей.
Z>Так ведь не важно что она технически совершеннее (что кстати не факт,
Факт. Вы же сами говорите что в CMake нет таких банальных вещей как кроссплатформенная поддержка PCH.

Z>ведь у нее нет большой пользовательской базы, возможно при столкновении с реальностью
Z>в нее пришлось бы во многих местах воткнуть костыли),
Qbs уже давно вышел из бета стадии. Если интересно, то по приведенным выше ссылкам есть описания промышленного использования qbs (команды 40+ разработчиков).
Самое главное, что он точно может собирать саму Qt.

Z>Ведь новую систему нужно протестировать в куче мест, написать ее поддержку для IDE,
QtCreator поддерживает qbs уже давно. Причем эта поддержака по определению лучше чем CMake, т.к. CMake всего лишь генератор.

Z>написать документацию
Есть. Не идеальная, но явно лучше чем у CMake, т.к. многие вещи куда очевиднее.

Z>долго и упорно заниматься пиаром
А вот этого они не делали

Z>убедить пользователей выкинуть код написанной для старой и написать код для новой и т.д. и т.п.,
Никто не меняет систему сборки просто так если все более-менее работает. Это актуально только для новых проектов или активно развивающихся/меняющихся проектов.

Z>и вот тогда встает вопрос а нужно ли более совершенная система или лучше старую улучшить?
Вопрос не корректный. Система нужна и она уже есть. Вопрос только стоит ли на нее переходить или нет. Универсального ответа на этот вопрос конечно же нет.

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

D> То выбирая Qt тебе не придется рассказывать заказчику что каждое новое сложное окно в MFC пишется по 2 дня, а то и больше.
Зато придётся предъявить ему счёт за лицензию и убедить его оплатить

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

aik>>А, ну я так и думал

Не, если это не дварф, то вот конкретно для ядра лучше уж cscope, потому что его прям его же makefile собирает на основе моего конфига, т.е. нет ненужных архитектур и прочего ненужного.
Z>Эээ... Вы читали что я написал? Мой вариант как раз будет учитывать только файлы которые компилируется,

Так и cscope это же делает, и для ядра оно собирается без допусилий.

Z>и там естественно не будет:
>> т.е. нет ненужных архитектур и прочего ненужного

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

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

AG>>Часто подобные Задачи устаревают и оказываются невостребованные, хотя ещё несколько лет назад они казались повторяющимися и незыблемыми

O>Если взять какую-нибудь зрелую разработку на тему создания типовых окон, например редактор метаданных + конструктор форм в 1с (абстрагируемся от неудачных сторон, вроде птичьего языка "для неграмотных") — что в ней за 30 лет оказалось зыблемым?
Переход от 7 к 8 версии.

O>Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?
Не переработает. Оверхед от MFC такой, что производительность часто будет на порядок отличаться. В сторону WPF.

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

Насчёт замечания о продуктах микрософта:
Какими бы они ни были костыльными и увечными, они всё-таки в топ-е по популярности среди массового потребителя. С этим как бы и не поспоришь.

AG>>Вангую, что будут перетекать в группу с Qt, или даже WPF, либо ASP.NET MVC.
O>Инструмент определяет не 100% успеха. Разве сплочённая группа опытных инженеров с мфц, написавших себе автоматизацию своих повторяющихся операций, не переработает банду живущих 1 днём обезьян с WPF?
+100500
Даже не спорю я, что группа опытных дядек с MFC окажется намного круче — как в плане теоретической подготовки, так и в плане практики.
Вот только группа вчерашних школьниц с WPF окажется дешевле.
Бизнес, с большой вероятностью, выберет второе

Да, я с сожалением признаю, что с точки зрения бизнеса окажется рациональнее — выбрать второе

Тем более, что по производительности труда они вполне могут оказаться примерно одинаковыми:
у первой группы тяжести разработки на MFC будут компенсироваться опытом разработчиков;
у второй — нехватка опыта будет компенсироваться более совершенной (и простой в применении) технологией.

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

_>Тут вопрос в другом: а сколько будет жить сама ОС Windows и MS? У тебя как бы посыл в том, что Windows будет жить вечно, как и сама MS... Однако это может быть не так.

_>Я бы опаслася складывать все яйки в одну корзинку, особенно проприетарную...

Вендекапец уже столько десятилетий пророчат — а он живее всех живых. Сколько опенсорсных операционок и экосистем за это время померло?

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

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

BE>>Я 10 лет проработал на делфи. Последние годы ездил по стране гоняясь за условно высокими зарплатами. Сейчас перешел на шарп и весьма этим доволен, т. к. не я бегаю за работой, а работа за мной. И в деньгах при переходе не сильно потерял.

_>Кхм... помнится лет 13 тому назад как раз были заявления от дельфистов, что дельфи — форева!
_>Сейчас похожие возгласы раздаются из стана .NET: .NET — форева! Но .NET уже попахивает так же как и Delphi в 2005.

Давайте посмотрим на плоды команды Хейлсберга с точки зрения хронологии:

Delphi VCL
NET. WinForms
WPF

На данный момент: WPF доступен как open-source, поддерживается в кроссплатформенном Net.Core, не имеет завязки на архитектуру проца… Продолжать список "попахиваний"?

	От:	CreatorCray
	Дата:	10.12.18 07:46
	Оценка:	+4

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	09.12.18 23:59
Оценка:	4 (1) +1 -2

	От:	nekocoder
	Дата:	10.12.18 05:01
	Оценка:	2 (1) +4

	От:	CreatorCray
	Дата:	10.12.18 07:46
	Оценка:	+5

	От:	aik
	Дата:	10.12.18 03:47
	Оценка:	1 (1) +3

От:	c-smile	http://terrainformatica.com
Дата:	10.12.18 18:59
Оценка:	+4

	От:	Stanislav V. Zudin
	Дата:	10.12.18 06:23
	Оценка:	2 (1) +1

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	10.12.18 09:10
Оценка:	+1

От:	BlackEric	http://black-eric.lj.ru
Дата:	10.12.18 16:24
Оценка:

	От:	Evgeniy Skvortsov
	Дата:	11.12.18 12:18
	Оценка:	+1

	От:	Мёртвый Даун
	Дата:	10.12.18 09:29
	Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	10.12.18 19:07
Оценка:

От:	Vetal_ca	http://vetal.ca
Дата:	12.12.18 02:15
Оценка:

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	12.12.18 16:54
Оценка: