CLion’s quick tour updated to celebrate 2 years!

Anastasia Kazakova

Hi everyone,

CLion is two years old—a big toddler! Over this time we’ve boasted an impressive user base growth of almost 400%, which has given us all the confidence in the world to continue and improve.

Remember what CLion was capable of when you joined us? Some things have stayed unchanged, for example CLion is still CMake-only, even though CMake smart support has evolved greatly. But the rest has been impressively enhanced:

  • Support for C++14, initial support for C++17, and C11 keywords
  • Code generation options for operators and lots of new and improved code inspections & intentions
  • Microsoft Visual C++ compiler experimental support
  • Doxygen
  • Clang-Tidy (2017.2 EAP)
  • LLDB on Linux and macOS, remote GDB debug, and attach to local process
  • Disassemble view
  • Google Test and Catch
  • Python support
  • Updated Go plugin, plugin for Swift (covering Linux), Remote Host Access, and others

Did I leave out your favorite feature? Most likely I did.

It’s a good time to update our Quick Tour Video now. Phil Nash, our developer advocate, did a great job and prepared a new recording. Check this fascinating monster story:

What do you expect from CLion in the next two years? Share in the comments below! We’re listening and it sure will be interesting to see how things develop 😉

Download CLion

Your CLion Team
The Drive to Develop

Comments below can no longer be edited.

15 Responses to CLion’s quick tour updated to celebrate 2 years!

  1. Olof says:

    May 2, 2017

    There’s a lot of stuff I wish for, but I need only two things, improved speed (including removing freezes) and correctness.

    Also, the reason I’m using CLion in the first place is due to the superior refactoring of ReSharper (for C#). I’m betting that CLion will become the best IDE for refactoring. Currently it is pretty far away. Lots of false positives and I rarely use refactoring because it is currently a net negative to my productivity. It doesn’t work about 50% of the time and it often refactors things wrong. Some times I’m sure it would save time but I just don’t trust it.

    Same thing with the red squigglies. They are a net zero help right now. If I trust them I spend my time chasing my tail because the code marked as wrong is often actually correct. On the other hand they are good enough that sometimes they help me so I don’t want to just completely ignore them.

    I think that the initiative needed is for Jetbrains to open up and experiment with large open source cmake based projects. I think a Jetbrains developer could easily log 10 error reports a day by just trying to refactor large projects. And when you have the ability to reproduce the issue it is much easier to fix. Or set up CLion to log every little red squiggly, open a large project, then go eradicate the squigglies.

    You _need_ to improve the quality. The biggest issue with CLion is not missing functionality, it is one of quality, with correctness and speed (including freezes) being criteria.

    • Anastasia Kazakova says:

      May 2, 2017

      Thanks Olof. Fair enough.

      I just want to assure you that we do test on various projects and we know about many correctness issues. And this is currently under investigation and the work in that direction is in progress.

      • Olof says:

        May 11, 2017

        Here’s an example (this is with the EAP from today).

        I tried to move some code in a gtest test file to a separate file.

        The code I tried to move looked like this

        bool operator==(const MyType &lhs, const MyType &rhs)
        return std::tie(…
        MATCHER_P(MyMatcherName, expectedValue, “no match for you”)
        { return *arg == expectedAck;}

        Several things went wrong:
        1) The header file was empty other than the
        //Created by Olof
        #ifndef myFile
        #define myfile


        2) The CPP file had generated broken code. It had split my matcher in half with the operator== code in the middle.

        MATCHER_P(MyMatcherName, expectedValue, “no match for you”)
        bool operator==(const MyType &lhs, const MyType &rhs)
        return std::tie(…
        } { return *arg == expectedAck;}

        3) It took about 3 minutes of waiting for the move refactor to happen. This is on a 32 core server with 32GB of RAM.

        4) When I undid the refactoring through undo the generated files where still present.

        I’d love to help by using refactoring and creating ways to reproduce problems and submitting it to your YouTrack but it just isn’t feasible. I’d spend half day of every day doing that.

        That’s why I think JetBrains needs to find a better and more effective way to find and root out these issues.

        My suggestion is to download several large cmake based projects and just pretend-work in them to find issues. I’ve said that previously. I’m repeating myself for clarity.

        I realize that C++ is a tricky language. I think JetBrains is a great company with great products. But for CLion I think you need a strategy change to improve the quality of JetBrains flagship area, which in my mind is products that “understand” code and helps developers develop with pleasure. Right now CLion is failing that.

        I feel as if the current vision for CLion is “Mediocrity for the masses” because features are being added while the state of the core product is poor. I understand that this is to increase your potential market share which is important, but in the mean time it hurts your current user base.


        Sorry for the tough love.

        • Anastasia Kazakova says:

          May 12, 2017

          I can assure you that we do test on big and complicated projects. Moreover, we have some people in the team dogfooding the IDE. We are aware of many issues with the parser (and with refactorings and code analysis in particular), and they are mostly logged in to the tracker. Right now we have a big plan how to overcome the existing issues, that includes big and global changes in many areas, starting from the bottom. This means some particular issues may not be fixed soon (if they are related to the upper parts), but in general the parser will improve step by step.

        • Anastasia Kazakova says:

          May 12, 2017

          Anyway, is it possible to get some sample to reproduce this problem in particular?

        • Anastasia Kazakova says:

          May 12, 2017

          After some search through the tracker, I guess some performance issues may be caused by

  2. Dawid says:

    May 2, 2017

    Agree with olof

  3. Cam says:

    May 3, 2017

    Enhanced memory inspection capabilities

    • Anastasia Kazakova says:

      May 3, 2017

      Would integrating Valgrind be an option here?

  4. Brett Cooper says:

    May 3, 2017

    In the future, debugging that lets me define the data format, dec,oct,hex, binary or object structure.

    • Anastasia Kazakova says:

      May 3, 2017

      Interesting suggestion, thanks!

    • Robin Newhouse says:

      May 7, 2017

      Seconded! I’ve had to resort to a lot of printf instead of proper debugging.

  5. Roman says:

    May 4, 2017

    Currently I use Clion for Linux userspace development, but since my job is in embedded development I wish Clion will eventually support some embedded stuff too, like Makefiles. Opening Linux kernel source in Clion can be an example.

    • Anastasia Kazakova says:

      May 4, 2017

      Thanks for the feedback. We do consider some work in that direction.

  6. Robin Newhouse says:

    May 8, 2017

    All constructive criticism aside, I love CLion as much as all the other Jetbrains IDEs I use. I’m finally sinking my teeth into C++ after years of dancing around it, and CLion makes it an approachable task. Thanks for all the work you do and thank you SO MUCH for providing a student license. I’m super happy with what’s been done with this IDE so far.


Subscribe for updates