Deleaker 2019.20: Integration with Qt Creator

Today we are pleased to present our clients the next version of Deleaker. Deleaker 2019.20 is coming with the full support of Qt Creator. New version of Deleaker can work as a Qt Creator plugin helping developers to find leaks without leaving Qt Creator.

You can get Deleaker for Qt Creator right now at the download page.

It is a very important milestone in the Deleaker’s lifespan. The fact is that from the very beginning one of the most important features of Deleaker was to let a developer search for some leaks in the code without leaving the IDE.

Fortunately, Qt Creator can be extended by third party plugins. It’s time for Deleaker to be a part of Qt Creator.

Qt Creator uses either Visual C++ compiler, or MinGW, to compile C++ code. These compilers produce debugging information in different formats. Visual C++ compiler generates PDB files. MinGW uses DWARF format. Deleaker supports both formats.

Qt Creator doesn’t use its own debugger but external debuggers instead, CDB or GDB. Deleaker cooperates with any of them to receive debug events notifications.

Let’s go on. The updated installer identifies the installed versions of Qt Creator, from which you can choose the ones you would like to integrate Deleaker with:

Launch Qt Creator. In the main menu there is a new item “Deleaker”:

Deleaker menu item in Qt Creator

Let’s see how Deleaker is looking for leaks. Create a new project, introduce a leak, allocating one instance of QPushButton. Imagine that someone allocated QPushButton but then decided not to add it to a layout:

Add leak in Qt / C++

Start debugging, close the application. Deleaker automatically takes a snapshot, and we get expected list of leaks. For each leak Deleaker shows the complete call stack:

Taking Memory Snapshot

Double clicking or using the context menu makes it easy to go directly to the corresponding line of code:

Feedback is genuinely useful and unbelievably appreciated, please write us.

Deleaker 2019.2: Integration with RAD Studio. Find Leaks in Delphi and C++ Builder.

Today we are happy to announce the next Deleaker release. Deleaker 2019.2 is coming with the full support of RAD Studio: Delphi and C++ Builder.

You can get Deleaker for Delphi / C++ Builder right now at the download page.

Download Deleaker for Delphi and C++ Builder

It is a very important milestone in the Deleaker’s lifespan. The fact is that from the very beginning one of the most important features of Deleaker was to let a programmer search for some leaks in the code without leaving the IDE. If beforehand Deleaker worked as an extension in Visual Studio only, now it integrates with RAD Studio. This means that you can search for memory leaks and resource leaks in both Delphi and C++ code directly in RAD Studio. Integration with versions from RAD Studio 2007 to the newest 10.3 Rio is supported. At the same time, Deleaker Standalone successfully finds leaks in code, compiled by versions of Delphi, starting with Delphi 7, and by versions of C++ Builder, starting with C++ Builder 6.0.

Let’s go on. The updated installer identifies the installed versions of RAD Studio, from which you can choose the ones you would like to integrate Deleaker with:

Deleaker Installer for RAD Studio

Launch RAD Studio 10.3:

RAD Studio with Deleaker Splashscreen

In the main menu there is a new item “Deleaker”:

Deleaker Menu in RAD Studio

Let’s see how Deleaker finds leaks in Delphi code. Create a new project, add a button, then allocate memory in the code, executed by pressing the button:

Add some leaks

Start debugging, then press the button, close the application. Deleaker automatically takes a snapshot, and we get the correct list of leaks. For each leak Deleaker shows the complete call stack:

Taking Snapshot

Double clicking or using the context menu makes it easy to go directly to the corresponding line of code:

Go to source code

Feedback is genuinely useful and unbelievably appreciated, please write us.

Download Deleaker for Delphi and C++ Builder

About smart pointers in C++

About smart pointers in С++

An application can use different resources – memory, handles, network connections and other stuff that is better to free after usage. C++ is a flexible language that allows a C++ developer to do a lot but makes him care about many things, including freeing resources. This article is dedicated to smart pointers.

Well, what can you do with resources?

To allocate but not to free

You may just live resources alone: as soon as a process exits, OS frees resources itself. It might look incorrect, but this approach can be used for the resources that are involved all the lifetime of a process.

It quite often occurs to memory – static variables and singletons are common things. It’s such a good deal – any time a program can call a singleton and check it. A singleton is always here.

Freeing manually

Like in good old times – if one had opened a file it was necessary to close it. Objects’ lifetime can be long and non-trivial because of the multithreading and exceptions. It’s hard not to make a mistake.

Reference counting

The idea is to count references to an object and once the count sets to zero, you free the object. There is a standard std::shared_ptr class in C++, below we will examine it.

Any problems? Yes, some. If object A has a reference to object B and vice a versa (circular references), then the reference counts of both A and B never set to zero, and thus A and B never get free .

Despite the primitiveness and the non-universality, this approach is widely used in languages like Python and frameworks like .Net due to the garbage collection.

However, in C++ you can use standard class std::weak_ptr to avoid circular references problem. Let’s talk about std::weak_ptr a bit later.

Garbage collection

On the one hand, a program doesn’t free objects explicitly, that makes a code easier,  particulary, when one deals with tree structures, lists, and, of course, lock-free structures.

On the other hand, a developer can rely on the garbage collection only in case of the memory freeing: if, for example, a file is opened, it’s much better not to wait when the garbage collector decides to close the handle, but to close the handle explicitly.

С++: std::unique_ptr

In C++ it’s easy to create an object on the stack:

struct DebugObject {
    int m_i;

    DebugObject(int i) : m_i(i) {
        std::cout << "DebugObject(" << m_i << ") created\n";

    virtual ~DebugObject() {
        std::cout << "DebugObject(" << m_i << ") deleted\n";

void f() {
    DebugObject p(1);

Once f() is finished, p goes out of scope and it gets destroyed.

Unfortunately, there are some obstacles. An object be destroyed right before exiting from f(), this can’t be changed. If you want to return the objects from a function, or to save it, a copy of the object is created.

It’s ok for lightweight objects like a number pair but imagine an array with billion items – you can’t do it this way. A stack is limited, copying large objects again and again takes a lot of time.

Nevertheless, destruction of an object on a stack when it goes out of scope is really a powerful feature of C++. Even if an exception is thrown in f(), the object p gets destroyed anyway and its destructor is called. Imagine a wrapper class that is created on a stack, which stores an object pointer (allocated from a heap), and destroys the object when “wrapper” goes out of scope. This wrapper class is std::unique_ptr.

With the help of std::unique_ptr you can write:

void f() {
        // It's correct in с++11
        std::unique_ptr<DebugObject> p1(new DebugObject(1));
        // make_unique is available in с++14
        auto p2 = std::make_unique<DebugObject>(2);

In this code all objects are freed correctly, and it doesn’t matter what might happen during the execution.

Custom deleter

It would be strange if there were no way to specify a custom function to delete an object:

void customDelete(DebugObject *p) {
     std::cout << "CustomDelete()\n";
     delete p;

void f() {
    std::unique_ptr<DebugObject, void(*)(DebugObject*) > p(new DebugObject(3), customDelete);

    p.reset(new DebugObject(4));

    std::cout << "raw pointer size:" << sizeof (DebugObject*) << "\n";
    std::cout << "unique_ptr with deleter size:" << sizeof (p) << "\n";

It’s important to mention a reset method: it overwrites an old pointer with a new pointer. The deleter function is called for an old pointer if it’s not null.

The custom deleter function std::unique_ptr let free not only objects, but any kind of resources, e.g. handles.

An example of a closing handle:

struct FILEDeleter {
    void operator()(FILE *pFile) {
        if (pFile)

using FILE_unique_ptr = std::unique_ptr<FILE, FILEDeleter>;

FILE_unique_ptr make_fopen(const char* fname, const char* mode) {
    FILE *fileHandle = fopen(fname, mode);
    // fileHandle will be nullptr if error
    return FILE_unique_ptr(fileHandle);

void f() {
    std::cout << "unique_ptr with stateless struct as deleter: " << sizeof (FILE_unique_ptr) << "\n";

Notice that FILEDeleter is stateless: FILE_unique_ptr stores just one pointer of a file.

Returning from a function

std::unique_ptr can be returned from a function. Due to move semantics std::unique_ptr transfers object owning, set pointer to null, and the object itself is not destroyed on exit from makeObj(). The object will be destroyed on exit from function f():

std::unique_ptr<DebugObject> makeObj(int n) {
    return std::make_unique<DebugObject>(n);

void f() {
    std::unique_ptr<DebugObject> p = std::move(makeObj(5));
    std::unique_ptr<DebugObject> p2 = makeObj(6);
    std::unique_ptr<DebugObject> p3(makeObj(7));

    auto p4 = std::move(p);
    // auto p5 = p; //compilation error!

Get raw pointer

void f() {
    auto p = std::make_unique<DebugObject>(8);

    std::cout << "DebugObject.m_i == " << p->m_i << "\n";
    DebugObject *inner_p = p.get();

It is simple. It is worth mentioning that p continues storing a pointer, and DebugObject will be deleted on exit. In case you don’t want to destroy an object, use the method release. As in case of usual pointers, it’s possible to access to fields and methods via operator ->.

void f() {
    DebugObject *raw_ptr = nullptr;
        auto p = std::make_unique<DebugObject>(9);
        raw_ptr = p.release();
    std::cout << "Object alive yet\n";
    delete raw_ptr;

Casting to bool

It’s quite handy that std::unique_ptr is similar to raw pointer – one can cast it to bool (if it’s nullptr, the result is false; otherwise it is true):

auto p = std::make_unique<DebugObject>(10);

if (p) {
    std::cout << "p isn't null\n";

Object owning

To make things simple, it’s a good idea to decide who owns an object, for example:

class Owner {
    DebugObject *m_p;
    // DebugObject is an abstract class, size is unknown

    Owner(DebugObject *p) : m_p(p) {

    ~Owner() {
        delete m_p;

Well, let’s rewrite the code using std::unique_ptr:

class Owner {
    std::unique_ptr<DebugObject> m_p;

    Owner(DebugObject *p) : m_p(p) {

The code is much simplier now because std::unique_ptr is stored by value, not by a pointer, the destructor Owner::~Owner() calls the destructor of m_p.

A few words about object owning

In Rust there are so-called linear types: Such types can be used only once. Speaking about object owning, if someone owns an object, it’s possible to transfer ownership to another owner only once .

Unfortunately, there is no such a feature in C++. One can make two unique pointers of the same object:

void f() {
    auto* p = new DebugObject(11);

    Owner o1(p);
    Owner o2(p);
    // bad way

In this case one object is destroyed twice which is wrong, of course. To avoid such thing it’s better to wrap a pointer by std::unique_ptr not at an arbitrary place, but at the start position instead.

class Owner2 {
    std::unique_ptr<DebugObject> m_p;

    Owner2(std::unique_ptr<DebugObject> &&p) : m_p(std::move(p)) {
        std::cout << "I'm owner of " << (m_p ? "object" : "nullptr") << "\n";

void f() {
    auto p = std::make_unique<DebugObject>(12);

    Owner2 realOwner(std::move(p));
    Owner2 fakeOwner(std::move(p));
    // at least it doesn't crash

In С++11 rvalue references and move semantics has been introduced.

std::vector<int> a{1, 2, 3};
std::vector<int> b = a;

assert((b == std::vector<int>{1, 2, 3}));
assert((a == std::vector<int>{1, 2, 3, 4}));

For example, standard std::vector stores pointers of the array beginning, end and the count.

The content of the vector a (i.e. the whole array of data inside it) will be copied, and b will contain another pointers. But if vector a is not planned to be used later, we can name it rvalue reference and, instead of making a deep copy, just copy the pointers. Actually, the poitners are not just copied, but replaced between a and b.

To convert an object to rvalue reference explicitly you can write:

std::vector<int> c{1, 2, 3};
std::vector<int> d = std::move(c);

// don't use objects after they are moved

assert((d == std::vector<int>{1, 2, 3}));
assert((c == std::vector<int>{4}));

So, at the second line values of empty vector b and non empty vector a are exchanged. a has been rvalue and it has been changed by assignment.

What are we talking about? Alike, std::unique_ptr transfers owning being assigned, and we can’t make two similar std::unique_ptr-s from a single one: one of them will contain nullptr.

In the sample above fakeOwner will contain nullptr and realOwner will be the only owner.

Of course, it would be great if C++ prohibited the usage of p after the first std::move(p), but, unfortunately, C++ doesn’t support it (yet?).

Well, at least we can’t delete an object twice, and a developer suspects that something is going wrong when seeing at std::move(p).

A small excursus on Rust: the idea of owning an object helps to implement state machine – for example, it’s possible to have class “closed file” with the only method “open” and the class “opened file” with the methods for reading and closing. And the method “open” will take the ownership of closed file and return opened file, and vice a versa. This approach allows to use resources with more number of states than usual “resource is allocated, resource is freed”.

C++: std::shared_ptr

As mentioned above, std::shared_ptr is a wrapper of a pointer with the reference count.

void f() {
    std::shared_ptr<DebugObject> ptr1(new DebugObject(0));

    std::cout << ptr1.use_count() << "\n"; 
    // 1
    std::cout << ptr1.unique() << "\n"; 
    // true

        auto ptr2 = ptr1;
        std::cout << ptr1.use_count() << "," << ptr2.use_count() << "\n";
        // 2, 2
        std::cout << ptr1.unique() << "," << ptr2.unique() << "\n";
        // false, false

    std::cout << ptr1.use_count() << "\n";
    // 1
    std::cout << ptr1.unique() << "\n";
    // true

The difference between std::shared_ptr and std::unique_ptr is that std::shared_ptr is heavier: it stores also a pointer to an additional object, a control block, that contains the reference count (count of std::shared_ptr instances that points to the same object)

When the reference count become zero, the object gets destroyed. The reference count is changed in a thread-safe manner, that’s why working with std::shared_ptr is slower than with raw pointers and std::unique_ptr.


std::shared_ptr<DebugObject> p1(new DebugObject(0));
auto p2 = std::make_shared<DebugObject>(1);

The second approach is more efficient. Why? In the first case memory is allocated twice (two pieces) – for DebugObject and for a control block.

std::make_shared immediately allocates single piece of memory that contains both an object and a control block. The disadvantage is that it’s possible to free this memory for both the object and the control block.

Wait, why it’s necessary to keep control block alive after destroying the object? The thing is that a control block also contains a count of weak references.


void f() {
    std::weak_ptr<DebugObject> w;
        std::shared_ptr<DebugObject> p(new DebugObject(2));
        w = p;
        std::cout << w.use_count() << "," << p.use_count() << "\n";
        // 1, 1
        std::cout << (w.expired() ? "true" : "false") << "\n";
        // false
    std::cout << (w.expired() ? "true" : "false") << "\n";
    // true
    std::cout << w.use_count() << "\n";
    // 0

In the sample above the reference count has become zero and the object is destroyed. But the count of weak references is not 0 and the control block still exists (it will be deleted only when the count of weak reference becomes zero).

The object pointer is hidden inside std::weak_ptr and can’t be accessed from the outside. To get it one must call the method lock – it returns std::shared_ptr and the object can’t be destroyed suddenly (if it has been destroyed already, the std::shared_ptr with nullptr will be returned).

std::weak_ptr can be used to avoid circular references – for example, А contains std::shared_ptr of B, Bstd::weak_ptr of A.

Thread safety

  • std::unique_ptr is not thread safe. If one calls e.g. std::move in the two threads at the same time, one can get two pointers of the same object. However, std::unique_ptr is fast.
  • std::shared_ptr – a reference count in a control block is incremented and decremented thread-safely. But there is one thing: std::weak_ptr contains two pointers (of the object and of the control block), and reading it in one thread, while someone is writing it in another thread, is not a good idea. On the other hand, one can read std::shared_ptr from several threads at the same time. std::shared_ptr guarantees that, when all owners are destroyed, the object is destroyed as well.

For reading/writing std::shared_ptr from different threads use synchronization mechanism: mutexes and others. Also there are standard helpers like std::atomic_load, std::atomic_store and std::atomic_exchange.

These helpers use blockings, and std::atomic_exchange is atomic only from the points of view of others “atomic_*” functions. If one of them is used, it’s better to use them everywhere.

About possible leaks

In complex expressions the order of execution is not defined:

func(std::shared_ptr<Lhs>(new Lhs("foo")), std::shared_ptr<Rhs>(new Rhs("bar")));

It’s possible, that Lhs(“foo”) has just been created but shared_ptr(..) hasn’t been called yet, and creation of a new Rhs(“bar”) will throw an exception. So Lhs(“foo”) will not be deleted as a smart pointer hasn’t been created yet.

If using std::make_shared(“foo”) everything will be fine:

func(std::make_shared<Lhs>("foo"), std::make_shared<Rhs>("bar"));

Another variant is not to write a long expression but split it onto three parts – creation pointers of Lhs, Rhs and call of func(…).
In this case smart pointer of Lhs is created earlier than constructor of Rhs is called. The same for std::unique_ptr.

Read more about that here:


The usage of std::unique_ptr simplifies a code and reduces the possibility of memory leaks. This kind of pointers is very lightweight – its size is equal to the raw pointer’s size (In case when the custom deleter is used – the size is equal to the size of two raw pointers). You can use it wherever the only owner of an object is supposed.

If the reference count is required, one can use std::shared_ptr along with std::weak_ptr to avoid circular references problems.

Deleaker 2018.27: new command line tool, bug fixes

The new Deleaker 2018.27 is available with new command line tool and several bug fixes.

The new command line tool makes Deleaker a part of a test suite.

Our customers used to ask if we were going to add support of running Deleaker from the command line? Such a feature is quite useful when it’s necessary to run Deleaker with an automated testing suite. It will require Deleaker to be launched from the command line.

That is why DeleakerConsole.exe, a command line tool that runs a process under Deleaker and produces leaks reports, has been created.

You can find the tool comprehensive documentation here.

Please write us if you find some features missed.

Case sensitivity.

Deleaker uses the Debug Help Library to retrieve names of source files. Sometimes these names are returned by the library in lower case.

Is it a problem? Sometimes.

For example, it causes a weird problem if you use SVN. It is a case sensitive tool: SVN can store two files with names that differ in case only.

Imagine, Deleaker shows source file name in incorrect case (the Debug Help Library has given this name!), then one opens the file from Deleaker in Visual Studio, edits it and finally saves. The case of the file name has changed. In fact the file has got a new name from SVN’s point of view.

Now Deleaker cares about the file name case and opens it using the correct name.

As usual updated version available on the download page.

Deleaker 2018.22: Resource Usage Graph

We’re excited to announce you the latest update of Deleaker that includes the resource usage graph.

Developers often ask if it’s possible to watch the memory usage of a process. Now with the help of the graph one can visually inspect the memory usage, GDI and USER32 resources, handles:

In Visual Studio the graph respects current color scheme:

You can easily switch between different resource types:

As usual updated version available on the download page.