IDE и C++

Я довольно давний поклонник IDE от Jetbrains. Тем же IntelliJ IDEA и PyCharm просто нет сопоставимых альтернатив с точки зрения скорости работы и удобства. Собственно говоря у меня у меня даже подписка на них оформлена из соображений “нравится проект – поддержи финансово”, но вот с CLion что-то пошло не так…

На мой взгляд основная проблема в том, что разработчики и менеджеры продукта пришедшие с платформ .NET и JVM просто не понимают что такое разработка на C/C++. В итоге идёт попытка переложить модель разработки с той же Java на C++. В крайне случае у меня сложилось именно такое ощущение как после личного общения с JetBrain-овцами на CppCon, так и после вчерашнего диалога в Twitter.

Собственно, проблема и непонимание состоит в том, что команда CLion упорно хочет видеть “проектную модель”. Я не знаю чем это вызвано, толи наличием libClang под капотом, толи архитектурными проблемами собственного парсера, но без реальной проектной модели CLion превращается в тыкву. Хотя, он даже и с реальной проектной моделью иногда превращается в тыкву, например спотыкаясь на сгенерированном через Protobuf коде.

К сожалению, такой подход не может работать в мире C++ на многих проектах сложнее Hello World. За исключением счастливчиков, которым доступно писать всё в Visual Studio, у разработчиков огромный зоопарк используемых редакторов и причина у этого довольно грустная, в теории CLion и должен был исправить эту ситуацию. Так вот, мои коллеги пишут в Sublime, Emacs, Vim, Eclipce CDT, Studio Code и многих других редакторах по большому счету потому, что все они практически одинаково плохи в роли C++ IDE. Ну может за исключением Emacs/Vim, за счёт его интеграции с Globals/CTags и Eclipse, за счёт наличия грамотно реализованного парсера C++. Но в Emacs/Vim ещё нужно уметь писать – это свой отдельный мир, а Eclipse даже на Xeon-ах с горой памяти на борту умудряется тормозить.

Если же говорить о проектной модели и почему привязка к ней делает редактор не пригодным к промышленному использованию – то её часто просто нет. К примеру на данный момент я периодически переключаюсь между несколькими проектами: один на базе CMake, второй на некой дикой смеси Make, CMake и SCons обвешанной sh/bat скриптами сверху. Так же я иногда заглядываю в проекты которые представляют из себя кучу файлов просто “для консультации”. Таким образом, в теории, я мог бы писать 1 проект из всех над которыми работаю в CLion, но есть ли в этом хоть какой-то смысл если мне нужно писать и другие проекты и иметь пусть приблизительную, но быструю навигацию по коду и хоть какую-то автоподстановку? По мне так никакого, так как привыкать к особенностям 2-х редакторов куда как менее удобно нежели всегда работать в одном. Жаль только надежда на то, что на менеджеров продукта CLion сойдет понимание проблемы угасла.

5 Comments IDE и C++

  1. Anastasia Kazakova

    Проектная модель CLion необходима ни как какая-то “прихоть”. Это способ узнать всю нужную информацию о проекта – файлы, которые входят в проект, флаги компиляции, header search пути, флаги линковки и пр. То есть можно попытаться сделать некий UI и “спросить” все это у пользователя, но это ж будет такая же проектная модель, только еще и своя, то есть ни с чем не совместимая. Поэтому решили начать (дальше ведь будет больше добавлять) с самой популярной модели в мире кросс-платформенной разработки на C++ (чтобы это узнать, мы проводили специальное исследование) – CMake.

    Reply
    1. Alexander Stavonin

      Анастасия – это все круто звучит, в теории, так же охотно верю что вы, JetBrains, проводили исследование. Проблема в результате – он не годен для использования и я объяснил почему. C++ проекты очень часто базируются на старых сборочных системах и их никто не будет переписывать в угоду классному редактору.

      Необходимость проектной модели прихоть – уровень автоподстановки/навигации обеспечиваемой Global/CDT достаточен в повседневной жизни. Уровень поддержки C++ в Global/CDT не идеален, но он лучше чем “вообще никак” предлагаемое CLion.

      Самые простые и распространенные сценарии в мире C++ (еще раз, выйдете за пределы мира JVM/.NET):
      1) Развитие проекта 10+ лет отроду. Он будет либо MSVS (но у них и без CLion всё хорошо) либо на некой смеси из Make, Sh, autoconf и чего угодно вплоть до самодельной сборочной системы. Тут вы пролетаете сразу, даже если Make будете парсить.
      2) Изучение исходников стороннего проекта в виде просто папки с кодом. Тут очень важна хоть какая-то, но навигация, так как любая приблизительная навигация лучше Grep.
      3) Развитие нового проекта. И вот только тут CLion позволяет со скрипом (у меня CLion так и не увидел сгенерированный через FindProtobuf исходники) работать над проектом.

      >> То есть можно попытаться сделать некий UI и “спросить” все это у пользователя.

      В этом нет никакой необходимости. Где находятся системные include вы знаете и можете всё найти. Вы знаете директорию с кодом пользователя и можете (наверное, зависит от реализации вашего парсера) её разобрать. Будет криво и не точно? Будет, но будет работать, а не говорить что “не нашел ничего”.

      Reply
      1. Anastasia Kazakova

        Я не буду спорить, что многих разработчикам и простого Vim достаточно. Цель CLion-а именно в предоставлении умных фич, которые требуют знаний о проекте (и хорошего и точного понимания кода, иначе один рефакторинг может испортить все). В C++ довольно легко неправильно понять код. Даже для простейших вещей, типа подсветки keywords, порою требуется глубокое понимание кода (читай, парсинг/резолв).

        Директории с кодом пользователя, безусловно, разобрать не достаточно. А от флагов компиляции (особенно для кросс-платформенных проектов, которые собираются на платформах отличных от платформы разработки) сильно зависит, как парсить/резолвить код.

        Но опять же, если достаточно “криво и неточно”, то наверное и не нужен никакой умный редактор, а достаточно обычного Vim/Emacs.

        И да, мы исследовали именно разработку в C++ мире (да и C++ разработчиков в команде достаточно), и смотрели именно на самые популярные модели там. CMake используется очень многими. На CMake переходят большие и маленькие проекты (вспомните LLVM, для примера), его активно продвигают разработчики другого тулинга (вспомните, Conan и его predefined helpers).

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

        Reply
        1. Alexander Stavonin

          А что вам мешает иметь поддержку папки с исходниками по аналогии с CDT? Там ведь парсер отлично работает, чего нельзя сказать про сам Eclipse.
          Всё же позиция продуктовых менеджеров JB загадочна для меня. Вы не можете выпустить универсального редактора имея все инструменты уже в готовом состоянии.

          Reply
          1. Anastasia Kazakova

            Папку можно открыть, ничего не мешает. Возьмите вот CLion 2018.1 EAP и там уже можно. Но никакой навигации, комплишена там, конечно, нет, потому что не понятно, как это парсить/резолвить. Если CLion ошибется, то велика вероятность, что рефакторинги или еще какие-то умные действия приведут к некорректному коду.
            Eclipse кстати тоже же имеет проектную модель, просто свою. И в рамках нее и парсит, не всегда корректно, особенно когда данных не хватает.

Leave a Reply