We hope you had a chance to try our previous EAP build with lots of changes in CMake workflow and improved overload resolution support. Today we are rolling out another EAP build, 163.7342.13. As usual, a patch update will be rolled out shortly for those using the previous EAP (163.6957.27).
In CLion 2016.2 remote GDB debug was implemented for Linux and macOS platforms. With this build it comes to Windows! The following cases are supported:
Debugging of Windows targets built with MinGW (or MinGW-w64) from Windows host with MinGW (or MinGW-w64) GDB.
Debugging of Windows targets built with Cygwin from Windows host with Cygwin GDB.
Debugging of Windows targets built with one toolchain (MinGW/MinGW-w64 or Cygwin) from Windows host with GDB from another one. In that case don’t forget to provide correct path mappings in the Remote GDB Debug configuration’s settings.
Start your application under gdbserver on remote host, connect there in CLion on Windows and use all the features of CLion’s built-in debugger.
Cross-platform debug (i.e. targets on Linux) requires GDB for Linux to be used from CLion on Windows. The easiest way for it is to build it on Linux with cross-compilation settings. Get the binutils-gdb sources on Linux from the Git repository, switch branch to gdb-7.11.1-release and build like this (here the in-source build is used):
sudo apt install mingw-w64
mkdir build-mingw-w64-x86_64
cd build-mingw-w64-x86_64
../configure --host=x86_64-w64-mingw32 --target=x86_64-linux-gnu --disable-gdbserver --prefix=$(pwd)/usr
make
make install
Copy the debugger (build-mingw-w64-x86_64/usr/bin/x86_64-linux-gnu-gdb.exe) to your Windows machine and select in the remote GDB configuration in CLion.
Renaming of user-defined literals
First 2016.3 EAP introduced user-defined literals support in CLion. With this EAP you are now able to use Rename refactoring on such literals:
Besides, Find Usages works now for overloaded operators (except for new and delete), like for example in this case:
Fixes in code analysis
We continue our work on cleaning up the false-positive code analysis along with incorrect quick-fixes in CLion. This EAP build includes another set of fixes. The most important one relates to simplify quick-fix, that previously produced incorrect code for overloaded operators (CPP-2100).
Other fixes cover incorrect Reference may be null case (when one-element initializer list is used) and bogus loop variable is not updated inside the loop warnings.
CMake reload optimizations
CMake project reload can be time-consuming, that’s why we’ve worked on the conditions in which the reload happens to be sure it’s not called when not necessary. Now CLion doesn’t reload project on opening, if nothing changed. Changes that do lead to reload are environment changes, CMake project settings changes and dependent files changes.
If you develop in plain C, you’ll be glad to know that CLion now supports gcc atomic builtins, thus no false-positives are shown in the editor in that case.
We appreciate your feedback and comments, and if you find any bug at all, please file an issue in our tracker. Note, that this build doesn’t require an active subscription.
We appreciate your feedback and comments, and if you find any bug at all, please file an issue in our tracker. Please also note that to use CLion 2016.3 RC2 you need to have an active subscription (or start a 30-day evaluation period).
Tracking down bugs is one of the most time-consuming parts of a developer’s job. To help users of CLion, Undo has partnered with JetBrains to bring its next generation debugging technology to the IDE.
In this webinar we will look at how CLion makes debugging easier out of the box – then see how Undo’s award-winning reversible debugging technology allows developers to step backwards as well as forwards inside their program to find the root cause of a failure.
You can learn more about Undo’s integration with CLion on our joint blog post.
Here are some of the things we will take a look at:
Fundamental CLion debugging topics
Getting orientated with debugging in CLion
Stepping, viewing and watching variables and expressions
Breakpoints, conditions, dependent breakpoints and logging
Reversible Debugging in CLion with Undo
Reversible debugging: why every developer should do it
Reverse breakpoints and watchpoints: run back to the last time your program executed a specified line of code or run back to a watchpoint to discover when a variable was last changed
Jump to any point in your program’s history and debug from that point onwards (either forwards or backwards!)
Advanced CLion debugging topics
Attach to process
Remote debugging
About the presenters:
Phil Nash is a Developer Advocate for C++, Objective-C and Swift tools at JetBrains. Prior to that he worked in as diverse fields as finance, agile coaching and iOS development. A long time C++ developer he also has his feet in C#, F#, Objective-C and Swift – as well as dabbling in other languages. He is the author of several open source projects – most notably Catch: a C++-native test framework.
Isa Smith is a Software Engineer at Undo. Her technical interests revolve around creating great development tools. Her favourite programming language is C, for its closeness to the machine. She likes to tackle problems from the bottom up, and has an extensive knowledge of the ARM (and ARM 64-bit) architectures and a good knowledge of the x86-64 instruction set.
At Undo she is responsible (among other things) for performance and optimisation of the Undo tools. She holds a BSc in Computer Science and Mathematics from the University of York.
Greg Law is the co-founder and CEO of Undo. He is a coder at heart, but likes to bridge the gap between the business and software worlds. Greg has 20 years’ experience in the software industry and has held development and management roles at companies including the pioneering British computer firm Acorn, as well as fast-growing start ups, NexWave and Solarflare. It was at Acorn that Greg met his co-founder, Julian Smith, and on evenings and weekends, they invented the core technology that eventually became UndoDB. Greg left Solarflare in 2012 to lead Undo as CEO and has overseen the company as it transitioned from the shed in his back garden to a scalable award-winning business.
We appreciate your feedback and comments, and if you find any bug at all, please file an issue in our tracker. Please also note that to use CLion 2016.3 RC3 you need to have an active subscription (or start a 30-day evaluation period).
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.
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.
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:
Allow configuring defaults for the CMake settings (CPP-1887).
Find existing generation folder and suggest to use it when opening CMake projects (CPP-7943).
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:
Just recently we’ve released CLion 2016.3. It brings dozens of C and C++ language improvements (including user-defined literals (C++11) and digit separator (C++14) support, as well as C11 keywords completion), remote debug on Windows platform, CMake changes, semantic highlighting and much more.
Special thanks
Now we’d like first to thank our evaluators! Your help in making this release stable and feature-rich is greatly appreciated. And as usual, we’d like to reward several contributors whose input was most valuable during this release cycle:
Alexey Klimkin (YouTrack handle: klimkin)
Robert Hölzl (YouTrack handle: mrh1997)
Roger Dubbs (YouTrack handle: rogerdubbs)
Anon Anonchik (YouTrack handle: aanonchik)
You’ll get a free 1-year subscription for CLion (to extend your current subscription or get a new one). A personal message will be sent to each of you guys with details on how to obtain your license. (And just in case you do not get any email from us within a week, ping us here in the comments.)
Further plans: 2017.1 and not only
The new release is not the end of the road, but just another step. It’s time to move forward.
Note: The following is a preliminary plan; we cannot guarantee that all of the features listed below will be included in CLion 2017.1.
Analyzing the feedback we’ve got on CLion 2016.3, we think we need to first concentrate on CMake workflow updates. The following changes are planned and might be (if possible) back-ported to 2016.3.x updates:
Exclude CMake generation directory from version control and find usages (CPP-4300).
Add ability to change CMake defaults (CPP-1887). The most popular case here is to have a default generation directory configured for all user projects.
Bring back the ability to add additional CMake configurations (CPP-3159). Right now it’s only possible to switch them in Settings | Build, Execution, Deployment | CMake. However, we consider making a UI to add any number of configurations to a project. In addition, a switcher to exclude the configuration from indexing could probably be useful for configurations that are not used for code editing.
The new year should bring even more exciting changes to CLion, including but not limited to:
Language support:
More C++14 coming to CLion. You can check what’s left on this new webhelp page.
Initial support of C++17. As the new standard is coming, we will already accommodate some of its features in CLion 2017.1: nested namespaces (CPP-3623) and initializers in if and switch statements (CPP-8234) will likely be among the first.
Indexing and resolve:
GCC 6 support that requires proper handling of #include_next in CLion (CPP-3821).
Support for precompile headers and -include (CPP-53).
Code analysis:
The plan here is to add more of the so-called modernize C++14 intentions, which could help make your code modern and nice. We are going to take a look at what’s available in clang-tidy tool. All your ideas are kindly welcome under this ticket.
Refactorings:
The main goal is to make refactorings in CLion more reliable and accurate. For this iteration we plan to focus on a couple of particular actions, most likely Extract Variable and Inline, and fix many issues around them. If you experience any, don’t hesitate to share with us in our tracker (CPP-1247, OC-9791).
Toolchains: Microsoft compiler support
Yes, we are finally going to introduce MSVC support in CLion. This will include:
Ability to use MSVC to compile your project in CLion.
Support for NMake generator in CMake.
Specific language extensions.
Debugger:
We were planning to add a debugger assembly view in 2016.3, but didn’t manage to get it in. This work is ongoing and the view will be introduced in 2017.1.
Today we are starting an Early Access Preview for CLion 2016.3.1, a bug-fix update to the recently released major CLion update. Build 163.9166.5 is now available.
You can download the build and install side by side with the stable version of CLion. Please, note that this EAP build requires an active subscription (or you can start a 30-day evaluation period).
Some notable improvements you can find in this build are listed below.
User-defined literals rename
CLion 2016.3 introduceduser-defined literals support along with an ability to rename such literals. However, it was not possible inside namespaces (CPP-8102). Now the case is fixed and everything works as expected.
Ellipsis in Doxygen
Ellipsis is now supported in Doxygen documentation comments, which includes:
Correct resolve and highlighting.
Quick-documentation preview.
Completion in parameter’s tag.
Doxygen stub generation (including param and tparam tags generation).
CMake
Several CMake workflow updates are still planned and are under development, however a few fixes are already included into this build:
When opening a project from an existing in-source generation directory, this directory is set as a generation path in CMake settings in CLion.
Fix for a bug with quotes erased by error in CMake options editor (CPP-8017).
Improved CMake reload behaviour by not reloading in situations when, for example, only whitespaces were changed or comments were updated.
Looks like CMake itself has a problem with reseting CMAKE_BUILD_TYPE when compiler changed. We’ve just implemented a workaround in CLion, that detects that CMake cleared cache after compiler change and triggers second generation to make sure other CMake settings are applied.
This workaround can be disabled by cidr.cmake.cacheResetFix=false in the Registry (in Find Action dialog (Shift+Ctrl+A on Linux/Windows, ⇧⌘A on OS X) type Registry).
Other fixes
This build brings a fix for invalid inaccessible code warning appeared when dynamic_cast is used (CPP-6403). As well as more accurate Simplify quick-fix (CPP-7750):
The recording of our December 6th webinar with Phil Nash, Isa Smith and Greg Law, Debugging C/C++ applications on Linux in CLion, from basics to reverse debug, is now available on JetBrainsTV YouTube channel.
In this webinar we look at how CLion makes debugging easier out of the box – then see how Undo’s award-winning reversible debugging technology allows developers to step backwards as well as forwards inside their program to find the root cause of a failure.
The video includes the time stamps following the agenda announced: 0:44 – Fundamental CLion debugging topics 1:24 – Getting orientated with debugging in CLion 4:20 – Stepping, viewing and watching variables and expressions 8:21 – Breakpoints, conditions, dependent breakpoints and logging 14:57 – Reversible Debugging in CLion with Undo, intro from Greg Law 21:50 – Undo demo 33:35 – Advanced CLion debugging topics: attach to local process 36:16 – Advanced CLion debugging topics: remote GDB debug
Below are some questions from our webinar answered by Phil, Isa and Anastasia.
Questions on CLion
Q: Is Python or JavaScript used in this sample application?
Phil: It’s not, but the breakpoint list shows Python and JavaScript breakpoints since Python plugin and JavaScript support are bundled into CLion by default, so these breakpoints types are available as well.
Q: Can you define a custom way of printing variables in the locals window? As a C developer I often want to correlate a pointer with a counter for listing a dynamic array.
Anastasia: You can use custom pretty printers via .gdbinit/.lldbinit.
Q: Any chance that the setup workflow for remote debug will be automated in a future version? Something like the Docker workflow in PyCharm?
Anastasia: Thanks for the idea. We’ll consider for the future. However use cases are rather different, so suggestions are welcome in the tracker.
Questions on Undo
Q: Is it possible to jump to a specific stack frame?
Isa: You can move up and down the stack one frame using ‘Step Out’ and ‘Reverse Step Out’.
You can view the state of a particular frame by clicking on it as normal, but this doesn’t properly move the state. You can move the state by setting a breakpoint in code having clicked the stack frame and using ‘Reverse Resume’ to run back to it.
Moving the program state to a particular stack frame without using breakpoints is an extra feature we could consider.
Q: Is the recorder always enabled during a debugging session?
Isa: You can delay, or ‘defer’ recording until some time into your program, for example if you have an IO heavy startup which is slow to record, and you don’t want to debug it. This isn’t yet supported directly from CLion: you will need to add --undodb-defer-recording to the undodb-gdb invocation and then urecord in the gdb pane to start recording.
Q: Does it freeze one thread or the whole state?
Isa: The whole state.
Q: Does it also support cross-compile?
Isa: Yes, Undo technology supports ARM and x86, and you can debug a remote ARM process from an x86 machine.
Q: Does it require extra memory to run Undo?
Isa: The memory requirements depend on your application. Applications that are heavy on IO, shared memory usage, signals… these will use more memory than CPU-bound applications. We are always working to improve performance and memory usage.
Q: I didn’t see support for amd64 on the Undo webpage – is this supported?
Isa: Yes.
Q: What if the issue is reproduced only once a day. Can we still record our session with undo?
Isa: Yes — this is what Undo is best for. If your program needs to run for a day, then it will take longer to run in Undo. However you only need to capture the problem happening once. Once you have captured it, you can save the state to a recording and share it with colleagues, and reproduce on any machine. To learn more about recording, and our Live Recorder products, please have a look at our website or contact us.
For long sessions we recommend setting a circular event log. This will keep the memory usage to a specified amount, at the cost of losing history from the start of your program.
Q: What about program that runs for many hours? Is there a limit to how much you can record?
Isa: By default we will record everything and keep growing our event log up to 256MB. You can increase (or reduce) the size of the event log, and for very long runs we suggest that you use a circular event log. This will overwrite old history with new history, so you should still have enough context to debug your problem, without having large demands on memory.
Q: What is cost of this plugin?
Isa: Please contact us for pricing and we can give you a quote depending on whether you want node-locked, floating or Live Recorder licenses (sales@undo.io).
Thanks to all the attendees for the questions!
About the presenters:
Phil Nash is a Developer Advocate for C++, Objective-C and Swift tools at JetBrains. Prior to that he worked in as diverse fields as finance, agile coaching and iOS development. A long time C++ developer he also has his feet in C#, F#, Objective-C and Swift – as well as dabbling in other languages. He is the author of several open source projects – most notably Catch: a C++-native test framework.
Isa Smith is a Software Engineer at Undo. Her technical interests revolve around creating great development tools. Her favourite programming language is C, for its closeness to the machine. She likes to tackle problems from the bottom up, and has an extensive knowledge of the ARM (and ARM 64-bit) architectures and a good knowledge of the x86-64 instruction set.
At Undo she is responsible (among other things) for performance and optimisation of the Undo tools. She holds a BSc in Computer Science and Mathematics from the University of York.
Greg Law is the co-founder and CEO of Undo. He is a coder at heart, but likes to bridge the gap between the business and software worlds. Greg has 20 years’ experience in the software industry and has held development and management roles at companies including the pioneering British computer firm Acorn, as well as fast-growing start ups, NexWave and Solarflare. It was at Acorn that Greg met his co-founder, Julian Smith, and on evenings and weekends, they invented the core technology that eventually became UndoDB. Greg left Solarflare in 2012 to lead Undo as CEO and has overseen the company as it transitioned from the shed in his back garden to a scalable award-winning business.
CLion 2016.3.1 bug fix update to the recently released major CLion update is just around the corner and most likely will come next week. And today we are rolling out the 2016.3.1 Release Candidate (build 163.9166.25) with the final fixes.
In addition to UDL rename fix, support for ellipsis in Doxygen and other improvements introduced in 2016.3.1 EAP, this build addresses:
Problem with sysroot setting in Remote GDB Debug (the path was mistakenly double quoted and thus not working as expected).
As you may notice, GDB on macOS Sierra doesn’t work for now. While the patch addressing GDB issues on Sierra has been accepted in the mainline, we’ve added a proper notification to CLion, that suggests to switch to LLDB:
CLion’s approach to CMake has changed in v2016.3. CLion stopped building all 4 CMake configurations by default, letting you select which ones you need. While this reduces memory usage, as well as the time required for CMake reload, there was some inconvenience that our users reported in blog post comments, the tracker and other social channels.
After considering all the use cases carefully, we’ve come up with a UI that allows you to create additional CMake configurations (as many as you need):
Go to Settings/Preferences | Build, Execution, Deployment | CMake and create any number of CMake configurations from scratch, or copy existing ones (with all the settings pre-filled). When done, additional resolve context will be available in the bottom right-hand switcher in the editor:
By the way, in case you have custom configurations created by the setting CMAKE_CONFIGURATION_TYPES, they will appear in the settings’ drop-down as well.
In the Run/Debug configuration settings dialog, you can switch between available CMake configurations:
If you used to switch between Release/Debug (or other configurations) during development, now you can create all the necessary CMake configurations and corresponding Run/Debug configurations (as necessary), and switch between them with ease.
Please, note, projects with multiple CMake configurations added in 2016.3.2 EAP might not work properly in v2016.3, but work ok in 2016.3.1 bug-fix update.
Exclude generated folders
CLion 2016.3 allows changing the CMake generation folder path. Among other benefits, it brings the ability to generate in-source. However, this folder was not excluded from the project in CLion, which would cause usability issues. Now in the CLion 2016.3.2 EAP build, the directories are excluded, which means that:
Find in path and other searches do not go through the files in these folders; and
These folders are excluded from VCS.
CMake output console
CMake output console has been updated to support error highlighting, links to corresponding CMake files, and navigation to next/prev errors:
Besides, CMake 3.6.3 was bundled into this EAP build.
Project templates
If you plan to start a project from scratch, we’ve got good news for you! Project templates finally have made their way to CLion. There are several options available in the dialog:
Select either a C++ project or a pure C project.
Select executable or library.
Select language standard and library type.
After you click Create, CLion will generate the sample project for you and pre-fill root CMakeLists.txt with the necessary information:
Project templates for Swift will also join a bit later (CPP-6155), as will compiler and additional libraries settings in the dialog (CPP-7919). Feel free to share your ideas in the corresponding tickets.
GCC6 support
This build fixes the problem with correct recognition of <cstdlib> (in case of GCC6) (CPP-7573). This work also covers most of the issues with #include_next (CPP-3821), and thus we are glad to announce that GCC6 can now be successfully used in CLion. If you still experience any issues, please, let us know.
If you’re using CLion 2016.3, a patch-update should be available. If you’re using an earlier version, give CLion 2016.3 and its new features a try and download it for a free 30 day evaluation.
CLion 2016.3.2 (build 163.10154.43), the second bug-fix update for the recently released major version is now available! If you still haven’t got a chance to try v2016.3, check our website for What’s new and download the build.
These months were full of great conferences – CppCon, ADC (former JUCE), LLVM US Meetup, Meeting C++, and some more local group meetups and smaller conferences. They are over now, but playlists with talk recordings are available for those who missed an event or just want to dive into it once again.
CppCon
First came CppCon 2016. The biggest event in the C++ world brought us 7,653 minutes of video recorded this year for 111 presentations and 31 lightning talks: from philosophical keynotes by Bjarne Stroustrup titled The Evolution of C++ Past, Present and Future to the state of C++ Core Guidelines in Neil MacIntosh’s The Guideline Support Library: One Year Later and many more. Also, don’t miss great advice from Jon Kalb: “Don’t use unsigned for quantities” from his lightning talk, unsigned: A Guideline for Better Code.
ADC
ADC (former JUCE) conference gathered Audio Developers from all over the world, and brought to light lots of topics around C++ modern language features, performance optimization and embedded development. Keynotes varied from the fantastic Dan Saks speaking about modern C++ instead of pure C in embedded development, to the legendary Roger Linn with his LinnStrument on stage playing demos.
LLVM US Meetup
The yearly LLVM US Developers meetup took place in early November in California. Among the recordings from the event one can find a highly interesting talk by Gor Nishanov about LLVM Coroutines, the story of LLVM and Clang transition to CMake by Chris Bieneman, and many more. The JetBrains C++ team also joined the event with a small lightning talk by Ilya Biryukov on how the compiler frontend is different from what an IDE needs, trying to explain why our C++ tools do not rely on Clang as a code parser.
Meeting C++
Meeting C++, the key European C++ event, was as usual held at the Andels hotel in Berlin this past November. The organizers brought together many famous names from the C++ community, including Bjarne Stroustrup, James McNellis, Timur Doumler, Jon Kalb, Michael Caisse, Arne Mertz, Odin Holmes, and many others, and offered an impressive program. Besides, it’s worth mentioning a quiz from Diego Rodriguez-Losada, the author of Conan. Interested in challenging yourself? Check 10 tricky code snippets from Meeting C++ in the Conan blog.
User Groups
The extensive worldwide collection of C++ focused user groups continues to grow, with at least two new groups starting up this quarter.
In Russia, the St. Petersburg C++ User Group started in October and has been meeting monthly since. Meanwhile, in the UK, C++::London started in December and also plans to continue monthly, with the January meet-up already scheduled. Both groups have been well attended, so if you’re in or near either of those cities do join up.
Both Meeting C++ and ISOCpp maintain up-to-date lists of C++ meetup groups worldwide, so consult those pages to find something near you.
News
Catching bugs at compile time
Andrzej’s C++ blog introduced a couple of blog posts on catching this non-obvious bug at compile time. The sample is simple and was generated by selecting an inappropriate completion suggestion. Still the discussion is interesting as an overview of possible workarounds in order to catch such issues with the help of the compiler. The author tried invoking a memory access violation (by providing another String implementation that assumes it will never be given a Null pointer), then comes to __builtin_unreachable()– and preconditions-based implementation samples. Another solution discussed in the blog is const usages.
Understanding fold expressions
Reducing a parameter pack over a binary operator with the fold expression is a new ability provided by the upcoming C++17. In his blog, Sumant Tambe tries unary left fold for operators and shows some interesting observations from his test, which shows some differences in how Clang and GCC handle the feature. There is also a valuable discussion of corner cases (like empty or single parameter packs).
Modern C++ features with Arne Mertz
The Simplify C++ blog by Arne Mertz was as usual full of interesting posts on various topics. Two attract the most attention: first, a general introduction to user-defined literals, with samples and use case description, and string literals (C++14) case in the very end.
Second, a series about variadic templates, providing full instruction on how to build and expand the parameter pack in templates. Empty packs, sizeof… operator and some additional tricks were also discussed.
42.times do
If you want to write something similar to “42.times do …” in C++, the answer by Dmitry Ledentsov is user-defined literals. Jon Kalb, however, attempted to play with it with more traditional syntax, so if you are not afraid of SFINAE, variadic templates, perfect forwarding, etc., check his blog post. The core idea among others is to make the code general, working for functions, function pointers, function objects and lambdas, with arbitrary values to be used as parameters to the callable.
Error handling strategy
Jonathan Müller in his foonathan::blog() published of series of posts on error handling. He discusses user errors, system errors and programming errors, checking whether it’s worth using recoverable or unrecoverable error handling strategy in each of the cases. The series also includes tips on customizable and modular assert implementations, as well as a discussion of C++ type system flexibility.
Next generation Doxygen for C++
Doxygen is a well-known format (de facto standard in many cases) for generating documentation from the annotated sources in various programming languages, including C++. Standardese (by Jonathan Müller) is a new library and a tool for getting documentation for C++ code. Its main goal is to fit C++ code bases more accurately, formatting the docs in a similar way to the standards themselves. It also aims to handle C++ language features in a smarter way (like SFINAE), provide balanced type information (not overwhelmed with various aliases and unnecessary return types), document private members, and more.
The Internet of Things, embedded development, and the future of C++
Qt blog published a research article looking into potential IoT market growth. Some interesting trends are mentioned. The number of connected devices is estimated to reach 20.7 billion by 2020, and 95% of today’s embedded systems are created with C/C++. Given that the number of C++ developers is growing at a very modest pace, how do we produce the software for that many devices? One of the answers suggested by the article is to enable C++ developers to be more productive. What better area for tools to make a difference! Check the blog post for the details.
Phil Nash & C++ team in JetBrains
In September Phil Nash, a well-known speaker and an author of the Catch framework, signed up as a Developer Advocate for C++ tools at JetBrains (also covering Objective-C and Swift). In his interview he shares his story and provides his vision on his duties as a developer advocate. There is also another episode of CppCast with Phil, focusing on his role in the community, Catch 2 and recent releases of JetBrains C++ tools.
Functional C++ for Fun and Profit
Phil Nash has a small tour with his “Functional C++ for Fun and Profit” in November and December, which includes many European User Groups meetups and the Meeting C++ conference. If you missed the discussion of the functional approach to software design and how it applies to modern C++, catch up with the recording.
Online compilers and not only
Jens Wellers overviewed the web resources that allow you to compile a piece of C++ code right in the browser and are collaborative in the sense that multiple people are able to edit the code interactively. It turned out to be a useful list, with not so many options supporting the latest C++ standard.
There is also a nice resource providing a long list of basic C++ code samples. Each code sample comes with a description and a comment section for discussion and questions.
CMake reference by LLVM
LLVM 3.9 dropped the autoconf build system in favor of CMake. To make the life of LLVM contributors a bit easier and clearer, the rich document on CMake was introduced. Not being a full tutorial or every feature reference, but more like a general introduction to the basic commands, principles and solutions used across the LLVM project, it can be helpful to both LLVM contributors and those who are starting to learn CMake.
CMake support in Visual Studio
Visual Studio 2017 will be delivered with two new options for those who are not using Visual Studio projects – open project from folder and CMake support. If you are planning to start/open a CMake project in VS, check their blog post, in which Marian Luparu gives a quick overview of the CMake features in Visual Studio. It includes opening CMake-based projects and working with them to benefit from all the intelligent features VS provides as an IDE. It also provides an ability to edit CMake files, update CMake Cache and tune CMake configurations. And of course, users can build and debug such solutions in Visual Studio 2017.
Shuffling data
Understanding the performance and drawbacks of standard functions is essential in order to use them effectively. Daniel Lemire in his blog post runs a comparison of the standard function for date shuffling (std::shuffle) and the standard Fisher-Yates shuffle algorithm. Check the blog post to see who won!
Is code faster than data?
Another performance test was run to check whether custom code for compile time data structure lookup functionality was faster than data. To be exact, the author compared the performance of the switch statement to that of a simple array type. The test was compiled within Visual Studio 2015 for 6 various data containers, running sequential, shuffle and sparse sums. The switch function turned out to be much, much slower than other options! Read the blog post for an explanation of the results.
Can a C++ package manager be written in C++?
Conan blog starts a discussion, sharing arguments for Python (for both UI language for packages definition and package manager core), and some philosophical fallacy around C++ package manager written in C++. Do you agree? Or do you think it’s more practical to use the same language (i.e. C++) than a completely new Python toolset?
Releases
CLion 2016.3
CLion 2016.3, another major update of JetBrains’ cross-platform IDE for C and C++ development, brought lots of key improvements. User-defined literals are supported including Rename refactoring, C++14 digit separator support, C11 keywords completion, and overload resolution improvements. Code analysis fixes from the language side include: ability to change CMake generation directory, ability to build only those CMake configurations that were added in settings, ability to open project from existing directory, and more. From the project model side code analysis fixes include project templates, remote debug on Windows, semantic highlighting, and more.
ReSharper C++ 2016.3
The ReSharper family received an update too, including ReSharper C++ 2016.3. With new refactorings (Introduce/Inline Typedef) to clean-up code, postfix completion to speed up code typing, Catch test framework support and dozens of smaller improvements, this Visual Studio extension is even more powerful and user-friendly.
Qt Creator 4.2
Qt Creator 4.2 was released with improved CMake support, cleaned projects mode UI, an ability to get local diff, an option to exclude files from indexing, and Clang code models enhancements.
PVS-Studio for Linux
PVS-Studio analyzer was released for Linux. To prove it was worth the effort, they put the most famous projects under investigation and re-checked the Linux kernel. This helped catch issues with string operations having the wrong string length, incorrect order of arguments, precedence problems, and others.
Today we are glad to announce that the first CLion 2017.1 EAP build (171.2613.3) is available for download.
You can install it side by side with your current stable CLion version, no active subscription required.
Using auto type for variable declarations is a powerful feature of modern C++ that makes the code less verbose and thus more readable. It also obliges you to initialize the variable. Herb Sutter once wrote an interesting article in his blog on AAA (Almost Always Auto) style, where he tried to analyze when the use of auto is justified and when it’s not. As we do support many ideas shared there and we’d like to help CLion users to modernize their C++ code, we’ve introduced this new intention action which converts variable type to auto:
While this is still a work in progress, we will also consider the opposite action – replacing auto with an appropriate variable type (CPP-8555).
This EAP also includes support for the auto return type (CPP-4321), which means more accurate code analysis, correct type inferred and shown in the Quick Documentation pop-up and code completion:
Quick Documentation
Quick Documentation pop-up (Ctrl+Q on Linux/Windows, F1 on macOS) combines lots of information about the code entity under the caret. For macros, it shows information about macro replacement, as well as macro substitution. For variables, it includes type information, even providing you with an inferred type for variables declared as auto. It shows signatures for functions, along with links to the referenced types, and much more, even including Doxygen-styled documentation preview and code comments.
In this build we’ve worked on polishing the Quick Documentation pop-up:
When comments are placed inside the code, Quick Documentation now includes both: type information and the comment
If the code entity under the caret doesn’t have any documentation comment, but the parent entity does, then Quick Documentation will show the parent documentation:
Project model
Project model is becoming more user-friendly with a couple of useful fixes:
Renaming a project no longer breaks existing run configurations
Obsolete not-modified run configurations, and run configurations for deleted targets, are now removed automatically
For existing CMake projects, the project name in CLion is taken from CMake’s PROJECT_NAME on first opening
Besides, when opening a project in CLion for the first time, an executable run configuration is pre-selected now. Previously, it was a Build All configuration which may miss an executable to run and thus confuse users.
VCS Log Viewer
An updated VCS Log Viewer provides you with a few new options to tune search over commit messages there:
You can use regex
You can choose whether to make the search case sensitive
Zero latency typing
While you type in the editor, the IDE is always doing lots of things in the background to provide you smart features on the fly, like completion, code analysis, formatting, etc. Wouldn’t it be great if typing performance weren’t visually affected by this fact? Ideally it should be comparable to that provided by a simple, code-agnostic text editor.
Some time ago Pavel Fatin, a developer at JetBrains, researched editor latency. Based on his findings, he implemented an experimental feature for IntelliJ IDEA (and the whole IntelliJ Platform) called zero latency typing. In a nutshell, his solution reduces the number of editor repaintings and performs them in a smarter way. The results are impressive:
So today, after almost 6 months of extensive testing, we are enabling zero latency typing as the default setting in all IntelliJ-based IDEs, including CLion.
Dvorak layout support and more
If you’re more used to Dvorak layout in macOS than QWERTY, you’ll be glad to know that keyboards shortcuts like ⌘/, ⇧⌘], ⇧⌘[, ⌘+ and others are now working properly with it (JRE-172).
Besides, this EAP addresses an issue with Korean, Chinese and Japanese keyboard layouts on macOS.
Code analysis fixes and other improvements
There are more bug fixes and enhancements introduced in this EAP build:
Incorrect Call to pow is ambiguous warning for GCC 6.2 was removed (CPP-8543)
Incorrect Too few template arguments warning was fixed (CPP-7150)
CLion now doesn’t suggest to reduce TRUE macro to ‘true’ for pure C code
CLion now doesn’t suggest to make static or friend functions pure virtual
Hidden functions from the base class are no longer suggested in the completion
Settings Repository plugin is finally bundled into CLion
Swift plugin: SourceKit inspections and intentions
Note that since the full support for reading Swift modules on Linux is not available yet, there could be issues with SourceKit integration in projects with complex dependencies. If you experience such problems, please report them in a sub ticket here.
Besides, we’ve added a New Project template for Swift, that allows you creating a new Swift project with ease (minimal working context is created automatically by CLion).
NB: We are very much looking forward to your feedback in order to help us create a tool that you will enjoy using on everyday basis. So if you do use CLion as a Swift IDE on Linux, let us know about your use case, your needs and your experience with CLion.
That’s about it. The full release notes are available here.
Stay tuned and don’t miss more exciting features and valuable fixes coming soon.
Last week CLion 2017.1 Early Access Program started with a new make auto intention, auto return type support, zero latency typing mode and many important improvements. This week a new EAP build (172.2822.8) is available. In case you use the previous EAP build, you should get a notification in the IDE about a patch update shortly.
Modern C++ standards support is one of our top-priority task for this year. We keep working on C++14, and while first EAP brought auto return type support, this build comes with the generic lambdas support. This includes correct type inference and corresponding code analysis checks:
More C++14 features are coming to CLion in the next EAP builds. You can check what’s left in our webhelp.
Decltype cases
This EAP also addresses several cases with decltype when the code was not resolved correctly:
CLion 2017.1 EAP builds were mainly focused on C++14 features support and various code analysis improvements, as well as zero latency typing mode (that seems to improve the editor performance in many cases). Today we are happy to announce new EAP build, 171.3019.8.
C++14: Variable templates and generalized lambda captures
We are moving forward with C++14 support in CLion and today we are glad to announce that variable templates (CPP-6419) and generalized lambda captures (CPP-4545) are now supported in CLion. That means that the only thing left from C++14 is constexpr.
Precompiled headers and -include support
To reduce compilation time and keep the code well-structured, especially on a large-scale code bases, precompiled headers and -include compiler option can be used. They guide the compiler to reuse the information about expensive includes (like many header files included everywhere).
In this case the IDE has to understand where to locate the precompiled headers and headers included via -include option, in order to correctly resolve symbols from such files and provide correct code highlighting, code generation and navigation, refactorings, etc.
The work on this feature in CLion has started in this EAP build:
Current limitations
Note, there are still some limitations while using precompiled headers and -include compiler option in CLion:
In case of GCC, CLion only resolves the symbols from the usual header files passed via -include option. Symbols from the precompiled headers won’t be resolved correctly now due to technical difficulties (CPP-8729). For Clang both options work.
Some performance degradation (~30%) is possible during the first project opening and initial indexing, so the work on the feature will continue in the upcoming EAP builds.
Other fixes
This build also addresses a problem with TArray widely used in Unreal Engine 4 projects – no more incorrect ‘not a valid range type’ warning there.
New CLion 2017.1 Early Access Program build (171.3224.8) is now available for download. You will get a notification about a patch-update in case you are using previous EAP build (171.3019.8).
A problem with debugger not starting if the main shell is csh/tcsh (CPP-2919, CPP-8737, CPP-2328) was addressed in this build.
Project model and CMake
This build brings fixes for incorrect handling of the escaped symbols. These problems mostly affected MinGW users and led to CMake command run failures on the correct projects, unrecognized include_directories and more (CPP-3962, CPP-8726, CPP-8727). Huge overhaul was performed there and now seems all the problem are gone. Feel free to report an issue in case you find anything!
While we are working hard on improving the CLion’s code parser, there are still cases which confuses CLion. For example, some preprocessor macros. We do encourage you all to report such cases to our tracker. However, in the meantime, find a workaround for such situations – special preprocessor macros to eliminate problematic definitions and to use some dummy definitions instead.
Find the following macros available now:
General macros: __JETBRAINS_IDE__
Per-ide variable: in CLion it’s __CLION_IDE__ , in AppCode – __APPCODE_IDE__ , in Android Studio – __STUDIO_IDE__
The values correspond to the current IDE’s version, for example:
#define __JETBRAINS__IDE__ 20170100L // for 2017.1
#define __JETBRAINS__IDE__ 20170101L // for 2017.1.1
The macros are undefined when you build/run your code, of course. They only affect the way your IDE parses the code.
Note, these macros are not available in completion for now (CPP-50) and their values are not shown in Quick Documentation (CPP-8576).
By the way, if you are looking for a way to check if the CMake script is called from CLion, there is an environment variable for this – CLION_IDE. Read more.
CLion 2016.3.3 bug-fix update (build 163.13906.4) is now available. You can download it from our website or install an update from the IDE if you’re using CLion 2016.3.2.
This build mostly addresses problems with debugger:
A new CLion 2017.1 EAP (build 171.3566.4) is now available for download. You will get a notification about a patch-update in case you are using the previous EAP build (171.3224.8).
This build includes a lot of preliminary work for the upcoming big changes: disassembly view for debugger and Microsoft C++ compiler support. While these features are not quite ready yet, this EAP build introduces important changes. Your help at this stage is highly appreciated, so please check the build and submit any issue to our tracker.
Starting with this build, CLion’s editor can highlight code written in assembly language:
The files are detected by the .s and .asm extensions (configured for you in Settings | Editor | File Types | Assembly Language). This works with a few limitations, however:
Only AT&T dialect is supported
Assembler with preprocessor is not supported
This work is the first step towards a disassembly view in debugger, which is going to come shortly to CLion EAPs.
MSVC support
Before we go through the changes, here are the two main reasons to introduce MSVC support in CLion:
MinGW and Cygwin are often difficult to use and configure
Cross-platform projects often use MSVC under Windows as a compiler
Saying this, we’d like to emphasize that our goal is not to provide support for VS projects, but to make it possible to use MSVC with CMake in CLion.
What is supported
Since MSVC support is still experimental, it’s not enabled by default. To turn it on, go to Help | Edit Custom VM Options… and enter: -Dclion.enable.msvc=true. Then restart CLion:
If you have Visual Studio 2015 or Visual Studio 2017 installed, you can now configure CLion to use MSVC compiler:
In Settings | Build, Execution, Deployment | Toolchains, select ‘Visual Studio home’:
In Settings | Build, Execution, Deployment | CMake, configure the architecture (x86, amd64, x86_arm, amd64_arm, etc.), platform (empty by default, store or uwp) and version (empty by default or Windows SDK name). Under the hood, CLion calls the script to configure the environment to build the project for the selected architecture and passes these parameters to it.
Now you can build your project with MSVC. Note that CLion will run CMake with the NMake generator in this case.
What is not yet there
There are still some things that are under development for now. We hope to finish them before releasing CLion 2017.1, but if not, development will continue for the 2017.2 EAP.
Auto-detect MSVC installed on user’s machine
C++ language standard is not detected by the IDE
PCH support (works in CLion 2017.1 EAP for non-MSVC cases)
There is a known issue with encodings and localized output
Easier navigation through compiler errors (CPP-7158)
The following will definitely not come to 2017.1, but will be worked on for the 2017.2 EAP:
Specific Microsoft C++ language extensions (CPP-8675)
Note that the debugger is currently not in the roadmap (CPP-8677). We are still considering the possible workarounds, but haven’t reached a decision at this point.
Find in Path popup
Find in Path lets you run a text search across the whole project or any selected scope. Now, you can get it in a popup window instead of the usual modal dialog:
That’s it! The full release notes are available here.
Phil Nash is a Developer Advocate for C++, Objective-C and Swift tools at JetBrains. Prior to that he worked in as diverse fields as finance, agile coaching and iOS development. A long time C++ developer he also has his feet in C#, F#, Objective-C and Swift – as well as dabbling in other languages. He is the author of several open source projects – most notably Catch: a C++-native test framework.
Isa Smith is a Software Engineer at Undo. Her technical interests revolve around creating great development tools. Her favourite programming language is C, for its closeness to the machine. She likes to tackle problems from the bottom up, and has an extensive knowledge of the ARM (and ARM 64-bit) architectures and a good knowledge of the x86-64 instruction set.
Greg Law is the co-founder and CEO of Undo. He is a coder at heart, but likes to bridge the gap between the business and software worlds. Greg has 20 years’ experience in the software industry and has held development and management roles at companies including the pioneering British computer firm Acorn, as well as fast-growing start ups, NexWave and Solarflare. It was at Acorn that Greg met his co-founder, Julian Smith, and on evenings and weekends, they invented the core technology that eventually became UndoDB. Greg left Solarflare in 2012 to lead Undo as CEO and has overseen the company as it transitioned from the shed in his back garden to a scalable award-winning business.
In September Phil Nash, a well-known speaker and an author of the Catch framework, signed up as a Developer Advocate for C++ tools at JetBrains (also covering Objective-C and Swift). In his 
CLion 2016.3, another 
The ReSharper family received an 
Qt Creator 4.2 was 
PVS-Studio analyzer was 
