JetBrains Way to C++: The Inside Story of Our Journey
For the last 15 years, JetBrains has provided software developers with tools to make them more productive, work faster, and solve mundane tasks in an automatic way. From smart IDEs and code editors to teamware tools, the JetBrains portfolio covers many aspects of software development and supports a huge set of programming languages.
We now have many of C and C++ development use cases covered. All of our C++ tools natively support C and C++, including the C++11 standard (with some limitations), libc++ and Boost, and correctly handle macros and templates.
ReSharper C++ is an extension for Microsoft Visual Studio, supporting the Microsoft Visual C++ compiler and associated Visual Studio toochain. CLion, on the other hand, is a stand-alone cross-platform IDE that supports the GCC and Clang compilers (note that, on Windows, you’ll need either MinGW/MinGW-w64 or Cygwin), GDB (or LLDB since the 1.1 version) as a built-in debugger, and CMake as a build system and project model.
The days leading up to and following the new products’ releases were full of excitement, various expectations and forecasts, and then the joy and anxious tracking of the first sales. But let’s go backwards and see how we got to this point and where all these products’ first ideas were born.
How the Idea was Born
If you take a look at our timeline, one of the products you’ll find is called AppCode:
AppCode is an IntelliJ-based IDE for iOS/OS X development that went public in 2011. At that time, it was exclusively an Objective-C IDE, and we naively assumed that it would function adequately without a fully fledged C++ parser.
After the warm reception of the first Early Access Program (EAP) build, we received several requests for Objective-C++ support and, at the same time, we began to struggle with macros. Continuing to build on our language model in this direction, we surprisingly quickly came up with initial C++ support in AppCode:
It really was very basic support that included some STL auto-import support and some C++ completion. It was only AppCode 1.6 that brought libc++ support, correct parsing for the templates specialization, some C++11 features and Implement/Override for C++ code.
Up until version 2.5, C++ support was not our top priority in AppCode, and our improvements were more or less local. AppCode 2.5 in Fall 2013 brought to the stage Google Test, one of the most popular C++ testing frameworks, and more importantly, a general understanding of the vital importance of C++ support in the product. The parser was completely reworked and the refactorings greatly improved. With all of these changes, the idea of a separate C++ IDE first started taking shape in our minds.
Then came April Fools’ day when we made our first public announcement of a C++ IDE, leaving lots of people guessing if it really was a joke. Truth be told, at that point it could have gone either way!
We worked on two separate implementations of C++ support, during which some people moved from AppCode/CLion to the ReSharper team to work on ReSharper C++. Private and public previews started in 2014 for both products.
Making tools for developers involves a lot of listening. Early Access Program builds are our way to get you involved, collect your feedback, and make changes and improvements in the early stages of product development, where they can greatly influence product planning.
We ran surveys on AppCode/CLion and ReSharper sites asking our users about their use cases and preferences for C++ tools. Out of about 5,000 responses, over 3,000 received private builds to try and use. The public EAP builds were available for everyone and we are thankful for the close to 20,000 public preview users each month, and the 30,000 who used the final RC.
Expecting the worst but hoping for the best, we released both products to the public in April 2015. And the rest, as they say, is history.
To make sure we were doing the right thing, we had to learn more about the demand for C++ support, to understand the main needs of C++ developers. We performed in-depth market research study to help shape our roadmap. Some findings from the study are given below.
Demand for C++ across the industries:
Some existing competitors:
Other interesting facts and statistics revealed by this research have been recently published in our CLion blog.
The study helped us identify the areas in which we could provide real value for the C++ tooling space, to offer an interesting and powerful product to the community. We knew where to apply our expertise in code analysis, generation and refactoring to the stage, together with a large set of general features coming from our IntelliJ Platform (like web-technologies support, VCS, debugger features, issue trackers, terminal, and much more).
The Android Market
Inside the overall C++ development space, the market related to Android NDK development is impossible to ignore. Given that Android development in Java is fully supported in both IntelliJ IDEA Ultimate and Community Edition, we were soon asked about support for Android NDK.
In May 2015, Google announced at its Google I/O conference that Android Studio (which is incidentally based on the open-source IntelliJ Platform) will now provide support for Android NDK development—and this support is based on CLion.
You can see what’s on board in Google I/O development session recording.
We are still considering a CLion-based plugin for IntelliJ IDEA, and could possibly consider having the Android NDK there as well, but these plans are still uncertain and we cannot promise anything or give any estimates.
As we’ve already mentioned, at some point the CLion and ReSharper C++ teams split, giving way to two completely independent implementations of C++ parsers. This was caused by two completely different platform architectures, IntelliJ and ReSharper, and two different sets of ideas of how parsers can be implemented.
Of course, this begs the question — why didn’t we simply use libclang but instead ended up with two separate implementations of our own?
There are a couple of reasons for this. When we first started C++ support in AppCode, Clang’s release cycle wasn’t sufficiently reliable for using libclang from inside the IDE. At that time, Clang looked very promising, but not mature enough. In contrast, we already had some of our own infrastructure on the IntelliJ Platform, and we only need a parser fitting in smoothly.
However, the main reason for not using libclang was our caching needs. For the IDE to perform efficiently during refactorings and other operations, we needed symbol caching. And it’s not just about refactorings: finding context-aware usages of a symbol, building proper hierarchical views, providing navigation actions, and doing all of this in a reasonable timeframe requires good code context awareness and symbols caching. Clang does a good job of caching while working with individual files, parsing incrementally. But if we talk about the entire project, it starts parsing every file, just like a true compiler should do. And that’s where it can become problematic from inside the IDE.
The last reason is language injections, a feature that we have in IntelliJ Platform. For example, a string in C++ can be parsed as an SQL statement and not just as an ordinary string. We need these hooks to be implemented in the parser as well.
With all of these reasons, and years of expertise in language parsers that we have at JetBrains, we began implementing our own solution, and continue to do our best to improve the IDE user experience and parser correctness. We still haven’t given a final ‘no’ to libclang as we track various clang-based projects and solutions. And, incidentally, we plan to include Clang error annotations in CLion’s code inspections.
CLion 1.0 has received many reviews since its launch, and we know that a lot of people have made CLion their IDE of choice for C and C++ development. We greatly appreciate this, as well as all the feedback we’re receiving, both inspiring positive reviews, as well as constructive criticism which drives us to improve.
There were some interesting reviews, after which we fixed many things in the 1.0.x updates (like this one) and are progressing greatly with the 1.1 EAP (see this). We also appreciate all your comments on social media, blogs, and industry sites.
Some interesting release statistics from the first two weeks after CLion 1.0 the launch:
- Nearly 1000 licenses sold
- The 1.0 build was downloaded around 30,000 times
- The announcement on reddit got a fantastic 92% upvote (thanks!)
- The overview video got 10,000 views on YouTube
Before we wrap up, we want to express our appreciation of the really cool tools out there which are providing integrations with CLion. There are pioneers such as biicode (dependency manager for C and C++), and the recent PlatformIO (cross-platform code builder and the missing library manager), or the fantastic Arduino discussion happening in our tracker, where you can now find a few workarounds to develop for Arduino in CLion! By the way, if you are a Go fan, have you tried the Go plugin in CLion and the CMake+Go sample project from Glenn R. Martin?
Subscribe to Blog updates
Introducing JetBrains AI and the In-IDE AI Assistant
With the rise of generative AI and large language models (LLMs) this year, the landscape of not just the development industry but the creative industry as a whole has begun a transformation. Using this new technology to augment JetBrains tools was a no-brainer for us, and we see it as a logical n…
Amper – Improving the Build Tooling User Experience
Introducing Amper, a new experimental project configuration tool focused on usability, onboarding, and IDE support.
Remote Development 2022.1 is here
Last week we released new builds of Remote Development and JetBrains Gateway. In this release cycle, our team has focused on the overall solution quality and bug fixes. In addition to the quality improvements, the latest version has several noticeable new features, which we’ll highlight in this blog…
BeamSearch in code generation
In the previous article devoted to full-line code completion, we looked into the vocabulary that the neural net of our full line completion plugin uses for Python. However, just having 16384 tokens like self., or, s.append(, return value, and others described in the article is not enough to generate…