Hi,

Here comes a new CLion 2019.1 EAP build 191.5701.24! Get it from our website, Toolbox App, or via a snap package (if you are using Ubuntu). The patch will be available shortly if you are using the previous EAP build.

When sharing our plans for 2019, we identified Embedded development support as one of the major areas of focus for the year. Ilya Motornyy, the author of the OpenOCD + STM32CubeMX plugin, joined our team in late 2018 and has already integrated the plugin into CLion. As a result, starting with this EAP, OpenOCD debugger support and integration with STM32CubeMX is available out of the box:

DOWNLOAD CLION 2019.1 EAP

STM32CubeMX & OpenOCD integration

In his two guest blog posts from 2016 and 2017, Ilya shared his experience in programming for microcontrollers in CLion and explained how the flow with the CLion plugin may look like:

• CLion for embedded development, Part I: sharing his experience
• CLion for embedded development, Part II: introducing the plugin

Below we’ll briefly summarize the setup and the steps, and we’ll highlight the changes introduced with the plugin’s integration.

Start by getting the tools ready

Currently the plugin targets STMicroelectronics boards (such as STM32 Discovery, Nucleo, or EVAL) and debugging with Open On-Chip Debugger. To start developing, you’ll need the following tools:

• ARM toolchain. Install and check you have arm-none-eabi-gcc in the system path.
• OpenOCD debugger.
• STM32CubeMX, a graphical tool to configure STM32 microcontrollers.

Check the STM32CubeMX and OpenOCD were detected automatically by CLion in Settings/Preferences | Build, Execution, Deployment | Embedded Development or set the correct paths manually.

If you are on Windows, note:

• Works fine with MinGW and MinGW-w64 environments
• Doesn’t work currently with Cygwin (CPP-15034) or MSVC
• As for the debugger:
  • arm-none-eabi-gdb.exe works fine, but doesn’t include correct pretty printers
  • arm-none-eabi-gdb-py.exe works fine, including the pretty printers, but requires python 2.7 (32 bit) installed and throws an error on the first launch (CPP-15502)
  • Bundled GDB works, but throws an error on the first launch (CPP-15502)

The OpenOCD + STM32CubeMX plugin is now bundled, so you don’t have to additionally install anything in CLion.

Create a new project in CLion

When you open File | New Project, the dialog now suggests an embedded project type – STM32CubeMX:

Simply provide the location for the project and CLion will create the .ioc file for you with the default MCU STM32F030F4.

The project sources are not yet generated though, so you should go to STM32CubeMX and run ‘Generate Code’. STM32CubeMX can be opened right from CLion: open the .ioc file and click ‘Open with STM32CubeMX’.

Important:
The newly created project in CLion has the MCU set to STM32F030F4. You can change the MCU in the MCU Selector of STM32CubeMX:

But STM32CubeMX will then reset the project name (as it creates a new one) and you’ll have to provide it in STM32CubeMX’s Project Manager and overwrite the recently created project. You are nearly done here. Just check that the Toolchain / IDE is set to SW4STM32 and check Generate Under Root:

You are ready to generate code now!

Go back to CLion and wait until the project is reloaded. A CMake project will be created for you automatically, and CLion will suggest selecting the board config:

Open an existing project in CLion

If you already have an embedded project, just open it in CLion. When you then first open an .ioc file in the editor, CLion will generate the CMake project for you:

What can I do now with my embedded project in CLion?

When the project is loaded and CMake is correctly generated, a few Run/Debug configurations are created automatically for you in CLion, including the OpenOCD one:

Use it to debug on your microcontroller.

You can also use Tools | CMake | Update CMake Project with STM32CubeMX to regenerate the underlying CMake for your project.
You are now free to create some cool stuff working on your STM board. CLion will assist you with editing and reading the code, and all the smart actions like refactorings and code generation will be available for your project in CLion!

What’s next?

This is just a first step into the vast area of Embedded Development. More smart IDE actions, deeper integration with STM boards and other MCUs, and other big features are definitely coming later this year. Give this EAP build a try, let us know what you think, and stay tuned for more!

By the way, next week, Thursday, February 28th, we’ll do a live webinar on Remote Development with CLion. Remote development on Raspberry Pi will be discussed as an example. There are still a few places left! Register now.

Other improvements

A new IntelliJ Platform feature worth mentioning here is the Recent Locations Popup (Shift+Ctrl+E on Win/Lin, ⇧⌘E on macOS). It lists all the locations that you’ve visited in a chronological order, with the latest visited location at the top and the first visited locations at the bottom.

A few great things to know about this new popup:

• You can filter by changed code locations.
• You can search by file name or code snippet: simply start typing, and the instant search will filter the matches for you.
• You can remove any location from the popup by pressing Backspace or Delete.

That’s it. Read the full release notes if you like, and download and try the EAP build today. We are looking forward to your feedback!

DOWNLOAD CLION 2019.1 EAP

Your CLion Team
JetBrains
The Drive to Develop

Hi,

We have a new CLion 2019.1 EAP, build 191.5849.15! You can get it from our website, Toolbox App, or through a snap package (if you are using Ubuntu). The patches will be available shortly for those of you who are using the previous EAP build.

Download CLion 2019.1 EAP

Build-system independent Build Targets and Run/Debug Configurations

Starting from v2018.2 CLion supports compilation database project format (along with CMake and Gradle for C++). The main issue was that the compilation database itself lacks the information about building and thus running the whole project. So only code editing was available for it in CLion. Earlier in 2019.1 EAP, we added the ability to configure Build/Clean tools for compilation database projects (simply configure external tools and provide them in the settings as build/clean commands).

And now the next big step – we generalized the approach and added the ability to create:

• Custom Build Targets: find them in Settings/Preferences | Build, Execution, Deployment | Custom Build Targets
• Custom Run/Debug Configurations: check the Custom Build Application template in Run | Edit Configurations…

The main advantage is that both of them are completely independent of any build system/project model. But of course, they are most useful in the case of compilation database projects.

How exactly does it work?

First of all, you need a custom target, so that CLion knows what to build. For this, go to Settings/Preferences | Build, Execution, Deployment | Custom Build Targets and configure one:

Here build_with_make and clean_with_make are external tools we’ve configured for this project to build and clean TscanBuild target:

Now you can Build/Rebuild your project from within CLion! But what if you’d like to Run and Debug your custom target in CLion? That’s also possible with this EAP! Open Run | Edit Configurations… dialog and create a configuration based on the Custom Build Application template:

Select the custom target from the drop-down list, put in the executable you need to run/debug and add in any other options you find useful:

By the way, remember you were setting Toolchain in the Custom Build Target configuration above? The environment (for example, on Windows, the choice between Cygwin, MinGW, VS, WSL, or Remote) and the debugger will be taken from it and used here in the Run/Debug configuration. So, for example, if you like to debug with some custom GDB version, create a corresponding toolchain -> provide it in the Custom Build Target -> select this Custom Build Target in your Custom Build Application.

That’s it! Now you can Run, Debug, and even Profile your application from CLion.

Other improvements

Other changes include:

• Cygwin supported version is increased to Cygwin 3.0
• Several fixes for Extract refactoring (CPP-3085, CPP-3086, CPP-5834, CPP-12461)
• ClangFormat: a collection of actions were updated to work with ClangFormat when enabled:
  • Reformat results of Generate actions
  • Reformat Refactoring results
  • Reformat on paste
  • Reformat block on typing }
  • Reformat on quick-fixes and intention actions

  There is one pesky issue still left (CPP-15283) with the unexpected swapping of include headers after completion in the case of ClangFormat. We hope to address it in the next EAP build.

Brief overview of 2019.1 EAP

Let’s take a quick look back at the other features and enhancements already delivered in CLion 2019.1 EAP:

• Clangd: code highlighting and quick-fixes on Clangd
• Embedded Development: OpenOCD debugger support and integration with STM32CubeMX
• Code style:
  • ClangFormat support
  • Naming conventions
• Debugger:
  • Disassembly view for LLDB
  • Ability to mute variables while stepping
• Other:
  • Injected languages support

And this doesn’t count the dozens of bug-fixes in various areas! Download and try the new EAP build right away! We are looking forward to your feedback!

That’s it. The full release notes are here.

Download CLion 2019.1 EAP

Your CLion Team
JetBrains
The Drive to Develop

Hi!

There are dozens of great events, thousands of interesting discussions, and a huge upcoming C++ release all happening right now in the C++ world. For this issue we have included a collection of interesting and engaging stories to our regular edition of C++ Annotated, we hope you enjoy them, please let us know!

Today:

• A look back at some of the recent C++ conferences: C++ in the Asia-Pacific region, new Embedded event, and the first edition of C++ on Sea.
• C++ Committee news.
• Proposals you can’t miss: Modules, Coroutines, and std::format.
• A few useful learning pieces.
• Recent releases.

C++ conferences

Many great conferences have been held since October. We would just like to mention a few here.

First of all, the Asia-Pacific region got a new conference in 2017, which grew bigger in 2018 – Pacific++. World-famous C++ speakers like Sean Parent, Titus Winters, Kate Gregory, James McNellis, and many others visited Sydney in October 2018 to meet the local C++ community. Check out the playlist with all the recordings from the conference, and definitely consider visiting this fantastic region for the 2019 Pacific++!

Meeting C++ 2018, in Berlin, was preceded by Meeting Embedded, a day which focused on embedded development and IoT. It was not a pure hardware event, but a day where developers could meet and discuss topics related to software development for the embedded & IoT sector. The day was opened by Dan Saks, and we really recommend you check out the interview he gave to Jens Weller, the founder and organizer of Meeting C++ and Meeting Embedded. Meeting Embedded was held for the first time but it seems it was a success (check out the trip reports from Rainer Grimm and the Conan team), and the speakers are known to the C++ community in general: Diego Rodriguez-Losada, Odin Holmes, and others. Video recordings of the talks from the Meeting C++ part can be found in the corresponding playlist on YouTube.

Imagine yourself on the beautiful UK coast, somewhere near Dover (full of white cliffs), looking across the channel at France, chatting with outstanding members of C++ community. Well, since it happened in February, you might need a bit of imagination to see the French coast on the other side, as it was quite foggy and drizzly:

That’s how the C++ conference by the sea was! Phil Nash ran it for the first time this year, but already managed to gather a great lineup of speakers! Just look: Kate Gregory was there with a thoughtful keynote on code written by human beings and some of the consequences of this, Nicolai Josuttis (whose talk on various ways of initializing in C++ is still one of our favourites!) with a talk on C++17, not with the traditional overview of the new features, but instead talking about the possible traps (a very practical approach indeed!), and a hymn to smart modern compilers in the keynote by Matt Godbolt (the creator of Compiler Explorer knows a lot about it!), plus many many others.

Let us ask Phil what his impression was of the first edition of C++ on Sea. Is he satisfied with how it all went – and what’s the plan for next year?

Phil: As an organizer it was my job to pay attention to every little detail and make sure everything went right (and try to fix it if it wasn’t) – so maybe I’m not the best person to ask? But the feedback I got in person, during and after the event, was overwhelmingly positive! I ran a feedback survey, in which I allowed submitters to remain anonymous. That too has been very positive. 90% of submitters rated the conference 4 or 5 out of 5 – with 65% rating it 5/5!
That’s not to say that nothing went wrong, that there was no critical feedback, or that there is anything that will need to be done differently next time. But I think most things that weren’t perfect are addressable. We’re looking to do it all again next year – the biggest question is whether to stay at the same venue. If we do, we’ll have to make some changes because it was very crowded in some places at times.

Aside from the logistical aspects, the content and social layers couldn’t have been better. We already knew we had first-rate, world-class, content – and our speakers really delivered. But we also had an emergent sub-theme of being a welcoming, inclusive, and just nice community – which was a benefit and credit to everyone and made me proud to be a part of it. Thank you all!

C++ Committee news

The 2018 Winter Meeting in San Diego along with the 2019 Spring Meeting in Kona have finally brought us to a feature freeze, leaving us with an amazing state for the upcoming C++20 release. Some people even call this future release the most powerful and important since C++11, which started the renaissance of C++!
Just take a look at the features lineup: Concepts, Contracts, Ranges, Coroutines, Modules (can you finally believe that?), spaceship operator, a whole bunch of new constexpr opportunities, and many others. Bryce Lelbach has written down the progress of both recent meetings in detail on Reddit:

• 2018 San Diego ISO C++ Committee Trip Report (Ranges v1 TS for C++20; consensus on modules design; new Language and Library Evolution Incubators)
• 2019-02 Kona ISO C++ Committee Trip Report (C++20 design is complete; Modules in C++20; Coroutines in C++20; Reflection TS v1 published; work begins on a C++ Ecosystem Technical Report)

A few words on Modules: The Tooling Study Group (SG15) has agreed to create a C++ Ecosystem Technical Report focused on modules’ interactions with the C++ ecosystem. This is a significant effort for smoother modules adoption across all the C++ tooling.

Proposals you can’t miss

In this section, we cover a selection of C++ proposals and initiatives you should definitely understand a bit about if you are developing in C++. We’ll focus on the parts affected by the recent C++ Committee Meeting in Kona.

Modules (C++20!)

P1103R2

This is one of the big three game-changing features we’ve been waiting for in C++ for a long time – and it’s finally here! In the recent committee meeting in Kona, the proposal that merged the Modules TS with the alternate proposal from Google employees was approved for merging into the working draft for C++20. That doesn’t mean that changes won’t be made before C++20 freezes, as Modules remain a hot area of debate.

But what are modules, or why is there such a big fuss?

To oversimplify: modules promise to be a replacement for what we call header files (and the whole #include model for exposing code for reuse). In the #include model, which happens during the preprocessing stage, header files are textually substituted into a single virtual implementation file that we call a translation unit. Because the headers themselves often have their own #includes, what we call the transitive closure of the entire set of files that make up a translation unit can very often be thousands – or even millions – of lines of code – even if you only wrote a few lines yourself. This has two main issues: (1.) the impact on compile times; C++’s notoriously bad build times owe a lot to this model, and (2.) poor visibility management; In order to use a symbol made known through a header file you often need to expose many more incidental symbols and layout details that will make your code more complex and less flexible.

A workaround for these issues has been somewhat common practice for many years. From the pimpl Idiom to Precompiled Headers to Unity Builds, these techniques are not always reliable, take a lot of effort to maintain, and introduce their own issues and overhead.

Modules promise to cut through all of this by providing a language mechanism to export only the symbols that should be made visible and hide all the other details. When a module is imported, it is this exported representation (in a partially compiled form) that is consumed. Object or Library files are still linked, as before, although working all this out should be taken care of by tooling.

In time, modules will change the way we write C++, and how it looks, to the degree that rivals that of the change to C++11.

Of course, the devil is in the details – and those details have been debated over at length for years. We’ve finally reached a state where the committee believes we have a system that works. But there remain unknowns when it comes to large scale adoption – especially in the area of tooling. So it is reassuring that the tooling group (SG15) are being given the responsibility of producing the C++ Ecosystem TR to aid tooling providers to work best in a brave new modules world. Those tooling providers, including JetBrains, are actively engaged, so support should already be in good shape when Modules finally arrive.

Coroutines (C++20!)

N4736 by Gor Nishanov

Another proposal that has been hotly debated for some years now has already been through a TS – and has finally been accepted into the working draft for C++20.

A coroutine is a function that may be suspended and resumed at specified points within the function. Of course, there also needs the means to call such functions, decide what to do while they are suspended, and a specification for what happens to the “bits in-between” – the glue that makes it all work.

The last part can be fully customized, but typically there are two main use cases: (1.) generators, which yield sequences of values lazily, and (2.) asynchronous workflows – a form of cooperative multitasking – ideal for event-based systems, such as networking.

With generators, values are yielded (more on that in a moment) one at a time, with the function suspended until the next value is requested.

With async, suspended code waits for some potentially long-running task (e.g., a network call) to return. In the meantime, the caller can be doing something else until it needs the return value. That doesn’t mean that async code is always multithreaded. In fact, it allows calls that would otherwise be blocking to be thread-agnostic.

All this magic is made available through three new keywords. To avoid clashes with existing keywords – and reduce the chance of clashes with other identifiers – they all have the co_ prefix.

You use co_await when calling a coroutine. In effect, you are saying that the code is “awaiting” a response from the coroutine. While it is waiting, control may be passed back to the caller to do other things.

A coroutine can return data without finishing using co_yield. This temporarily returns control back to the caller, along with some data, but it remembers where it left off, so it can be resumed.

To completely return from a coroutine you use co_return. It effectively works just like a normal return but includes the co_ prefix for consistency with the other two (in practice there are important differences about what happens between the co_return and actually returning – and what happens to the return value).

Using any of these co_ prefixed keywords in a function means that the function is, itself, a coroutine. As a result, we say that coroutines are viral – although there are ways to break out of this.

This brief summary omits many essential details – such as awaitable return types, the difference between stackful and stackless coroutines (C++20 Coroutines are stackless), and using Coroutines for other use cases that aren’t async or generators. But hopefully, it gives you an idea of how they will fundamentally change the shape of a lot of C++ code.

std::format (completing the specification)

P0645R5

The humble printf first appeared in C in the early 70s (and, itself, was based on BCPL’s writef from 1966). The first version of C++’s iostream library where added in 1984, and expanded in the first standard in 1998. iostream formatting was “better” because it was type-safe and memory-safe (in that it maintained its own buffer). Yet many have been disappointed with it in practice, and even fall back to the printf-family formatting.

So it’s great news that C++20 is adopting a third generation formatting library, which incorporates the strengths of both its predecessors, without all the downsides! A string formatter for a more civilized age, you might say.

std::format feels more like Python or C#’s string formatting approach – and, indeed, cites both as influences (as well as Rust). Braces are used as placeholders and may contain optional modifiers. Being type-safe, types can be inferred – so empty braces are common. But you can use some printf-style type specifiers, as well as other modifiers, for example, width and precision.

Arguments can also be positional, which means that localized strings with formatted insertion points may reorder inserted arguments as the language grammar requires.

If you’ve never been comfortable with the trade-offs between printf-style formatting and iostreams, std::format really does give you the best of both worlds. It may not be game-changing in the way that Modules and Coroutines will likely be, but it should make a lot of code nicer and easier to work with for very little investment.

Learning

Deprecation of Qbs

Qt Creator 4.9 will be the last release with support of Qbs. After that, the build system will be deprecated, and Qt will give preferences to qmake and CMake (the latter is growing significantly). In the future, it’s planned to switch to CMake for building Qt itself. So if you are still on Qbs, it’s now time to learn a new build system!

Debugging CMake

There was already an attempt to create a CMake debugger, but work there is no longer actively going in the branch. However, VisualGDB now provides the ability to step through CMakeLists.txt files, set breakpoints, and evaluate variables! This might look a bit crazy – whoever wants to debug the build system!? But with CMake, there is a real need for that. In this tutorial the process is explained step by step, from how to create a project in VisualGDB Linux Project Wizard, to launching the CMake Debugger, setting a breakpoint, stepping, and setting variable values on the fly. There is also the possibility to set a breakpoint on variable value changes so that a stop is triggered wherever a variable is changed.

Raging on ranges

Ranges are finally in the standard and will be shipped along with C++20! This is really a great move to increase the expressiveness of C++ code and (more importantly) solve some limitations of STL. In particular, it helps avoid passing begin/end to various collection iterators and makes the code more composable. Eric Niebler put lots of effort in making this happen, so kudos to him! And in December he wrote a blog post on some of the benefits and use cases for Ranges.
A huge discussion started in the C++ community (especially in the games industry), regarding the general readability of modern C++ code and some tradeoff here. A Twitter thread and blog post by Aras Pranckevičius raised a lot of questions in this direction. Ben Deane overviewed the current language state and ecosystem from the perspective of game development. Sean Parent finally participated in the discussion bringing his points and arguments in another blog post. So if you’d like to know what these long threads on C++ complexity were across the web in December, take a look at the linked resources – they more or less draw a picture of what it was all about.

A brief introduction to Concepts

As Concepts are finally coming with C++20, it’s good to know more about them than a basic definition (an ability to express constraints on template types). First, understand the Requirements, compile-time Boolean expressions, learn a few standard library concepts, and check out how it all works on a couple of non-basic examples.
Then go deeper, construct your own Concept, learn shorter syntax, and find out how overload works for concept function. All of the above can be found in two blog posts by Glennan Carnie: A brief introduction to Concepts – Part 1 and A brief introduction to Concepts – Part 2.

The Legacy Code Programmer’s Toolbox book

Jonathan Boccara is known for his Fluent{C++} blog and great talks (for example, “105 STL Algorithms in Less Than an Hour”). He has also published a book at Leanpub, and it’s dedicated to Legacy Code!

It promises not only to teach you how to read and understand legacy code, but also how to stay motivated when working with such code, diagnose bugs, and write documentation.

The real experience from a variety of software developers has been incorporated and instilled into the book making it a very precious artifact in the area. Check out the announcement for the book on the Fluent{C++} site and get the book from Leanpub!

Recent releases

CLion

CLion 2018.3 was released at the end of 2018. The biggest news was the Remote Development mode enabled in this version. It helps to develop remotely from a Windows, Linux, or macOS client machine to a Linux remote host. All run and build commands are executed on a remote host, while sources are synchronized automatically to the local machine so that the code can be resolved there.
Other improvements include Clangd-based navigation and search, CPU profilers on Linux and macOS, support for Git submodules, and various updates to Rust and Swift plugins.
The roadmap for 2019 was published soon after the release, and in January the Early Access Program for v2019.1 got started with ClangFormat, C++ naming conventions, and initial embedded development support.

ReSharper C++

ReSharper C++ v2018.3 tuned literally every smart feature the product has, making them work more precisely on modern C++ code. It all started with huge performance improvements, in particular, improved memory usage and optimized memory traffic, parallel cache loading on project reopening, and parallelized Find code issues command.
Besides this, ReSharper C++ can now detect formatting settings and has predefined naming conventions available in the settings. So that you can, for example, switch easily between Microsoft, LLVM, Google, or STL schemes. A more informative parameter view, new context actions, deeper knowledge of the dependent code, name hints, and better error diagnostics help you easily deal with modern C++ code.
As for the integration part, Catch 2.5 got supported, and Unreal Engine 4 support got some valuable enhancements.

Visual Studio

Visual Studio Preview 2019 started at the end of 2018 with C++ support in VS Live Share (where you can collaborate with your teammates by sharing the project, editing, and debugging in real time) and IntelliCode, which trains and puts the most used items on top of your completion list.
The second preview added support for the C++20 spaceship operator in the compiler, and brought a huge set of improvements for CMake projects. Other improvements include Lifetime checks update (the checks that detect dangling pointers and references, implementing Herb Sutter’s proposal in this area).

Qt Creator

Qt Creator 4.9 is now in Beta. It includes enhanced LSP support (and actually affects all languages, not only C++ in particular) by adding document outline, find usages, and some refactoring and quick-fix actions to the available API.
Profiling using Perf is now available for applications running on local Linux or a remote Linux system on a Linux or Windows host.

The recording of our February 28th webinar with Phil Nash is now available on the JetBrainsTV YouTube channel.

In this webinar, we took a look at some of the remote development topologies that developers work with, explaining how CLion supports them.

The video includes the time stamps:
01:06 – Intro with all the topologies briefly explained
07:53 – Remote GDB debug sample
11:30 – Remote GDB debug configuration
15:37 – Raspberry Pi demo: remote GDB debug
21:21 – Full Remote Development
26:00 – Raspberry Pi demo: full remote mode
29:50 – WSL case
32:30 – Q&A

Useful links and further reading:

• Documentation page on Remote Debug via GDB/gdbserver
• Documentation page on using WSL development environment in CLion
• Documentation page on Full Remote mode
• Stay local, let your IDE do remote work for you! – blog post on Full Remote mode in CLion

Questions
Q: What if the remote is a Docker container? Can this be handled somehow similar?
A: While you can work with Docker containers as with regular remote machines now (so the Full Remote mode will work), you might be asking about smarter support, which includes Docker toolchains and some easy configuration steps (like we have for WSL now). The latest is not yet available in CLion, but we definitely have some plans for the future – see CPP-13751.

Q: What are the supported combinations of platforms for the Full Remote Mode?
A: The local client machine can be macOS, Linux, or Windows, but the remote host should be Linux. The setup is also limited in terms of the project model, as right now it works only for CMake.

Q: Are ssh keys supported?
A: Yes, they are supported. When configuring the remote toolchain, select the “Key Pair” authentication type.

Q: For remote development on Windows with WSL, can we have rsync to transfer the files? It will be much faster than scp. rsync can be installed on WSL.
A: For WSL it’s better to use a separate WSL toolchain type. In that case, no file synchronization is happening at all, as it’s actually the same memory segment.

Q: How is the mapping created for local and remote folders in the Full Remote Mode? How can I change the remote directory where the source code is synchronized?
A: The configuration process is as follows:

1. Create a Remote Toolchain in Settings/Preferences | Build, Execution, Deployment | Toolchains (toolchains are IDE-wide – they define the environment and the compiler/debugger executable).
2. Create a CMake Profile in Settings/Preferences | Build, Execution, Deployment | CMake (there are project-wide – they define the build type and other CMake options).
3. After step 2, an entry in the Deployment settings (Settings/Preferences | Build, Execution, Deployment | Deployment) appears. The Mappings tab defines the Local/Remote path mappings. By default, CLion creates a directory under the /tmp folder on the Remote host. You can change the path here.

Most notable requests on Full Remote development in CLion

• Configurations:
  • Open remote CMake project, no requirement for sources stored locally (CPP-14584)
  • Native Docker support (CPP-13751)
• VCS: Remote VCS support (CPP-14482), VCS branch switching (CPP-14272)
• Debugger:
  • Launch configuration automatically under gdbserver via ssh for remote debug (CPP-7050)
  • Attach to process on remote host (CPP-14316)
  • An option to provide symbol file for a shared library in case of remote GDB debug with gdbserver (CPP-8236)

There is a set of other bugs and requests linked to this main ticket, CPP-744.

Cheers!

Your CLion Team

Hi,

Introducing the new CLion 2019.1 EAP, build 191.6014.11! You can get it from our website, Toolbox App, or through a snap package (if you are using Ubuntu). The patches will be available shortly for those of you who are using the previous EAP build.

DOWNLOAD CLION 2019.1 EAP

Memory View

Hex view has been available in the debugger for a while already in the experimental mode (controlled by Registry cidr.debugger.value.numberFormatting.hex option and turned off by default). Now it’s time to introduce Memory View!

Memory View dumps the memory behind the pointer in the Debug mode. To invoke it, select a pointer variable in the debugger’s variables view and press Ctrl+Enter on Windows/Linux or ⌘Enter on macOS:

During stepping, if you have memory view opened, CLion will highlight the memory changes that happen in the selected memory piece:

We are still working on Memory View (including UI) and will be glad to listen to your feedback here in comments!

Header Guard style

We’ve recently added the naming conventions for C/C++ to CLion, and now we’ve also included the ability to configure the header guards style there. Go to Settings/Preferences | Editor | Code Style | C/C++ to check the default template:

In this template you can use predefined variables such as ${PROJECT_NAME}, ${PROJECT_REL_PATH}, ${FILE_NAME}, ${EXT} (file extension), and predefined variables from Settings/Preferences | Editor | File and Code Templates | Files tab, such as ${USER} or ${DATE}. It also supports Apache Velocity syntax. Alternatively, you can select the style from one of the predefined schemes (Google, LLVM, Qt, GNU, etc.).

This style will be used by CLion when creating a new header file. But there’s even more! Now, when you rename the file, the header guards matching the currently configured style will be updated with the new name if needed:

Besides all this, a few code highlighting issues (when Clangd was used) were addressed, and the regression with an unexpected swapping of include headers after completion (CPP-15283) was fixed.

That’s it. The full release notes are here.

DOWNLOAD CLION 2019.1 EAP

Your CLion Team
JetBrains
The Drive to Develop

CLion 2019.1 goes Beta! To install CLion 2019.1 Beta (build 191.6183.6), download it from the website, update from our Toolbox App, or through a snap package (if you are using Ubuntu), or use a patch update.

DOWNLOAD CLION 2019.1 BETA

The Beta builds are sufficiently stable compared to the EAP builds, but some issues may still occur. If they do for you, please report them to our issue tracker. No license is required to use this build.

This build brings the following fixes:

• For Embedded Development:
  • Show detailed error when OpenOCD executable isn’t correct (CPP-15466)
  • When opening an .ioc file, suggest opening as a project (CPP-15532)
• For custom targets: when a custom target is renamed, the corresponding custom run/debug configuration is updated accordingly (instead of invalidation)
• A few fixes for Refactorings (CPP-13822, CPP-3811)

The full release notes are available here.

Once again, here are the key improvements to look forward to in v2019.1, which is just around the corner:

• For Embedded Development: OpenOCD debugger support and integration with STM32CubeMX (read more)
• ClangFormat support (more)
• C/C++ naming conventions (more)
• More responsive editor thanks to code highlighting with Clangd (more)
• Build-system-independent Build Targets and Run/Debug Configurations (more)
• Memory View in Debugger (more)

DOWNLOAD CLION 2019.1 BETA

Your CLion Team
JetBrains
The Drive to Develop

Hi,

Please welcome the Release Candidate for the upcoming CLion 2019.1!

Download the build 191.6183.49 from our website, update from the Toolbox App, or through a snap package (if you are using Ubuntu).

DOWNLOAD CLION 2019.1 RC

Please note that to use CLion 2019.1 RC, you need to have an active subscription (or start a 30-day evaluation period). No patches are provided for this release candidate, but you can expect a patch from the latest 2018.3.4 update to the 2019.1 release version.

Resync with Remote Hosts

In the full remote development mode, the CLion instance runs locally and synchronizes header search paths from the remote machine to the local host (to resolve the code correctly in CLion). Previously, we’ve triggered the synchronization of the header search paths on every CMake reload, which might be a time-consuming task. Now the resync is performed only when triggered manually, by calling Tools | Resync with Remote Hosts.
The registry option clion.remote.resync.system.cache allows you to change the behavior to the previous one, if you still prefer it.

Besides that, this RC delivers the following fixes and changes:

• Clangd memory indicator is now turned off by default and can be enabled along with the JVM memory indicator in Settings/Preferences | Appearance & Behavior | Appearance | Windows Options | Show memory indicator.
• When MinGW is used in CLion, user input is no longer duplicated in the output window (CPP-2580). Unfortunately, the issue is still present for WSL and Remote toolchain cases (CPP-15753).

The full release notes are available here.

Your CLion Team
JetBrains
The Drive to Develop

We’ve got great news for you! This year’s first major update, CLion 2019.1, is public!

To update right away, use the Toolbox App, snap package (on Ubuntu), our website, or the patch-update from the latest build of 2018.3. What are you waiting for?

As announced earlier, our main areas of focus this year are IDE performance, expanding Clangd leverage, and Embedded Development. This update makes headway in all three areas:

• Clangd now powers code highlighting, provides more detailed error messages, and performs new inspections.
• CLion’s own language engine has been improved with better performance across the IDE and more accurate refactorings.
• We’ve taken several steps to help you effectively do Embedded Development in CLion.
• Adjust CLion to your code style: ClangFormat, C/C++ naming conventions, and header guards style.
• Project-model-independent build targets and run/debug configurations are now available and are especially useful for compilation database projects.
• Debugger enhancements include:
  • Memory view
  • LLDB Disassembly View
  • Mute Variables on stepping
• Injected languages are here.
• Brighten up your IDE with custom color themes!
• The Rust plugin has been updated.
• Other enhancements include a brand new Recent Locations popup, an improvement for plugin writers, and more.

We can provide you with a free 30-day trial to test out all these features for yourself before committing to a subscription.

DOWNLOAD CLION 2019.1

Wider integration with the Clangd-based language engine

As our main focus on wider Clangd integration hasn’t changed, we devote a lot of effort to developing our complementary Clangd-based language engine. Where possible (from the functional and performance point of view), we reimplement actions on this engine, still leaving the option (for now) to switch to CLion’s own engine for such actions.

From a user’s perspective, we see that it makes the editor more responsive. Another step we’ve taken towards wider Clangd integration is that we now leverage Clangd to identify places that need quick-fixes. This means that the Clangd-based language engine can not only be used to identify potential breaches in the code and show an error or warning, but also to provide the location for a quick-fix. Note though that the actual quick-fix is provided by CLion.

This second step however had some drawbacks, and as a consequence a few of the quick-fixes were temporarily removed (CPP-15243).

Amongst other things, the error-annotator has been improved, and can show more detailed error message taken from Clang. Useful cases for this includes debugging a failed overload resolution, where Clang can provide a detailed reason for the substitution failure:

Our C++ language support team is also working on the unique code checks provided by CLion and implementing them on Clangd. This time the Member function can be static check. It analyzes the method body, trying to check if it depends on this or not:

Improvements for CLion’s own language engine

IDE performance

Even as we are working on the Clangd-based engine, we’re still investing lots of effort into improving our own language engine. First, we aim to boost the IDE’s performance, where Clangd is not yet applicable, and second, we increase the accuracy of the refactorings, which still cannot be moved to the Clangd-engine, at least not in its current state.

Importantly, we’ve reduced the initial indexing times when you create a new project or open one for the first time. The idea is that CLion can now reuse the symbols built already for some other recently opened projects, as long as they fit for this project. A typical case is with STL or Boost libraries, or any other custom library you are widely using in your current and new projects. We plan to work further on this feature and expand on it in the future.

More accurate refactorings

We have been going through and updating the refactorings one by one, and this time we got to work on Extract. To make sure the result is accurate, we worked on making it respect the std:: namespace qualifier, template specialization and template parameters, and type aliases.

The Rename refactoring has also had some special attention given to it. Now the Rename called on a file doesn’t silently trigger the associated class/struct rename, but instead shows a popup suggesting this option. And vice versa!

Besides, when the header file is renamed, the header guards are updated accordingly if they are used in this header file and the header guards style template used includes the header file name.

First steps towards Embedded Development

If you develop for STMicroelectronics boards, you’ll be happy to find that CLion now integrates with STM32CubeMX:

• CLion’s new project wizard suggests you creating an STM32CubeMX (.ioc) project or you can open an existing project of this type in CLion.
• Later you can start STM32CubeMX directly from CLion at any time to update board settings and generate code.
• CLion will also generate a corresponding CMake file for your .ioc project to work with it correctly and suggest selecting the board config.

If you’ve ever tried the OpenOCD + STM32CubeMX plugin, the functionality is very similar as we now bundled the updated version of this plugin into CLion.

The second part of the plugin can be useful to any embedded developer, as it provides the integration with Open On-Chip Debugger. Use the new Run/Debug configuration template, ‘OpenOCD Download and Run’ to debug on your microcontroller.

Learn more about the integration and necessary setup in this detailed blog post.

Adjust CLion to your code style

ClangFormat

The ClangFormat tool is widely used in the C/C++ world and is even regarded as a standard by many developers. Quite often open source projects store a .clang-format config file in their repository. Now, when you open up such a project in CLion, the IDE will detect the config file and will suggest that you switch to ClangFormat. Which means, ClangFormat is now integrated into CLion as an alternative formatter! It affects all the IDE’s actions, so you can switch to it completely.

There is also a general per-IDE switcher for ClangFormat in Settings/Preferences | Editor | Code Style. Read all about it in our dedicated blog post.

C/C++ naming

PascalCase for classes and structs, camelCase for member functions and variables, SCREAMING_SNAKE_CASE for macros and constants, snake_case for global functions, ‘E’ as a prefix for all enum types – all these naming conventions. CLion understands your pain and now provides the corresponding settings in Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention and respects the selection in all completion, code generation, refactoring actions, and quick-fixes.

You can also select a naming style (and other code style settings) from a predefined scheme: Google, LLVM, Qt, and others are available. Or, you can enable the Inconsistent Naming inspection to have the IDE warn you about any problematic names and then give suggestions for a more accurate name with a quick-fix to replace all the usages for you.

Header Guards style

What do you usually use in header files – pragma or header guards? By default, CLion generates header guards (you can change the header file template to use pragma in Settings/Preferences | Editor | File and Code Templates), if you are a header guard kind of person, then you’ll be happy to know that CLion 2019.1 comes with a new ability to configure the header guards style:

The template supports Apache Velocity syntax and uses some predefined variables such as ${PROJECT_NAME}, ${PROJECT_REL_PATH}, ${FILE_NAME}, ${EXT}, etc. If you wish to use a more standard style, select one of the predefined styles option (same as for the naming conventions).

Custom build targets and run/debug configurations

Many of you have been asking us recently to provide you with the ability to build projects using some kind of custom command provided in the IDE. There have also been a lot of requests for the ability to run/debug binary in the IDE by pointing a Run/Debug configuration to the custom executable. This would be especially useful for compilation database projects, which are supported in CLion (and can be extracted from nearly any build system). So in CLion 2019.1, this is exactly what we have done.

To build your project with a custom command, create a Custom Build Target in Settings/Preferences | Build, Execution, Deployment | Custom Build Targets, where provide a toolchain and Build/Clean commands:

To run or debug a custom configuration in CLion, configure the Custom Build Application configuration in Run | Edit Configurations…, where you can provide a custom target, executable, the program arguments, etc.

Learn more about the details of how this all works in our webhelp.

Debugger enhancements

Memory view

Starting from CLion 2019.1, you can dump the raw memory behind a pointer when you are debugging. There is even more to this: open the memory view while debugging and follow the changes to the memory during stepping:

This is still a work in progress. For example, you can expect the ability to dump the arbitrary memory address in the Debug mode coming soon in the updates.

Disassembly view

The Disassembly view has been improved to show the information there categorized by function. And it now works for LLDB, so LLDB and GDB are both covered now.

Use Force Step Into (Shift+Alt+F7 on Win/Lin, ⌥⇧F7 on macOS) on a function with no source code to open this view:

Mute variables

Variables can take a significant amount of time to calculate, and this may be especially performance-critical when stepping through the code. If you need to keep an eye on the variables calculations, it can be a huge amount of work and may not even be needed in the end. In such situations, you can now Mute variables using a general per-IDE switch. And when you do need to, you can apply the Load option to calculate the particular variable on the current step.

Injected languages

String literals with pieces of code can be treated as real code pieces. This means that code highlighting and language-specific intentions and actions can be applied to them. Typical examples where this could be useful would be SQL or HTML strings, or regular expressions.

To temporarily inject a language, press Alt+Enter and apply the intention “Inject language or reference”, select the appropriate language, and you are done! Now you can edit code fragments in the dedicated editor section or apply a specific action, for instance, you can check whether a string matches the RegExp right in the IDE:

Isn’t that handy?

Brighten up your IDE with custom color themes!

If the Default white and Darcula themes are not enough for you, then why not go ahead and create your own custom one! Every color of every item in your IDE, from the icons and radio buttons all the way through to the arrows, are now all totally configurable. Adjust them to your own personal preferences and then save it all as a new theme plugin. Learn how to do it in this tutorial.

Rust plugin update

The IntelliJ Rust plugin provides support for Rust along with the Cargo build system and debugger in CLion. This version gives it a massive update:

• Profilers are now supported for Rust: DTrace on macOS and Perf on Linux.
• Out-of-scope items are suggested in code completion and trigger the auto-import when used.
• Rust language injection into code snippets in doc comments is now provided.
• Various improvements to Cargo check annotator and LLDB and GDB formatters.

Stay tuned for a detailed blog post on the recent changes (or subscribe to our Rust news here in the blog).

Other enhancements

Other improvements include a new Recent Locations popup, which provides an overview of all the locations that you’ve visited in chronological order, and an updated versions of bundled CMake (3.13), the bundled LLDB (7.0.1), and the latest supported Cygwin (3.0).

Besides, the process of building CLion’s plugins was simplified by publishing CLion as a Maven dependency to be used by gradle-intellij-plugin (since version 0.4.2).

That’s it! Please go and give all the new improvements a try and let us know what you think.

DOWNLOAD CLION 2019.1

Hi,

We’ve recently just released CLion 2019.1! It has been served up with several major improvements, like Clangd-based code highlighting, integration with ClangFormat, project-model-independent build targets and run/debug configurations (especially useful for compilation database and Makefiles projects), memory view in the debugger, injected languages, and not to forget of course some initial Embedded Development support. Release time is always exciting, and we are enormously inspired by all your positive feedback and kind words!

There are still a couple of glitches and regressions, but we are planning to sort them out with the first bug-fix update. Right now, it feels like a good time to give our sincerest thanks to the most active evaluators and share with you all our plans for v2019.2.

Special thanks

There are so many possible setups and configurations where CLion is used nowadays, that we may sometimes miss some of them during testing. This is why our Early Access Preview program is so helpful to us, and we greatly appreciate all the help of our evaluators! There is an ongoing tradition to thank our most active EAP evaluators here in the blog and present each of them with a full 1-year subscription to CLion (as a new subscription or extend their current one). This time we’d like to issue a special thanks to the following contributors:

• Victor Sergienko
• Renat Khayretdinov
• Dmytro Nezhevenko
• Erik Hyun

You will receive a personal email with details on how to claim your license. (If, for some reason, you do not get an email from us within a week, ping us here in the comments!)

CLion 2019.2 roadmap

Our general areas of focus for this year will stick closely to the same as announced previously. A detailed plan for the next cycle looks as follows:

• Editor Responsiveness and Performance

We have some major architectural changes planned, which on the one hand could take longer than a single release cycle, but on the other hand, it will definitely improve the performance of many of the actions across the whole IDE. This should eliminate a big chunk of the existing UI freezes.

• Further integration of Clangd-based C++ language engine
  • Improve the accuracy and put back the ‘Unused includes’ diagnostic
  • Move more of the IDE’s actions to Clangd-based engine (we are currently experimenting with a few and seeing how it goes)
  • Bug-fixes and engine performance tuning
• C++ language support
  • Action to switch header/source (reworking current go to related symbol action) – CPP-12920
  • Continue with refactoring fixes, especially the Move refactoring
• Embedded Development
  • Peripheral view for ARM devices (support for SVD files)
  • Support for custom gdbservers (ST-Link and J-Link GDB Servers)
• Debugger
  • Continue with the ongoing work on the Windows debugger (for MSVC). This debugger is being implemented from scratch and is based on LLDB. We hope to have a preview ready for v2019.2, but can’t promise anything at this stage.
  • Improve current memory view
• Project Model
  • The ongoing work to create a project model API to allow 3rd-party plugin writers add support for currently unsupported build systems will continue during this release.
  • Another direction is to start Makefiles support. Saying this, we are giving no promises regarding v2019.2, but just want to assure you that this is under careful investigation and analysis from our side.
• Remote
  • Various enhancements in remote development and an ability to launch the application automatically under gdbserver via ssh for remote debug (CPP-7050).

That’s it! Do you have any new feature requests? Send them to our tracker. We’re listening!

Your CLion Team

JetBrains
The Drive to Develop

Hi,

With CLion 2019.1 released just a couple of weeks ago, it’s already time for the first bug-fix update. Build 191.6707.62 is now available to download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

DOWNLOAD CLION

This update includes a few major fixes and enhancements:

• This update fixes an annoying issue with the false redefinition errors shown by the clangd-based engine in several cases (CPP-15464).
• For remote toolchains, the Cannot get compiler information error is now fixed (CPP-14477).
• Move refactoring dialog (notifying about escalating the visibility) no longer hangs (CPP-15655).
• In the newly added naming convention settings (Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention), Upper_Snake_Case is now available as one of the options.
• Bundled CMake was updated to v3.14.2.
• Custom build targets and run/debug configuration are useful for compilation database projects, especially when using them to workaround Makefiles and other project models not natively supported in CLion. In this update we made the configuration process even more friendly – CLion now allows you to configure Custom Build Target right from the Run/Debug configuration settings dialog:
  

The full release notes are available here.

Want to know what’s next? See our roadmap for CLion 2019.2.

Your CLion Team
JetBrains
The Drive to Develop

Hi,

A few days ago we published the first bug-fix update (2019.1.1) for the recently released CLion 2019.1. Thanks to our vigilant users, we’ve learned quickly that this build is affected by a very unpleasant freeze on IDE start when several projects are opened (CPP-16039, OC-18440). The IDE fails to recover in that case, unfortunately.

We are sincerely sorry for this and apologize for any inconvenience it might have caused. We’ve analyzed the source of the issue and will do our best to prevent such situations in the future.

If you are using v2019.1 (and especially 2019.1.1), we recommend that you update to the newest 2019.1.2 build, which is now publicly available. Download it from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

DOWNLOAD CLION

Your CLion Team
JetBrains
The Drive to Develop

Hi,

Please welcome a new bug-fix update: CLion 2019.1.3! Build 191.7141.37 is now available to download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

DOWNLOAD CLION

Here are the highlights:

• CLion can now work with header guards that use several define patterns (CPP-15736).
• CMake 3.14.3 is now bundled.
• The exception, when Google Sanitizers were launched from CLion, is fixed.

Full release notes are here.

Your CLion Team
JetBrains
The Drive to Develop

Wondering how to add a package to your C++ project? In this guest blog post Javier G. Sogo from JFrog shares how to start with Conan package manager in CLion.

Javier G. Sogo @jgsogo Software Engineer at JFrog After several years of C++ development, I moved to Python to learn the best practices and tools. Now I’m back building Conan, the C/C++ package manager.

Writing a C++ project from scratch is always a delightful challenge. Starting from a blank page writing your code and creating your functionalities, all the way through to building on top of solid and high-performance libraries… but wait! Sometimes it’s not easy to get those libraries available for your project to compile and link, and possibly you are not experienced in that build system or the library may require some patches to be built for your platform.
The lack of a package manager in the C++ world has slowed many projects down, requiring dedicated efforts to handling external libraries or rewriting functionalities to avoid using third parties.
Conan is an open source, decentralized package manager that simplifies the process of integrating and reusing C and C++ libraries and packages. It automatically manages and reuses binaries for any possible configuration, increasing development speed. Conan is also able to build and cross-build packages from sources, it integrates with any build system, with very high flexibility and customization capabilities.
In this blog post, we will show how to use Conan in your CLion workspace to get your preferred libraries ready to use in your project. We will use the Conan-CLion plugin to integrate both applications smoothly, for example, by building an MD5 hasher using an already available implementation from the Poco libraries.

Installing all the parts

1. Conan-CLion Plugin

To follow along with this example, you’ll need to install the Conan by JFrog plugin from the JetBrains marketplace. It can be easily installed using the Plugins section in the Preferences/Settings window, or from the welcome screen using the Configure>Plugins option.

After restarting CLion a new “Conan” tool window will appear at the bottom of the IDE, which is ready for you to use.

2. Conan Client

Next, you’ll need to install Conan. Conan is a python application, you can install it using pip (pip install conan) inside a Python virtual environment or system-wide, or you can download a standalone application and unpack it into your system, choose the way that best fits your needs from the download page.
We highly recommend that you read the Conan documentation; although the default configuration is enough for this example, it is important for you to know about many other important features that are not covered in this article. Including, the distributed nature of Conan that allows mixing different origins for your libraries, JFrog Artifactory integrations, workspaces, etc. These features will help you in developing high-quality software.

3. Conan Plugin Configuration

There are a couple of configuration points we need to address before running our example, these configurations only need to be done once for all your projects. First of all, you will need to provide the path to the Conan executable you want to use in the Preferences window (leave it empty to use Conan from the PATH).

Second, we need to define the correspondence between CLion CMake profiles and Conan profiles. CLion profiles are a handy way to create different configurations to build your project, the same as Conan profiles, that’s why both should match.

[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=x86_64
compiler=apple-clang
compiler.version=10.0
compiler.libcxx=libc++
compiler.cppstd=gnu17
build_type=Release
[options]
zlib:shared=False
[build_requires]
cmake_installer/3.13.0@conan/stable
[env]

A Conan profile is a file where the user defines a set of settings, options, environment variables, and build requires, that can be reused to build any package. These files can be handled individually using conan profile commands or, if you are working with other people, you will probably want to maintain a shared configuration with your colleagues using conan config install commands. Create as many profiles as you want using the command line or copy an URL with your shared Conan configuration into the plugin settings. For more information related to this core feature of Conan, the documentation about using profiles is a good starting point.
Once your profiles are ready, match them with the CLion ones using the button, a window will pop up for you to make these assignments.

Creating the C++ project

After the configuration is complete, we can leap into C++. The following example demonstrates the MD5 hashing utility in the Poco library, a few lines of code should be enough to get us started:

#include "Poco/MD5Engine.h"
#include "Poco/DigestStream.h"
#include <iostream>

int main(int argc, char** argv)
{
     Poco::MD5Engine md5;
     Poco::DigestOutputStream ds(md5);
     ds << "abcdefghijklmnopqrstuvwxyz";
     ds.close();
     std::cout << Poco::DigestEngine::digestToHex(md5.digest()) << std::endl;
     return 0;
}

If we try to compile this project using CLion it will fail, because the Poco libraries are missing. This is where our package manager comes into action.

Getting your dependencies with Conan

Conan uses a separated file to store information related to a project. This can either be a plain conanfile.txt file, or a python conanfile.py file that handles more complex logic regarding your dependencies. The Conan plugin can work with both of these file types.
For this example we only need a couple of lines in a conanfile.txt that you should add to your repository:

[requires]
Poco/1.9.0@pocoproject/stable

[generators]
cmake

[requires]

These lines notify Conan that our project requires the Poco library, and provide the version and origin for it. Conan will look in the remotes and retrieve the recipe for Poco from there, it will also grab the binaries if they’re available for your configuration and, if not, it will trigger a compilation from sources. All of this will be done using the Conan install button, , that can be found in the Conan tool window.

As you can see, Conan not only installed the Poco libraries, but also OpenSSL and ZLib too. This is because they are transitive dependencies of Poco. If binaries matching your configuration are available in the remote, Conan will just download them, otherwise, Conan will compile these packages from sources no matter if they use CMake or other build systems (OpenSSL uses Makefiles).

[generators]

Conan will create a file for each of the generators listed here, as CLion uses CMake we need that generator. These files contain all the information of the requirements, including: paths to includes, libraries or resources, and compile flags. Basically, everything that needs to be consumed by your project. You only need to include this file into your build system, there is no need to change anything else, and you’re ready to go.
Modify your CMakeLists.txt to include this automatically generated file, named conanbuildinfo.cmake:

cmake_minimum_required(VERSION 2.8.12)
project(MD5Hasher)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(md5_hasher main.cpp)
target_link_libraries(md5_hasher ${CONAN_LIBS})

Compile again and run your project. Conan will take care of your dependencies, by locating and downloading (or compiling) them, making them available for your project. If you feel that this implementation requires modifying your project, you can try other CMake related generators available in Conan, such as cmake_find_package or cmake_paths. Additional information on how to activate these generators can be found in the Conan documentation.

Conclusion

Alongside CMake and CLion, Conan has become one of the big C’s for the C++ language. Having a package manager encourages the community to share their libraries and build functionalities on top of existing ones, modernizing the C++ ecosystem towards a more mature and useful one. It also allows companies to have a professional tool to build all their internal libraries and third-parties using the same process, preserving consistency and reproducibility of their builds, and keeping their developers focused on their job.
The plugin in its first version implements just some basic functionalities of Conan, we highly recommend you to use it in your projects, but also to explore all the functionalities that Conan provides. We’re always happy to receive feedback related to both the CLion plugin and Conan in general.

Happy Coding!

Hi,

We’re launching the Early Access Program for CLion 2019.2! As usual, the EAP builds are free to use and no license is required. Get early access to the upcoming changes and enhancements and give us your feedback! We want to test it in all kinds of non-standard or unusual environments you may have set up, and collect and fix as many issues and regressions as possible. So, please try these builds and let us know what you think!

Note you can install any EAP build in parallel with a stable CLion release such as 2019.1.

As usual, you can download build 192.4205.36 from our site, use the Toolbox App, or a snap package (if you are using Ubuntu).

Download CLion 2019.2 EAP

This EAP build polishes lots of features first introduced in the recent v2019.1, but also brings some new enhancements. The main highlights include:

• Parameter name hints
• Go to address in Memory view
• Code assistance for .clang-format files
• Move refactoring: an ongoing update
• Naming convention: new settings
• Platform changes

Parameter name hints

Parameter hints are now displayed in the editor in line with your code, to increase its readability. They can help you understand the function call without exploring the function signature (which you still can do with the parameter info tooltip or by navigating to a function declaration). They show the names of function parameters for passed arguments.

Arguments passed by non-const reference show the hint &: to indicate the fact they can be modified:

Note: Parameter hints require Clagd-based engine running (on by default).

Hints are displayed in the following cases:

• For function calls, lambdas, constructors, initializer lists, and macro expressions.
• For argument literals and expressions with more than one operand.
• For a constructor invoked through emplace_back-like functions.
• Hints for initializers are not shown when the argument is used as a designated initializer.

To show/hide parameter hints in particular cases or globally, use Settings/Preferences | Editor | General | Appearance. Use Configure dialog to adjust the parameter hints settings. Or just right-click on any parameter hint in the editor:

This is a work in progress, and we are aware of several issues (for example, see subtasks of CPP-12452).

Go to address in Memory view

In CLion 2019.1, we’ve introduced Memory View. When you debug your application, it’s possible to review the memory behind the pointer by simply calling Show in Memory View (Ctrl+Enter on Windows/Linux, ⌘Enter on macOS) on a pointer in the Variables view in the debug toolwindow.

We’ve updated Memory View and added ‘Go to address’ functionality:

You can enter a hex number representing an address, a pointer variable, or call the address (&) of any variable you are interested in. Code completion will help you with the known symbols:

We also plan to have Go to address in the Disassembly View, to navigate to the function’s assembly code for example (currently it’s implemented only for global symbols CPP-16323). Stay tuned!

Code assistance for .clang-format files

There’s one more enhancement for ClangFormat: if you have your customized .clang-format config files in the project, you can now benefit from code assistance when you update them. This includes:

1. The Quick Documentation popup for options in .clang-format config files:
   
2. Code completion for options and their values:
   
3. Options description in the code completion popup.
4. Highlighting for option values that don’t match the allowed value set.
   

Wondering how this works? CLion simply validates the .clang-format config YAML file against the JSON Schema that we build specially for ClangFormat.

Move refactoring: an ongoing update

We never stop working to improve CLion’s refactorings. In 2019.1, we focused on Rename and Extract refactorings and now it’s time to, err, move forward with the Move refactoring!

While the work is still in the very beginning (CPP-1166), we’d just like to briefly highlight the main improvement. The update Move refactoring dialog consists of the following parts:

• As before, you can move a member to a file (existing or new).
• Now you can also move a member to a namespace (existing or new).
• A preview for the change is available right in the dialog.
• The conflicts, like other members dependent on the one you move, are shown in the dialog.

As a nice addition, code completion helps you with select files and namespaces in the dialog:

Naming convention: new settings

CLion 2019.1 respects the naming scheme you provide. You can inherit one of the existing schemes, or create and customize your own.

The settings to describe the naming convention have been reworked to become more flexible and provide more opportunities:

First, let me assure you that all your current naming settings will be migrated smoothly from 2019.1 to 2019.2. (If you notice any issue of that kind in the EAP build, please report immediately so that we can fix it before the release.)

The rule can now address several entity kinds at a time – just add as many as you need by clicking to the entity kind field of the selected rule, or select none to specify a rule for any entity kind:

If there are several rules applicable to one entity kind in the given code location, the last one in the list will be used in practice.

Settings like Visibility (Public, Private, or Protected) and Specifier (Const or Static) are shown only for the entity kinds for which these settings can be applied. For example, for member function you can configure both, while for namespaces none of these work.

Now try the settings and please let us know what you think about the updated UI.

Platform changes

JetBrains Runtime

All our IntelliJ-based IDEs are now available with the bundled customized JBR11 (the fork of OpenJDK 11 with fixes from the JetBrains team). This transition addresses a whole bunch of issues and hopefully will make your experience with our IDEs much more pleasant.

However, builds with JBR8 are still provided on our site for your convenience. Also, as before, you can switch the boot JDK in the Switch Boot JDK dialog (use the Maintenance dialog (Shift+Ctrl+Alt+/ on Linux/Windows, ⌥⇧⌘/ on macOS) to find it).

Statistics Sending Change

In Early Access Program (only!), we are enabling sending usage statistics by default. This means that we’ll be receiving anonymous data about features and plugins used, configuration, etc. This will not include personal data or any sensitive information, such as source code or file names. The data sent complies with the JetBrains Privacy Policy. You may disable this at any time under Settings/Preferences | Appearance & Behavior | System Settings | Data Sharing.
Note: This change affects EAP builds only. In a stable release the data sharing will remain OFF by default.

The full release notes are here.

Download CLion 2019.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

More and more C++ events, community meetups, and conferences are appearing around the globe. 2019 is definitely looking like a year for new C++ conferences. Take, for example, C++ on Sea (UK, in February) or the upcoming CPPP (France, in June). Even C++ Russia now has two editions per year – one in Moscow and one in St. Petersburg. And, finally, there’s the event we just visited – Core C++, held in Tel Aviv, Israel.

Core C++ was started by the organizers of two big local communities, the Core C++ meetup in Te Aviv and the Haifa::C++ meetup. Adi Shavit from Tel Aviv is a well-known international speaker you may have met at one of the many C++ events around the world. The event was hosted at the Academic College of Tel Aviv–Yaffo, very close to the beautiful and historic old city of Jaffa.

Talks

Despite being new and young, Core C++ managed to gather over 350 participants and several famous speakers from abroad. Jason Turner opened the event with a keynote and paid tribute to more than twenty crucial C++ features over the years. He began with changes that were revolutionary in the past, like templates and auto. Then came the C++20 updates. His pragmatic look, as he called it, included an analysis of the impact of those features on C++ coding.

Hana Dusíková again talked about compile time regular expressions, but this time in a new and updated way. She presented runtime and compilation time measurements to compare CTRE, PCRE, Boost, std, and some other approaches.

Other talks you may have heard before Core C++ were Initialization in Modern C++ by Timur Doumler and The Dawn Of A New Error by Phil Nash. I gave my talk, C++ Ecosystem: For Better, For Worse, for the second time since its ‘inauguration’ at ACCU 2019.

Bryce Adelstein Lelbach closed the conference with an overview of Modules coming with C++20. He started the talk by collecting all the reasons why headers are terrible: slow to compile, ODR violations, lack of encapsulation, cyclic dependencies, and order dependencies. He then explained the core syntax and the main ideas behind the proposal. The most interesting and unique part came later, as Bryce now chairs the Tooling Study Group in the C++ committee who, as it happens, are now discussing the details of implementing modules in compilers. For example, the kinds of linkage were discussed in detail during the talk. I would say that the only idea that bothers me is the intent to automatically convert old-style includes for std library headers into modules. This might cause issues in legacy code where these includes were affected by the preprocessor definitions passed earlier, as modules will be protected from that by design. This is not yet settled in the standard, and my guess is that the compilers will be afraid to provide such behavior by default.

I also want to mention a few interesting talks from local speakers. One was the story of implementing Concepts in Clang, given by the actual contributor, Saar Raz, who is now ready to push the first implementation parts to the LLVM master. This will put Clang ahead of GCC, which still supports an old Concepts TS incompatible with the C++20 draft. An interesting fact is that the author plans to support the old TS syntax (like in GCC) in Clang as well – maybe not fully, but at least to some extent. The talk itself was mostly dedicated to the history of the implementation and typical issues most first-time LLVM contributors run into.

Gal Zaban also gave an exciting talk about Reverse Engineering C++ code. Can you read the assembly code and see the patterns for destructors/constructors, template instantiations, and other typical C++ constructions? This speaker can! Doing this is her everyday job, so don’t leave her with your secret code – she can get it!

On the first evening, we enjoyed a session full of lightning talks ranging from serious to funny, from technical to purely philosophical. The local community leaders were also happy to learn from Bryce Adelstein Lelbach on how to form a national body to represent Israel in the international C++ committee.

Beyond the talks

Core C++ had an exhibition representing well-known companies that often join C++ events as partners, sponsors, and exhibitors, including Conan/JFrog, Think-Cell, IncrediBuild, and JetBrains, among others. My colleagues and I we were happy to chat with everyone who stopped by our booth about CLion and ReSharper C++. Wee even managed to help out with some practical advice, for example, about how you can start using the compilation database format for Makefiles-based projects in your company.

On Friday, the activities only ran until lunch in Israel, including a fantastic training session from Diego and Luis from the Conan/JFrog team. It was interesting to learn about the capabilities of Conan. It also inspired me to come up with some feature ideas for the Conan plugin that was recently presented on our blog.

When the heat was mostly over, we sneaked a peak the old port and the narrow stone streets of the city. Big thanks go to the organizers for giving us a tour of the old city of Jaffa! The breathtaking view of downtown Tel Aviv from the hill was an unforgettable experience.

By the way, the Eurovision song contest was held in Tel Aviv on the same days as Core C++. The event organizers raffled a free ticket to the final show among the attendees. I don’t know if the winner did or did not go to the show, but Bryce shared on Twitter his story of sudden decisions and the visit to the Final.

Comments from Phil

It was my first time in Israel and all I can say is: it won’t be my last! The people were welcoming and, as a speaker, exhibitor, and attendee, I felt well-looked-after. The food was amazing and, of course, the weather was perfect.

As is often the case these days, I didn’t get to see many of the other talks, but from what I did see the quality was high – not just from the speakers but from the audience, too. As well as my own talk, “The Dawn of a New Error”, I ran a pre-conference class, “Accelerated TDD”, which was well attended and I had many thoughtful – sometimes challenging – questions.

For a first time conference, I think Core C++ got off to a great start – with only some minor teething issues. This is one to watch!

As a closing remark

C++20 is going to be the next Big Thing in C++ history with many giant features entering the standard. So our guess is that Core C++ 2020 will be even bigger and more successful. Good luck and thanks to all the organizers, speakers, and participants who made it happen this year!

Hi,

Last week we launched the Early Access Program (EAP) for CLion 2019.2. We thank everyone who already gave that EAP build a try and checked new things like parameter name hints, code assistance for .clang-format config files, go to address in memory view, and other enhancements and shared their feedback with us!

Today a new EAP build (192.4488.4) is available to download. As usual, you can download build 192.4488.x from our site, or use the Toolbox App, or use a snap package if you are using Ubuntu. A patch-update for those using the previous EAP build will be available shortly.

DOWNLOAD CLION 2019.2 EAP

C++ related improvements

Performance

While our major effort to improve performance is still ongoing, there are a few changes already available in the EAP build. First of all, we’ve removed lags in several cases of in-place Rename refactoring (CPP-16098). This has made the editor much more responsive.

Second, we’ve reduced the number of I/O operations when CLion collects compiler info in the full remote mode (when you run CLion locally and work with your project remotely). This has improved the performance of the Loading CMake step in remote cases.

Naming convention settings

In the first 2019.2 EAP build, we introduced reworked and more flexible naming convention settings. This time we’re polishing the UI/UX to make it possible to work with the settings table without using the mouse:

• Use -> / <- to navigate between the columns in the selected entry.
• Use Space to open the dropdown menu, and use Esc to close it.
• Use Tab to navigate between the options in the checkboxes, and use Space to select/deselect them.

And more

A few other C++ related fixes include:

• Move refactoring got further improvements, including a fix for the refactoring failing on global variables (CPP-16337).
• CLion shouldn’t add headers that are already included when refactoring or applying quick-fixes (when the Clangd-based engine is used) – CPP-15972.
• A fix for a regression with “OpenOCD Download & Run” configuration that stopped working.

Platform improvements

A new Plugin settings page

We’ve continued improving the Settings/Preferences | Plugins page:

• Plugin description is now located right next to the list of plugins:
  
• You can enable/disable all the downloaded plugins – simply click the gear button and select the corresponding action.
• Updates and Installed tabs are now merged, so you can find the update button right next to the plugin name on the Installed tab.

New look for the inspection tooltip

Have you noticed that the inspection tooltip was updated to make quick-fixes more discoverable? Now, it not only shows the problem description, but also provides you with the first available fix when possible (to apply, use Alt+Shift+Enter):

New default keymap on macOS

The default keymap on macOS has been changed to be the macOS 10.5+ keymap by default, instead of Mac OS X. We’ve changed the naming of the macOS keymaps accordingly:

• Mac OS X 10.5+ to the default, and
• Mac OS X to IntelliJ IDEA Classic.

There are also a few improvements in VCS support. Read about them here.

The full release notes are available here.

DOWNLOAD CLION 2019.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

Hi,

A new bug-fix update CLion 2019.1.4 has just been released! Build 191.7479.33 is now available to download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

DOWNLOAD CLION

Here’s a brief overview of the improvements and bug fixes:

• If you open a project from the invalid compile_commands.json file and then fix it manually, CLion will now suggest to auto-reload the project for you (CPP-16088)
  
• Changes in the Environment variables field of the Run/Debug Configurations are now saved correctly by the IDE (IDEA-208525)
• The font settings on Linux are now saved correctly by the IDE (IDEA-206180)
• The Find in Path dialog now closes when opening a project in the same window (IDEA-204277)
• A few IDE hangs are fixed

Full release notes are here.

Your CLion Team
JetBrains
The Drive to Develop

Hi,

A new CLion 2019.2 EAP build (192.4787.12) is now available. Download the full build from our site, install it via the Toolbox App, or use a snap package if you are using Ubuntu. A patch-update for those using the previous EAP build will be available shortly.

DOWNLOAD CLION 2019.2 EAP

On-Chip debug with GDB Server

As we announced previously, Embedded Development support is one of our main areas of focus right now. We already had some results to show you in v2019.1, with OpenOCD support and integration with STM32CubeMX, along with major improvements in the debugger like the Memory View.

We are now working on further improvements for general embedded debugging and a peripheral view. In this EAP build, we’ve implemented and polished a Run/Debug configuration for On-Chip debug with GDB Server. This covers such cases as:

• Using OpenOCD as a standalone GDB Server
• Using ST GDB Servers (you can get an OS version of the tools on GitHub)
• Using Segger J-Link GDB Server
• Using QEMU as a GDB Server
• Any other specific GDB Server

To get into debugging with GDB Server on your MCU, follow the simple steps:

1. Get a GDB Server installed on your machine.
2. Create an Embedded GDB Server Run/Debug configuration in CLion, and provide an executable path, arguments to run the server, and other appropriate settings:
   
3. Debug from CLion using this new Embedded GDB Server configuration:
   

Other improvements

Other notable changes include:

• CMake 3.14.5 is now bundled.
• For remote projects: changes introduced to the project externally (from outside the IDE) are now automatically synchronized to the remote host.
• The Member function can be static inspection was updated to avoid false positives in macros, for example when a Boost test macro is used (CPP-16229).
• The quick-fix that simplifies an expression was updated to behave correctly on ternary operator (CPP-16372).

The full release notes are available here.

DOWNLOAD CLION 2019.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

Hi,

A new CLion 2019.2 EAP (build 192.5118.29) is now available. Download the full build from our site, install it via the Toolbox App, or use a snap package if you are using Ubuntu. A patch-update for those using the previous EAP build will be available shortly.

DOWNLOAD CLION 2019.2 EAP

Debugger

When debugging your application, you can use the GDB/LLDB console directly from CLion. Now, command completion works when you press Tab or Ctrl+Space. Note that completion is provided by GDB or LLDB, respectively, while CLion simply gives you access to them.

For GDB:

For LLDB:

This build also introduces new, clearer icons for line breakpoints:

• 
  Line breakpoint out of debugging session (i.e. the session hasn’t started yet).
• 
  Line breakpoint is successfully resolved by GDB or LLDB using the provided debug symbols, and can be hit during the execution.
• 
  Line breakpoint is invalid, which means it can’t be resolved by GDB or LLDB and will never be hit. This might happen when the breakpoint is actually located out of the executable code or some debugging symbols are missing. CLion now detects such situations accurately and updates the icon on the fly (for example, when you load the proper debug symbols).

Naming Convention: Leading_upper_snake_case

We keep improving the naming convention settings (available via Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention). We’ve added a Leading_upper_snake_case style, which capitalizes only the first letter in the snake_case name, leaving the rest in lower case. Now it’s available along with the somewhat similar Upper_Snake_Case style and others.

Syntax highlighting for over 20 different languages

In your C++ projects, you may also have some code in other languages such as Rust, PHP, Python, Ruby, or Java. For some of these, CLion offers full-featured support, including:

• Bundled support for JavaScript, XML, HTML.
• Bundled support for Python.
• A plugin for Rust.

And yet in some situations no support is available. Well, we are now adding syntax highlighting for over 20 different programming languages, and it just works out of the box – no additional configuration required!

If you occasionally have to look through code written in a different language that is not supported in CLion, the IDE provides you with a friendly way to do it. Please note, however, that we don’t plan to extend the support for these other languages beyond syntax highlighting.

This support is based on TextMate grammars. The list of languages is available in Settings/Preferences | Editor | TextMate Bundles, and you can even add additional languages there. Of course, where more profound support is provided through the IDE itself or a plugin (such as Rust), it’s prioritized over a TextMate Bundle.

Shell Script Support

This EAP build bundles a Shell Script plugin, which enables rich editing support for shell scripts, including word and path completion, and even textual Rename:

The full release notes are available here.

DOWNLOAD CLION 2019.2 EAP

Your CLion Team
JetBrains
The Drive to Develop

As a tool vendor, we keep our finger permanently on the pulse with what’s going on in terms of key trends and important changes in the development world. As our IDEs cover lots of languages and technologies, there is a lot of ground to cover in all different directions. In the C++ team, we are obviously most interested in the C and C++ ecosystems and the related languages and technologies around them.

The Developer Ecosystem survey, which JetBrains runs yearly, aims to reveal all this kind of information. And today we are happy to share with you the results of the 2019 edition of this survey. Especially, we’ll take a closer look at the most interesting things we’ve found from this year’s study related to C, C++, and there’s even a bit about Rust too at the end.

VIEW THE STATE OF DEVELOPER ECOSYSTEM 2019 REPORT

Top C discoveries

The most interesting findings regarding C development were about the various tooling adoption. The project models distribution has mostly remained unchanged from 2018, however, Makefiles has secured itself a stronger position with 50%. A similar situation can be seen with the compilers, where GCC is trending, but Clang has grown its share from 23% to 35%:

A new question on dependency and package management tools was introduced this year that led to the discovery that for the C language 60% don’t use any dependency manager, while 22% rely on a system package manager. Nuget and Conan lead the list of specific dependency managers, with 6% of the share for each:

In terms of the IDE/text editors, all of the top-4 tools have strengthened their positions since last year, and again Vi/Vim is leading the trend:

We do wonder how many of the CLion users who answered this question are using the IdeaVim plugin to emulate the Vim mode and its key bindings

Top C++ discoveries

In C++ our first question is always: what about C++ language standards adoption? C++11 and C++14 are still very popular among C++ developers, but C++17 is now at nearly 30%. But more importantly, we keep asking respondents if they plan to upgrade to a newer standard in the upcoming year, and this year we found out that one in three developers is planning to adopt C++17 in the next 12 months!

Next year we’ll definitely add the upcoming C++20 (which is going to be a huge!), and see how many developers are bravely pioneering with it already. What about you, will you be one of them?

CMake and GCC are the top project model and compiler, respectively. However, we have to admit that CMake is still growing and is now at over 40%, and in terms of compilers Clang overgrew the Microsoft Visual Studio C++ compiler and reached 32% (which is still less than half of the GCC usages):

This year we introduced 3 new questions into the C++ section. The first was about dependency managers which had some interesting results. While the share of those using a specific dependency manager (not a system one) is similar to the C-language case, the leader board has a completely different distribution. Unlike the case in C, Nuget gains 12% here, while Conan only takes 5%:

Conan seems to be the fastest growing dependency manager these days, acquiring a bigger audience, especially on Linux and macOS. It will be interesting to check on this distribution in a year from now and compare. By the way, if you are interested in starting with Conan in CLion, read this guest blog post from our friends on the Conan/JFrog team.

The next two questions were taken from the C++ Foundation survey and both are dedicated to coding guidelines and code quality. Interestingly, in the question regarding the tools for guideline enforcement and code quality checks, in comparison with the C++ Foundation survey, we added the option ‘Tool provided by my IDE’. And it won with 38%!

This fact makes us (as a tool vendor) feel some extra responsibility and pushes us to provide wider integrations with various tools in our IDEs to make them easily accessible for our users.

Regarding the guidelines sources the C++ developers are actively using, Effective C++ series (books by Scott Meyers) leads, with the Google C++ Style Guide and the main project of C++ Core Guidelines following up right behind it:

By the way, before this data was weighted and processed, and all these nice infographics were drawn, I was processing the raw data and including a few other sources on my own, to prepare for my talk “C++ ecosystem: For better, for worse”, in which I try to identify the common aligning trends across all sources and analyze the reasoning behind them. I also dug deeply into the most popular areas of C++ language adoption to see how these trends are reflected there. The recording of this talk from ACCU 2019 is available here:

And what about Rust?

Rust is often considered a language that every C++ developers should learn, or at least pay attention to. How is the language doing now, a few years after announcing v1.0? First of all, it seems Rust is most popular for home and side projects, with only 14% using it for their production work. And these home projects are relatively small, as more than 90% of respondents who chose Rust as one of their primary languages work with codebases of fewer than 300 files.

But what types of projects are done in Rust? Utilities and scripts for systems programming seem to be the most popular application area. However, it’s interesting to see some active Rust usage in other areas:

The top languages used together with Rust on the same project are C++, Python, and JavaScript, each gaining 12%. Luckily enough, the IntelliJ Rust plugin, maintained by JetBrains, should cover all 4 of these languages at once, when installed in CLion.

That was the round up of some of the most interesting facts and you are welcome to check out the full results:

VIEW THE STATE OF DEVELOPER ECOSYSTEM 2019 REPORT

The raw data (obviously, anonymized) will be published later, so you can investigate and analyze it deeper on your own. If you have any comments or thoughts on the C, C++, or Rust facts, share them in the comments below!

Your C++ Team
JetBrains
The Drive to Develop