text: 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:
  - C++ language support: user-defined literals, C++14 digit separator, overload resolution support, and dozens of code analysis improvements.
  - C language support: C11 keywords support including auto-completion.
  - Remote GDB debug on Windows platform.
  - New approach to CMake project model: allows you to select the generation directory, open a project from an existing generation folder, and more.
  - Automatic switching of resolve context per build/run configuration change.
  - Semantic highlighting in the editor.
  - For Unreal Engine developers: plugin for better completion for Unreal Engine 4 sources, 3rd party plugin for CMake generation, and performance improvements for project re-opening in CLion.
  - Doxygen tparam tag support.
  - Various VCS improvements.
  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.
  Doxygen
  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.
  VCS
  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:
  Your feedback is very welcome in the comments section below!
  Your CLion Team
  JetBrains
  The Drive to Develop
  Yay!!!
  And now I can’t wait for the roadmap for the next major release.
  PS.
  You might want to pin this above the 2016.3 EAP announcement.
  Done already (you were too quick 😉 ). Thanks!
  Congrats! Clion is now the best IDE for CMake projects! But I hope to have custom project (custom build-system) support in next release
  We’ll consider the option when planning upcoming versions. Thanks and stay tuned!
  Hey,
  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.
  Now it’s only possible via the settings page. But we are considering the improvements in this direction. Feel free to share your vision.
  I’d love to have it working similarly to QtCreator – multiple “kits” and multiple configurations within each with very easy (2-3 clicks) switching between them.
  At the moment I’m working with custom builds of clang and gcc. Switching the compiler and the build type is quite uncomfortable right now.
  Thanks. We’ll consider how to address your case in the upcoming updates.
  You can follow this for update:
  Please, check our new CLion 2016.3.2 Early Access Program build that includes an ability to add CMake configurations. Check our blog post for more details:. And let us know if the solution fits your workflow.
  Basically I see few ways to do it:
  (*) In any of this situation you probably can configure LIST of available configurations.
  1) Visual Studio like – One switch on the toolbar, that changes every run configuration to CLion
  pro – easy and understandable
  con – you can’t set
  2) All configurations are generated at the same time,
  Each configuration chosen in (*) may be chosen as configuration to run configuration (I mean where we could choose it in 2016.2).
  pro – maximal flexibility
  3) There’s one main configuration that is used by CLion (to run highlighting etc), but you can still choose configuration that will be used when running.
  BTW is there issue already or should I create one?
  Sure. This one:
  Please, check our new CLion 2016.3.2 Early Access Program build that includes an ability to add CMake configurations. Check our blog post for more details:. And let us know if the solution fits your workflow.
  Good to see the language support:)
  Hope it’ll be possible to start using most usefule features of c++17 such as structured bindings
  Feel free to upvote/add corresponding requests to so that we can prioritize.
  Well, I (as not a jetbrains-dev) can’t do that, but I’ll create some features soon
  Not sure, what’s the problem with it. Just add any feature you are interested in to the tracker. Thanks!
  Structured bindings
  Initializers in if and switch statements
  Nested namespaces
  The new attributes
  Initializers –
  nested namespaces –
  structured bindings –
  new attributes –
  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
  This could be the case, since CLion stores quite a lot of information about the project to provide smart actions and features. If the amount is constant and not growing, than that’s actually ok.
  I could be just fine with this, but it used to consume ~1,5Gb in overall (Windows Task manager), now it consumes ~2,5Gb (Windows Task manager). In the memory view in CLion amount of consumed memory didn’t change though. 1Gb of difference is seriously not a small amount of memory to consume, just because.
  Memory indicator inside CLion should provide correct values. But if you have concerns send memory snapshot to our support:
  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?
  Ok, I found the solution in cmake for this:
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
  set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
  Actually generation directory from CMake settings is one where CMake command is actually called.
  You can change the generation directory in CMake settings and set some global one for example. Will it help?
  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)?
  There is not option for now to configure CMake defaults. However, we’ll introduce it soon:
  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?
  Now you need to go to CMake settings and change it there: Settings | Build, Execution, Deployment | CMake
  Thanks for reply.
  That means that there’s no way to specify build type for different targets anymore, right?
  Not now, but looks like this is not suitable for some of our users, so we are gonna address it:.
  Please, check our new CLion 2016.3.2 Early Access Program build that includes an ability to add CMake configurations. Check our blog post for more details:. And let us know if the solution fits your workflow.
  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?
  You can change it in: File | Settings | Build, Execution, Deployment | CMake
  Thanks for the answer. It’s weird because it should be a per project setting. I can’t even come up with a reason why it’s implemented in that way.
  It is a per project setting.
  Can you add generator for Goggle Mocks like it has been made in Resharper C++?
  We’ll consider here, thanks:
  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
  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:,
  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.
  Sure.
  Check also our webhelp:, site and this blog for more details on features.
  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.
  > “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?
  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.
  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?
  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?
  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.
  Hi,
  – 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.
  Let me re-check and come back to you with more details.
  Thanks for pinging us about this feature. Seems it’s inherited from the platform, but doesn’t work properly for C++ code due to some reasons. We’ll investigate it and try to get the same functionality for C/C++ code under this
  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?
  Could you please share some code sample?