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

Не понял, "как работают опытные пользователи vim и emacs", а они точно опытные?
Просто copy/cut/paste и выделение в Emacs работают как во всех остальных редакторах (можно и чисто
emacs специфично выделать типа ctrl+space, но shift и выделение мышкой тоже работает),
поэтому выделить что-то и перетащить можно точно также,
переход к другому уже открытому файлу требует нажатия 4 (во многих IDE сделано похоже по функционалу,
для переключения вкладок с помощью клавиатуры),
закомментировать кусок можно как обычно выделив и отдав команду закомментировать,
в общем в этих обычных вещах разницы вообще никакой нет,
vim немного специфики добавляет, но у него выделение в командной режиме тоже одной клавишей
включается, может "ваши опытные пользователи" просто ничего не умели?

Здравствуйте, 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 подобных затаптывал только в путь.

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

А, ну я так и думал Не, если это не дварф, то вот конкретно для ядра лучше уж cscope, потому что его прям его же makefile собирает на основе моего конфига, т.е. нет ненужных архитектур и прочего ненужного.

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

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


aik>А, ну я так и думал Не, если это не дварф, то вот конкретно для ядра лучше уж cscope, потому что его прям его же makefile собирает на основе моего конфига, т.е. нет ненужных архитектур и прочего ненужного.


Эээ... Вы читали что я написал? Мой вариант как раз будет учитывать только файлы которые компилируется,
и там естественно не будет:

> т.е. нет ненужных архитектур и прочего ненужного

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

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

Здравствуйте, 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?