Комментарии 40
Спасибо за интересную статью! ️
В общем, у нас и продуктов несколько, и парсеров много.
Распыляете ресурсы, получается? :)
работаю с девелопер-адвокатами и сообществом.
Прочитал штук пять статеек и ответов на вопрос «кто такой developer advocate», но так и не понял. Зато я теперь точно знаю: человек, который в суде распинается перед присяжными, что программист не виновен в багах — это НЕ девелопер-адвокат.
Ну, продукты разные, архитектуры разные, да и парсеры разные пробуем. Задача ведь не свой самый любимый парсер холить и лелеять, а сделать лучшее решение для конечного пользователя. А тут без экспериментов никак!
Девелопер-адвокатов мы раньше называли евангелистами, но как-то нам все же хотелось в названии позиции больше «девелоперского», потому что это так и есть про этих людей.
Девелопер-адвокатов мы раньше называли евангелистами, но как-то нам все же хотелось в названии позиции больше «девелоперского», потому что это так и есть про этих людей.
Картинка «Because C++» видать по мотивам: «Потому что, гладиолус !»
Раз у вас в дальнейшем будет углубляться поддержка embedded, то планируется ли какая-либо интеграция с системами Mender, SWUpdate, RAUC и прочими системами firmware update?
Раз у вас в дальнейшем будет углубляться поддержка embedded, то планируется ли какая-либо интеграция с системами Mender, SWUpdate, RAUC и прочими системами firmware update?
Хм, я уж было подумал, что Вы про единорога PVS-Studio будете рассказывать.
Постоянно пользуюсь CLion, но почти не видно развития среды. Разве что проекты с каждом релизом грузятся всё дольше и дольше.
Вот вы говорите, что метите в embedded, но в то же время никак не запилите поддержку Makefiles (уже 5 лет обещаете), не говоря уже про другие системы сборки (до поддержки какого-нибудь IAR я думаю, что и не доживу даже).
Вот вы говорите, что метите в embedded, но в то же время никак не запилите поддержку Makefiles (уже 5 лет обещаете), не говоря уже про другие системы сборки (до поддержки какого-нибудь IAR я думаю, что и не доживу даже).
Забавно, а некоторые пользователи нам наоборот говорят, что все слишком быстро меняется) И движок альтернативный на кланге появился, и remote dev режим добавился, и профиляторы появились, и кстати про проектные модели — compilation database. Это все за последний год где-то.
Makefiles сейчас можно использовать через compilation database. Вот здесь небольшой туториал. Планируется в ближайшее время такой подход еще чуть автоматизировать, чтобы меньше надо было руками делать.
IAR тоже в планах, может и в этом году даже, как elmot будет успевать)
Makefiles сейчас можно использовать через compilation database. Вот здесь небольшой туториал. Планируется в ближайшее время такой подход еще чуть автоматизировать, чтобы меньше надо было руками делать.
IAR тоже в планах, может и в этом году даже, как elmot будет успевать)
а некоторые пользователи нам наоборот говорят, что все слишком быстро меняетсяДа где ж быстро? Почти пять лет не можете исправить относительно тривиальный баг.
НЛО прилетело и опубликовало эту надпись здесь
Когда я говорила, что на Linux вариантов не много, я как раз к тому, что там мало хороших альтернатив. Qt Creator действительно одна из лучших.
Если сравнивать с qt creator, то рефакторинги, которых гораздо больше, код анализ, который умеет показывать гораздо больше всяких проверок, чем просто ошибки компиляции и clang analyzer / clang-tidy (хотя и они тоже есть), больше действий навигации (go to symbol / base class / derived class), больше опций кодогенерации, ну и множество функционала из платформы — от встроенного VCS и local history до разнообразных плагинов (Rust, например, или Vim-emulation mode).
А новые стандарты языка они придумываются, потому что разработчикам нужны языковые средства, которых еще нет в языке, поэтому они пишут библиотеки, а потом пытаются это стандартизировать, чтобы все работали с общим/единым подходом, а не каждый со своей библиотекой локальной. Инструменты же обычно создаются для облегчения каких-то ежедневных задач, когда вы устаете делать одну и ту же задачу постоянно вручную.
Если сравнивать с qt creator, то рефакторинги, которых гораздо больше, код анализ, который умеет показывать гораздо больше всяких проверок, чем просто ошибки компиляции и clang analyzer / clang-tidy (хотя и они тоже есть), больше действий навигации (go to symbol / base class / derived class), больше опций кодогенерации, ну и множество функционала из платформы — от встроенного VCS и local history до разнообразных плагинов (Rust, например, или Vim-emulation mode).
А новые стандарты языка они придумываются, потому что разработчикам нужны языковые средства, которых еще нет в языке, поэтому они пишут библиотеки, а потом пытаются это стандартизировать, чтобы все работали с общим/единым подходом, а не каждый со своей библиотекой локальной. Инструменты же обычно создаются для облегчения каких-то ежедневных задач, когда вы устаете делать одну и ту же задачу постоянно вручную.
К сожалению на больших проектах (несколько миллионов строк кода) Clion практически перестает работать, а QtCreator бегает довольно шустро.
Подтверждаю… Пользуюсь одновременно CLion и QtCreator… Стараюсь при этом сидеть на EAP и репортить в багтрекер всё что мешает. Только последнее время почти всё что сообщаю оказывается дубликатами уже известных проблем…
При этом не ощущается, что CLion становится быстрее. На большом проекте банальное переключение Header/Source может занять… целых 10 минут, А Find References зависнуть, намекая о внеплановом кофе или даже обеде.
А при открытии cpp-ков с тестами (gtest) IDE вообще умирает.
Switch header/source платформенный экшен, который надо переделать по-другому (с учетом C++ специфики). Оно in progress) Надеюсь, будет уже в 2019.2
Вообще перфоманс — это самая клавная сейчас задача. Там много всего большого переделывается, в том числе архитектурно, чтобы принципиально вопрос решить. При этом в каждом релизе есть какие-то улучшения, видимо просто вам пока не везет( Надеюсь, до вас улучшения тоже скоро дойдут!
Вообще перфоманс — это самая клавная сейчас задача. Там много всего большого переделывается, в том числе архитектурно, чтобы принципиально вопрос решить. При этом в каждом релизе есть какие-то улучшения, видимо просто вам пока не везет( Надеюсь, до вас улучшения тоже скоро дойдут!
Спасибо. Будем надеяться :)
А еще просто жутко бесит, что CLion может в фоне непонятно что делать (даже без уведомления в Background Tasks). Даже сборка в CLion раза в два замедляется по сравнению со сборкой в терминале… Типа такого: https://youtrack.jetbrains.com/issue/CPP-15627
И да, нет нативной поддержки ninja в 2019 году :(
Да уж, отсутсвие ninja, кроме как через custom build target, удручает. Даже в Visual Studio! ninja работает из коробки.
С ninja история в том, что если поддерживать Ninja генератор, то нам не хватает информации нужной в получаемых файлах. Есть вариант через CMake server их поддержать и мы думали так сделать, но пока просто банально ресурсов на такую задачу не хватает.
У вас уже есть поддержка compile_commands.json. Сделайте гибридный какой-то режим в виде cmake -GNinja -DCMAKE_EXPORT_COMPILE_COMMANDS=1.
Чтобы хотя-бы была возможность выбирать цели для сборки.
Можно сейчас и так сделать Custom Build Target, который будет использовать -GNinja, а потом Custom Run/Debug Configuration, чтобы запускать сборку таргета с Ninja.
Тут проблема в том что эти цели нужно создавать руками (что не очень удобно). Плюс теряются удобные фишки в виде запуска тестов просто из контекстного меню CPP-ка (не зная даже Build Target-а)
Интересно как он в Visual Stuio работает, через CMake Server?
Если будете делать CMake Server, постарайтесь оставить текущее окошко «Projects» без изменений. То как оно сделано в QtCreator (показывает только файлы из CMake проекта) не удобно, постоянно приходится переключаться между «Projects» и «File System».
Если будете делать CMake Server, постарайтесь оставить текущее окошко «Projects» без изменений. То как оно сделано в QtCreator (показывает только файлы из CMake проекта) не удобно, постоянно приходится переключаться между «Projects» и «File System».
Смотрели ли вы на cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html?
Я не уверена, что VS парсит аутпут генератора в случае CMake + Ninja. Сложно сказать.
На тикет про сборку посмотрим еще раз. Вообще не должно быть такого, конечно. Заводите такие вещи в трекере, заранее спасибо.
Тыкал палочкой CLion пару лет назад. Во-первых, на кодовой базе хромиум (CentOS 7.2, 8 core, 32 Gb) он умер. Во-вторых, проект поменьше он распарсил через 15 минут, но лагает даже при передвижении курсора. В-третьих на темплейтном коде он подчёркивает полностью всё после ошибки. Нетбинс все проекты поднимает на раз и там можно свободно работать. Кстати, у них свой парсер, он понимает примерно 80% с++14/17 кода и не тормозит. Если апач не сольёт с++ плагин, то лучше ничего не надо.
Netbeans C++ увы всё, не развивается. Eclipse CDT тоже полумертвый. Вся надежда на clangd.
Хромиум — это и правда тяжко пока, но это самое «худшее», что можно открыть в C++ IDE, с точки зрения перфоманса) Такой референсный тест. Мы у нему стремимся, безусловно.
Сейчас кстати я уверена, что с шаблонами там все ок, потому что красится код нашим вторым парсером на базе Clangd.
Парсер в NetBeans все же не так хорош, как вы себе это представляете. И да, у нас работает человек из NetBeans команды, делает как раз парсер на базе Clangd. NetBeans до закрытия всего добра в Апач именно туда тоже и двигался.
Сейчас кстати я уверена, что с шаблонами там все ок, потому что красится код нашим вторым парсером на базе Clangd.
Парсер в NetBeans все же не так хорош, как вы себе это представляете. И да, у нас работает человек из NetBeans команды, делает как раз парсер на базе Clangd. NetBeans до закрытия всего добра в Апач именно туда тоже и двигался.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного технической лирики о C++ Tools от JetBrains, и при чем тут единороги