CLion 2016.3 released: Modern C and C++ support, remote debug on Windows, CMake workflow changes and more

Great news: As of today, CLion 2016.3 is generally available!


In its third and final update this year, our cross-platform C/C++ IDE gets a firmer handle on modern language standards, incorporates top-voted changes in working with CMake project model, and brings lots of other enhancements. Take a closer look at these and other capabilities available in CLion 2016.3:

Download CLion 2016.3

C++ language support

With C++ evolving quickly, it’s crucial for an IDE to support modern standards. While relying on our own parser, we do our best to catch up. Version 2016.3 brings lots of improvements for C++11 and C++14.

User-defined literals

First, we’ve introduced support for user-defined literals. This concept of the built-in type that you can define based on integer, float, character, and string literals by adding special suffixes, became especially popular after it was included in std::chrono (as well as some other places in the Standard Library). CLion 2016.3 is not only aware of the syntax, keeping code with user-defined literals away from false-positives in code analysis, but it also understands the type and shows it in the Quick Documentation popup (Ctrl+Q on Lin/Win, F1 on macOS):
It also allows you to rename such literals:

Overload resolution improvements

In order to make CLion’s code analysis more accurate, we’ve improved our overload resolution support, which eliminates lots of false-positives. You can now catch two problems on the fly in the editor, thanks to the new code inspections:

  • Ambiguous call
  • No matching function to call


Code analysis accuracy

Static analysis in CLion helps you catch problems on the fly and write beautiful and correct code more easily. CLion 2016.3 introduced some important fixes for:

  • Reference may be null checks for one-element initializer list case;
  • Loop variable is not updated inside the loop warnings;
  • Simplify quick-fix for overloaded operators;
  • Unused variable in case of non-trivial destructors (including a fix for for the so called ‘guard’ idiom);
  • Platform-dependent sizeof()-related analysis;
  • Local variable is never used check inside the sizeof() expressions;
  • Code analysis check for bitwise shift operators.

It also provides support for __attribute__(unused) and __builtin_unreachable.

C++14 digit separator

The last but not the least, is C++14 digit separator support. Not that much to say here except that it now works, but it does mean that we are open now to C++14 fixes and will look at it more closely soon. So if you have something in mind from C++14 that really annoys you in CLion, let us know.
Current list of supported features sorted by standard can be found in our webhelp.

C language support

CLion is an IDE for both C++ and C, so we’ve put our efforts in C language support as well, including _Generic keyword support and completion for specific C11 keywords such as _Thread_local, _Alignas, _Noreturn, _Static_assert, and _Atomic:

CLion 2016.3 also introduces support for gcc atomic builtins:

By the way, you may remember that we promised C and C++ project templates in 2016.3. Unfortunately, they are not ready yet, but will definitely make their way to one of the 2016.3.x updates a bit later. Stay tuned!

Remote debug

CLion 2016.2 introduced remote GDB debug feature for Linux and macOS. This included connecting from CLion on Linux or macOS to the application running remotely on Linux machine under gdbserver.
With 2016.3 the feature is enabled on Windows as well. Use it to debug applications run under gdbserver on remote Linux or Windows machines. Find more details about cross-platform debug in this case here.

CMake workflow changes

CMake is a core technology for CLion as it’s the project model and the whole IDE relies on it heavily. While we still consider adding other build systems support (i.e. Makefiles, autotools, qmake), we want first to finalize the approach CLion takes when working with the project model. With the previous solution, our users have complained about:

  • high memory usage,
  • useless configurations building,
  • performance issues, and
  • restrictions on CMake generation directory configuration.

To incorporate your suggestions and solve the above problems, we’ve come up with a new approach in CLion 2016.3.

In a nutshell, CLion now builds only one selected configuration and allows setting the CMake generation directory. That also makes it possible to open projects from an already existing CMake generation folder without additional generation (right now this only works for Makefiles generator) – just point to a generation folder or CMakeCache.txt file:

There are also CMake output logs available in the CMake tool window, and the ability to add variables to CMake Cache. Read more details in this blog post.

While the changes have been released, we are still working on this and will roll out a couple of improvements in the upcoming updates and next versions:

  • Allow configuring defaults for the CMake settings (CPP-1887).
  • Find existing generation folder and suggest to use it when opening CMake projects (CPP-7943).
  • Allow additional generated build types (CPP-3159).

Let us know what you think about the changes in the comments below and in related issues in the tracker.

Resolve context

Consider the situation when some source or header file is used for several CMake targets, and their sets of variables and flags differ. It could happen that in your editor, code highlighting, find usages, refactorings, code generation and code analysis all depend on these variables and flags. How should an IDE deal with this situation? We believe that the correct way is to take into account the build/run configuration selected (that actually complies with the CMake target).

Since version 1.0, CLion has allowed using a special resolve configuration switcher in the bottom right-hand corner of the editor:

However, in version 2016.3 we made it possible for CLion to switch the resolve context automatically when the user changes the build/run configuration. This makes the whole experience nicer and more comfortable. You don’t have to think about these things as the IDE does it for you. Isn’t that great?

If you still prefer the manual switcher, feel free to use it. However, be aware that automatic switching will then be disabled until the IDE restarts.

Semantic highlighting

When you read code, wouldn’t it be great to see how the data flows through the code at a glance? Highlighting each variable/parameter with its own color appears to be possible solution. That’s where the idea of semantic highlighting comes from.

Many of you have asked us about this feature in CLion, and today we are glad to say it’s available in CLion 2016.3. Three simple rules are used to highlight the code:

  • Each parameter and local variable has its own color.
  • CLion tries to keep colors unique inside the body of a function or lambda.
  • Identifiers with the same name are assigned the same color.

Go to Editor | Color & Fonts | Language Defaults to enable Semantic highlighting in CLion.

Improvements for UE4 projects

Games created with Unreal Engine 4 can be developed with CLion. However, previously it took quite some effort to get a CMake project for UE4 game ready. With a third-party plugin for Unreal Engine, CLionSourceCodeAccess, that task becomes a lot easier.

Another plugin made by one of our team members, Unreal Engine 4 SDK Support, can speed up your game development by adding extra completion options for UE4 reflection specifiers, which CLion is unable to provide by default:

We’ve also introduced significant performance improvements for re-opening projects that have already been indexed once in CLion.

Here’s a good read if you’re interested in developing UE4 games in CLion.


Templates are the cornerstone of modern C++, and we believe IDEs should treat them specially.

CLion’s Doxygen support includes generation of documentation stubs for types and functions that have parameters, return a value or throw an exception. If there are template parameters in a function, class or structure, CLion 2016.3 will generate a stub that includes the tparam tag:

In addition, the Rename refactoring for such a parameter updates the documentation comment.


Like all IntelliJ-based IDEs, CLion 2016.3 comes with a set of improvements for Version Control Systems support:

  • Undo actions for the last change that you haven’t pushed yet, and the ability to restore a deleted local branch.
  • Git Sign-off commits possibility.
  • Ability to resolve simple conflicts in one click (nonoverlapping changes on one line):
  • Performance improvements for filtering in Git and Mercurial log, as well as some nice UI polishing.

Other changes

Among other fixes worth mentioning is the Find in Path dialog, which now keeps previously used settings (scope, file name filter, context, etc.) regardless of where you call it from. This can be helpful when doing subsequent searches through the various folders in the project:

To play with the new features, check our special repository that we maintain in order to illustrate changes in CLion 2016.3 in a very code-centric way.

Check out this short demo to see new features in action:

To learn more, please visit the What’s new in CLion 2016.3 page on our website, view our demo and download CLion for your operating system:

Download CLion 2016.3

Your feedback is very welcome in the comments section below!

Your CLion Team

The Drive to Develop

This entry was posted in Announcement and tagged , , , , , , . Bookmark the permalink.

55 Responses to CLion 2016.3 released: Modern C and C++ support, remote debug on Windows, CMake workflow changes and more

  1. Olof says:


    And now I can’t wait for the roadmap for the next major release.

    You might want to pin this above the 2016.3 EAP announcement.

  2. Roman says:

    Congrats! Clion is now the best IDE for CMake projects! But I hope to have custom project (custom build-system) support in next release :)

  3. RiaD says:


    Is it now impossible to change the configuration type (e.g usually run app in release, but change to debug when debugging or vice versa) without going to settings page?

    It was rather useful feature for me.

  4. RiaD says:

    Good to see the language support:)

    Hope it’ll be possible to start using most usefule features of c++17 such as structured bindings :)

  5. Dawid says:

    Unfortunatelly there is no much change in the high memory usage in my case it’s usually 1663 of 1987 M, which is really high.

    Project is quite big, though

  6. Vladeta says:

    New version is just fine and changes for cmake are also OK. Only issue with this is now the deploy. This is now pain in the… Before all libraries and bin were in one folder, so it was easy to upload. Now, they are in source tree and you need to add mapping for all folders. It could be nice to have upload without the path. Or there is something like that?

  7. Leo says:

    Can I restore the old behaviour for the generation directory? Or set a default so that every time I open a new project, the generation path is something like ~/.clion/$ProjectName)?

  8. Peregrin says:

    With previous version it was possible to change build type in Run/Debug Configuration window for any target.
    In this version there is only Debug option available.
    How to switch to Release now?

  9. Anton says:

    The new CMake model is good, but now it’s impossible to set the build type. There is only one option – Debug. Is this a bug?

  10. patlecat says:

    I’m still struggling with a few things that still I miss in CLion. I can now at least use GCC 5.4 which means that I can start testing it. I use Windows to develop and compile for Linux/Unix as well. But I need a few more things to make the IDE an indispensable workhorse to me, now it’s just a toy:

    + Vagrant Support!!
    + Remote Debugging through Vagrant
    + Simple 1 click creation of a new build target (Debug, Release, etc.) also on the Vagrant system!
    + Simple option from the editor to select those build targets
    + Simple option (and easy to find) to change the font size of the editor globally
    + GCC6 support
    + CLang 3.9 support
    + Google UnitTests

    • Anastasia Kazakova says:

      Let’s start from an end:
      Google UnitTests – supported, what’s the problem with them?
      CLang 3.9 support – also supported
      GCC6 support – under development, planned for 2017.1 –
      Simple option (and easy to find) to change the font size of the editor globally – how about Settings | Editor | Colors & Fonts | Font?

      Simple 1 click creation of a new build target (Debug, Release, etc.) also on the Vagrant system!
      Simple option from the editor to select those build targets
      – Not sure what do you mean. You can create configurations in Edit Configuration menu. Then you can call Run/Debug and select configuration from the list. Also CLion automatically creates configurations per each CMake target in the project.

      Remote GDB Debug is available.
      With Vagrant it’s also possible: if you can run gdb server on your Vagrant VM, you’ll be able to connect with CLion.
      More options for Vagrant support are logged as feature requests here:,

      • patlecat says:

        As I said I’m new to CLion and if those options are all possible and there, then I haven’t found them – also not from the documentation. And I searched for a long time. I find that a lot of important features are not easy enough to reach and/or not intuitive enough (like Build options).

        I will try to find everything with the links you provided. Thanks for now Anastasia. I’ll be back if it’s not satisfying.

        • Anastasia Kazakova says:

          Check also our webhelp:, site and this blog for more details on features.

          • patlecat says:

            I tried many hours to get the remote debugging to work from Windows 10 to Vagrant-Ubuntu16.04. The documentation is very sparse to put it mildly!

            I managed to connect to it somehow but never got past this error message: “Architecture of file not recognized.”

            What I find confusing is that you don’t put all the compiler options into the Makefile.txt, that way I cannot simply define build targets once and then reuse them on Linux again. I had to define Debug manually to even use it.

          • Anastasia Kazakova says:

            > “Architecture of file not recognized.”
            Am I right that you’ve run the app under gdbserver at Vagrant-Ubuntu, and on Windows you are using the GDB for Linux, and set proper symbol file and path mappings in the Remote GDB configuration settings?

            Not sure I got your comment about compiler options. Could you maybe share some sample of what you mean here?

  11. patlecat says:

    Yes gdbserver runs in Vagrant which runs Ubuntu. All is 64 bit, Windows and Ubuntu. Under Windows I am using CLion with the included compiler and debugger.

    Compiler options like Release/Debug, Compiler Flags and such.

    • Anastasia Kazakova says:

      Could you please collect debugger logs as described here and share with us?

      Also, how did you built a debugger for this? Did you follow the instruction from our blog post?

  12. patlecat says:

    I used the standard debugger provided by CLion/JetBrains on Windows and the standard debugger/gdbserver on Ubuntu 16.04. Why would there be a need to compile them anew?

    • Anastasia Kazakova says:

      Since you are using a cross-platform debug, built-in Windows debugger from CLion doesn’t work. You need one targeting Linux. Check the instruction how to build it and point to it in the Remote GDB Configuration settings.

  13. vincent says:

    – I’m wondering how “Analyze Stacktrace” works.
    Can a demo video be recorded on that ?

    – Also this reference link is dead : “Analyze Stacktrace Dialog”

    – Finally, is there a way to dump a debugger session to file and reload it later to analyze the stacks / threads ?

    Thank you.

  14. Thien Hoang says:

    In 2016.1 I am able to view array’s elements just by simply typing the name in Watches window. And now in 2016.3, it only shows me the address of the variable. How can I fix this issue?

Leave a Reply

Your email address will not be published. Required fields are marked *