Phil Nash

The JetBrains Blog

Developer Advocate at JetBrains for CLion, AppCode and ReSharper C++

This if the third and final part of our Advanced Debugger series. If you haven't seen them, do catch: "Part 1: Suspended" and "Part 2: Dynamic" As well as the earlier, "Debugging Fundamentals" video. In this video we start by looking a direct access to the GDB or LLDB terminal, as well as running commands on start-up using .gdbinit or .lldbinit, then look at attaching to external processes and debugging on remote machines. We also look at debugging core dumps and running the debugger with root privileges. We hope you have enjoyed this series and have learnt some ways to make your

Following up on "Part 1: Suspended", of our Advanced Debugger series, Part 2 focuses on the dynamic part of working with breakpoints, watchpoints and setting the execution point. Because this an advanced series, we look beyond simply setting and removing breakpoints, and take a look at the different types of breakpoints we support, as well as all the options along with them. In many cases your breakpoints may not even need to break at all! Watchpoints let you break when data changes - or even when it is read. And being able to skip over lines of code - or even go back - by setting the executi

Back in October of last year I wrote "CLion Debugging – Part 1: Fundamentals", to introduce the everyday debugging features in CLion. It was "Part 1", because the promise was that I would follow up with a "Part 2", covering more advanced features. One thing you should never do is call something "Part 1" before you've written later parts! Part 2 has been a long time coming not just because it was bigger than expected, but so much bigger that I am, in turn, splitting it into three parts! Therefore I've rebased on "Beyond the Basics - Part 1", and

An important part of writing code is debugging. Despite the name this is not limited to just finding bugs in our code, but can help us to understand what the code is actually doing at runtime - often in a specific environment. While it's possible to do this to some extent using, so-called, "printf-debugging" (inserting code to write out messages and values to the console or a log file), that process is tedious, time-consuming, and very limited. Using a debugger well can make an order of magnitude difference in productivity at this stage - so it would be a shame not to learn our debug

One of the common questions we get is why there is no Docker integration in CLion? In fact CLion works very nicely with Docker! There might not (yet) be a specific, “use Docker”, button - but setting it up yourself is actually quite easy and straightforward - even if you’re a Docker newbie! Update: Staring with CLion 2021.3, you can configure special Docker toolchain in CLion. In this case, CLion will mount the project folder to it to avoid redundant source synchronization. Read on if you prefer written instructions, or watch this video with the same content: https://www.youtube.com/

In July of this year, in the German city of Cologne, the ISO WG21 committee approved the full draft of C++20. After Belfast, in November, we now have just one more meeting (in Prague) to deal with national body comments and get their approval. That means that, barring any catastrophes, C++20 will become the current standard sometime after February of next year. So C++20 is still in the future, but we now have a very good idea of everything that will be in it. Large sections of it have already been implemented in several compilers. GCC and Clang are leading the pack here (EDG is only a front

One of our most frequent feature requests for CLion is the ability to use project or build systems other than CMake. There are many good reasons for needing to use something different - but if you could only pick one we still feel CMake is the best choice. That’s not because we think it is perfect (although it’s worth noting that some of the issues that people have with it may be addressed by focusing on “Modern CMake”). Instead it’s because CMake is in very widespread use - especially in the open-source world, where it has become the de-facto standard. CMake also has the advantage that it

ReSharper C++ joined the ReSharper fold back in 2015 to bring the power of ReSharper to the world of C++ - and has been getting better ever since! For most people this has rounded out the ReSharper story within Visual Studio. However an odd gap remains. Odd because the worlds of C++ and C# are bridged by the interop language, C++/CLI, yet this has remained unsupported by the ReSharper family. Until now, that is! From 2018.2 (available now in the EAP) ReSharper C++ has initial support for C++/CLI. There are some limitations, so read on to find out more. Support is enabled by default, but

CLion is a cross-platform IDE for C++ development (which happens to have a built in test runner). Catch is a cross-platform test framework for C++. I'm the original author of Catch and am now working at JetBrains so this seems to be an ideal match! As of the 2017.1 release I'm pleased to say that CLion fully supports Catch as a first class test framework. That means you can create Catch test runner configurations that let you specify test names (with wildcards) or tags, see the results of your test runs, hierarchically, in the test runner window, and can re-run failing tests, or the test

The JetBrains Blog

Phil Nash

CLion Debugging – Beyond the Basics – Part 3: Beyond Local

CLion Debugging – Beyond the Basics – Part 2: Dynamic

CLion Debugging – Beyond the Basics – Part 1: Suspended

CLion Debugging – Part 1: Fundamentals

Using Docker with CLion

C++20 and ReSharper C++

Working with Makefiles in CLion using Compilation DB

C++/CLI support comes to ReSharper C++

To Catch a CLion