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:
- 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.
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!
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.
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.
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.
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
The Drive to Develop
Subscribe to Blog updates
Thanks, we've got you!