For the development of Synth Guitar my Ludum Dare Compo entry I decided to use JetBrains’ CLion as my IDE. Ever since writing my most popular post about MinGW-w64 and an older EAP version I played around with the thought of trying it out, but never found the right project for it. For a year or two I’ve been using Code::Blocks, but was never fully satisfied (among others also because of this), however whether CLion will replace Code::Block for me is still open.

The Setup

Before I had the EAP (Early Access Program) version installed on my notebook, but for my desktop PC I got to newly install the full version of CLion. As a student I get a non-commercial license for free, not only for CLion but for most of JetBrains’ products. If you however want buy CLion you’ll be paying €99 for a personal and €199 for a commercial license.

The download was very fast and with 138 MiB acceptably small. In comparison the offline installer for Code::Blocks with a compiler is 98 MiB and for Visual Studio you’ll be spending 6.9 GiB of your bandwidth, because Microsoft unfortunately doesn’t manage to provide a version just for C++.

The setup is very simple and I quite like the settings part when starting CLion for the first time. It allows you to directly change the options for design, version control integration and proper compiler detection. The later is one of the strong points compared to Qt Creator or Code::Blocks, because CLion supports and properly detected my MinGW-w64 installation, while it always seemed a bit of a hassle with Code::Blocks or you first needed to learn how Qt Creator actually handles toolchains and compilers. I wonder though why JetBrains couldn’t fully “support” the latest builds of MinGW-w64, not even with their 1.0.1 update. Then again I ignored the warning you get for it and have yet to run into any problems because of that. However CLion has stated that it can lead to freezes in certain situations.

The Build System

As someone who quite likes CMake, CLion’s native support is amazing and something I’ve been looking for quite some time. Of course Qt Creator comes with CMake support as well, but last I tried it, it did not integrate very well. With CLion you write your CMake code, link your favorite libraries through it and it will build and run just fine. One thing that seems a bit strange compared to most other IDE is, that CLion keeps by default all the build files in a temporary directory somewhere in your user directory. I mean it makes sense to not spam the source directory with all the CMake temporary files, however every now and then one might want to do something specific with the binary and has to go search it in there. My assumption is that CLion expects you to install the binaries instead. Luckily the directory can be changed with a few simple clicks if you know where to look.

One of the strange default options CLion ships with is that it allows multiple instances of the application to be run. So when you for example are debugging, you can also click on run again and the interface will switch to a different layout but still keep running in the background and a new instance will be loaded. During the Ludum Dare Compo I didn’t figure out that there’s a stop button if you switch to the correct tab, thus I ended up killing off GDB manually. I’m however really glad that pressing the stop button works, because pressing the stop button with Code::Blocks most of the time simply doesn’t work and you end up having to kill the process in the task manager. After the Compo I got a response from CLion that there’s an option to only allow one instance. This should in my opinion be the default setting given that single-instance applications are a lot more common.

The Editor

I had been using Vim for some web development during a year or so and gotten quite used to some commands, however I’m still not a Vim guru, but can’t argue with the fact that it can accelerate the code-writing quite a bit. As such I tried out CLion’s Vim-Emulator and I’ve to say it’s very good. My main critique would be, that it’s not obvious in what mode you’re currently in, as such it’s really annoying when you start typing commands or text and only then notice that you’re in the visual mode. I honestly never had that issue with Vim, so all I can assume is that the indicators aren’t well placed. Something else that got me quite annoyed is that in almost all cases when you click on the editor to get the focus back, it will (accidentally) switch to visual mode. This usually lead me to keep hitting the ESC key multiple times just in case, to ensure that I ended up in command mode. Since the Vim-Emulator is a general JetBrains’ feature and not strictly related to CLion it might also just be me, who isn’t used to it.

I’m not a big fan of getting my code automatically formatted, since my style usually doesn’t match with the coding style of a lot of other C++ developers. Until I realized that CLion allows you to customized the formatting rules to about every detail, it was quite annoying to work with at times. But the customization settings are in fact so detailed that you have to be careful to not overlook the option you actually want to change. What was a bit counter intuitive however is that in order to make any changes to the formatting, you first have to create a new style setting. The ones that are installed by default are read-only. Some indication for that would be helpful and would’ve saved me a trip to the all-knowing Google.

Performance

Performance is one of my main concerns with JetBrains’ IDEs. CLion is written in Java and even though they do a great job at hiding that fact, meaning the application doesn’t feel nor look like your standard cheap Java application, the resource allocation regarding RAM and CPU time is something you might not want to overlook. To be fair though, it’s impossible to tell whether Java itself has much to do with it or if there is more improvement possible in CLion’s codebase alone.

When opening my Ludum Dare project and just letting CLion sit there, the memory allocation idles at around 1000-1200 MiB. I assume most of it is used for source code meta information to make auto-completion or similar things faster. However Synth Guitar only uses SFML as library, which makes me wonder how the memory allocation scales for larger projects with a lot of different libraries. Personally it doesn’t seem like a big issue, after all there’s plenty of free RAM and it certainly is a better alternative to keep that data in memory compared to Visual Studio’s huge IntelliSense database files.

Something that got a bit of an issue during my Ludum Dare live stream, was the CPU usage of CLion. It’s nice to see CLion using no CPU time at all, when doing nothing, but it gets quite scary when you look at it while writing code. It will jump all over the place starting off at around 30% total CPU allocation and when you start compiling something it actually maxed out my CPU. If you do CPU-heavy things like encoding live stream video and audio data at the same time, such a high CPU load can become a bit of a problem. Again it’s just a speculation, but I’d claim that optimized C++ code instead of Java code, would reduce the CPU usage for the general editing part quite a bit.

Refactoring

Having worked with CLion for only a short period of time, it’s kind of hard to talk about features, since I have yet to discover most of them and put them to use. But since we’re talking about JetBrains here, I think the most talked about feature is their refactoring tool. I’m very used to manually refactoring everything and as such will first need to get used to the option of having code changed automatically, as well as learn what the tool can actually do. Something that I tried to do was rename my copy of a class, but apparently that’s still a missing feature. It might have been just my lack of knowledge, but using the refactoring tool with the Vim-Emulator seemed to cause some trouble.

Conclusion

CLion is a solid IDE for C++ development. You really notice the long experience JetBrains had with building code editors and yet they still managed to keep up to date with the “latest tech” (Git, CMake, MinGW-w64, etc.). I really hope that performance will improve a bit and am sure that some of these early bugs and missing features will get fixed over the next few months. I wish the developers of Code::Blocks and similar IDE would take a look at the look and feel of CLion and try to aim for that as well. Especially Code::Blocks seems to not have improved noticeable over the past years, which is quite a shame.

Everyone who works a lot with CMake should really give CLion a shot. I already started another project with CLion, so who knows maybe Code::Blocks will slowly drift into the “unused” section of my PC?

As a final note: JetBrains has in the meantime released version 1.0.1.