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

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

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

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

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

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

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


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

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

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

Здравствуйте, 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?
Это совсем не то, более того совсем неудобно.
Пример понагляднее: вот смотрю я в корку, ничего есессно не шагаю — там всё уже упало, надо постмортем делать.
Лажу по фреймам, потокам, смотрю на всякие состояния в куче потоков и стеков.
Как мне сделать чтоб было так же удобно как и в вижле? Типа такого (первый попавшийся пример из гугла):

Здравствуйте, 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 + некросплатформенный С++.

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

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

Мне не надо вечно, мне надо лет 10-15
Как мне кажется, в ближайшем будущем 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 по отзывам в США плохо, платят мало, и работа уезжает в Китай.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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. И количество кликов мышью в виндософте меня невероятно злит, причём, цинизм ситуации в том, что это как раз в винде то на всё есть клавиатурный шорткат, а в линуксе простейшая хрень типа выделить произвольный кусок текста в консоли — требует мыши, но шорткаты в винде сделаны настолько трёхэтажными на "отвяжись", что ими мало кто пользуется, а линуксовые долбанутые, но — короткие.

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

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


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

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

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


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