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

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:

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:

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.

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.

(*) 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.

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.

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)

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:

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.

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.

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?

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.

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 https://youtrack.jetbrains.com/issue/CPP-8454