Clion stability


having recently heard about the imminent rease of version 1.0, I would like to present my view about the product, and pose a few questions. My findings stem from a mid-sized project on which I have been using CLion intensively and extensively for a couple of months now:

  1. I frequently see code passages which are marked red, and CLion presents some error message when hovering the mouse over them. However, the code compiles correctly, there really is no error
  2. on Linux (which is my favorite platform), the debugger often fails in the middle of stepping through the code. The buttons become grayed, and stepping is no longer possible. I also often see messages about some "timeout", and sometimes the loading of local variables takes extremely long.
  3. The fact that compile error messages are not parsed by CLion makes refactoring large code bases impractical. When I have, say 20 errors, and 80% of the console littered with compiler "proposals" and such, I move over to QtCreator, which gives me the error count and puts each error in one line, with related details available on request.
  4. MinGW on windows is unfortunately not up to date. Until recently I was able to work around that, but now I am depending on Xerces, and mingw isn't able to generate a usable Xerces build. BTW, mingw64 crashes when it sees boost precompiled headers.

In summary, I currently cannot rely on CLion as my sole IDE on any of my target platforms. It is always either the compiler or the debugger that fail at certain points. The fact that error messages aren't parsed is somtimes annoying, as are the wrong code error markers. There are, of course, a lot of points on the positive side, which, I would say, right now outweigh the problems. Remains the question whether these problems will get fixed, and if not, whether the commercial price point will tilt the balance towards the negative side. I hope you guys are holding some good stuff back to make moving to the for-pay version more appealing..

BTW, I would offer access to my project source code for tracking down the code analysis errors. I dont have time to isolate the issues to simple cases.



to illustrate some more: I just accepted CLions offer to generate a non-existent method from an in-code call.

Heres the code line with the invalid call:

heres the generated prototype (just one non-compilable line. Parameters and closing bracket missing):

void processAppModelWhen(TItemWithSubitems::Ptr const;

and heres the generated implementation:

void ViewModelGenerator::processAppModelWhen(TItemWithSubitems::Ptr const aConst) {


not really helpful. I'd make this an error report in the tracker, if I knew how to extract ansd describe..



just tried the debugger again -> fail. This has become much more serious with the latest release. Debugging is basically impossible here


Hi, Christian,

Thank you for your detailed feedback.

Could you please send us your project and idea.log, which you can find via Help | Show Log In Files, to for investigation your problems.

Also please specify what mingw distribution do you use?
MinGW 64 was one of the top-voted feature requests in our tracker.


I will send the code on wednesday, after getting the agreement of my boss. Be aware, however, that the code has a few external dependencies (libraries like xerces, odb) which you would have to install.

mingw64 may be the best option on windows other than Visual C++. And I understand that you have another product available for VC++, specifically


unfortunaltely, I cannot send the full code base. Would have been a lot of setup for you, too. I would simply suggest that you checkout some large open source project which makes use of  templates and other modern C++ features and test with that. In fact, I assume that you are doing exactly that already, so you will probably already be busily working on the very issues I am referring to.. ;)


BTW, after disabling the GNU C++ library renderers, I can debug again. Maybe next EAP...


Hi Christian.

As for your exampe: we've tried to reproduce your problem with stub example (assuming as much as possible from your post) but it worked for us:

class TItemWithSubitems {
    class Ptr;

class ModelViewGenerator {
    void processAppModelWhen(TItemWithSubitems::Ptr ptr, int when, int method, int modelref, int var);

    void foo() const {
        TItemWithSubitems::Ptr item;
        int when, method, modelref, loopVar;
        processAppModelWhen(item, when, method, modelref, loopVar);


void ModelViewGenerator::processAppModelWhen(TItemWithSubitems::Ptr ptr, int when, int method, int modelref, int var) {


If you provide a standalone test case, it would be perfect.