This One Thing Is Possible With Concepts, but Not With SFINAE

enable_if Fans Are Furious

Notice that I did say “seemingly”? Yes, there is one thing which makes concepts superior. There is one thing concepts allow you, which is impossible with pre-C++20 SFINAE. It is extensibility.

Say you have a simple template:

template <typename Mutex>
struct lock_guard {
    Mutex& m_mutex;
    lock_guard(Mutex& m) : m_mutex(m) { m_mutex.lock(); }
    ~lock_guard() { m_mutex.unlock(); }
};

… and now you want to make it work with MFC-style mutexes whose methods are called Lock and Unlock, capitalized. What can you do? You can specialize individually for all specific lockable classes you need, but that’s a lot of copy-pasted code. Had the author of lock_guard envisioned your need for extensibility, they could’ve created lock_guard like so:

template <typename Mutex, typename SFINAE_Hook = void>
struct lock_guard {
    Mutex& m_mutex;
    lock_guard(Mutex& m) : m_mutex(m) { m_mutex.lock(); }
    ~lock_guard() { m_mutex.unlock(); }
};

and now you can use partial specialization to make it work:

template <typename MFCMutex>
struct lock_guard<MFCMutex, std::enable_if_t<is_pascal_case_lockable_v<MFCMutex>>, void>> {
    MFCMutex& m_mutex;
    lock_guard(Mutex& m) : m_mutex(m) { m_mutex.Lock(); }
    ~lock_guard() { m_mutex.Unlock(); }
};

Without concepts one has to think and try to envision extension points like this one. With concepts one can just do:

template <lowercase_lockable Mutex>
struct lock_guard {
    Mutex& m_mutex;
    lock_guard(Mutex& m) : m_mutex(m) { m_mutex.lock(); }
    ~lock_guard() { m_mutex.unlock(); }
};

And this is both an extension point and prouduces nice¹ compilation errors when something can’t be locked/unlocked like this.

“Wait”, I hear people saying, “I’m not the author of lock_guard! In this example the author of lock_guard ‘envisioned’ that it could be extended by constraining its argument with a concept, just like the author of lock_guard<Mutex, SFINAE_Hook> did.”

We’ve come to The Thing™: With concepts you can partially specialize existing templates with a single template argument.

Partially specialize single template argument? Yes, what used to be an oxymoron pre-C++20 is now a legitimate statement.

template <typename MFCMutex> requires pascal_case_lockable<MFCMutex>
struct lock_guard<MFCMutex> { ... };

Tada! This works with the initial example of lock_guard<Mutex>.

Now, granted, this is pretty niche. I don’t think I’ve ever had the need to partially adapt templates outside of my codebase in my entire career. In similar cases I’ve always been in a position to add the SFINAE hook if a template didn’t already have one.

So, OK. Let’s adopt the concepts everywhere mindset. If we are the author of lock_guard, why rely on partial specialization? Why not just define it as only valid for lowercase_lockable and leave it to users to extend their code with entirely new definitons if needed?

There’s a catch. With code written like this, you lose the ability to forward declare things.

With This One Trick You Lose the Ability to Forward Declare Things

People Who Care About Compilation Times Are Furious

Now, you can still forward declare the templates themselves. template <lowercase_lockable Mutex> struct lock_guard; is perfectly fine (well, as long as lowercase_lockable is defined), but templates are rarely forward declared. It’s much more common to forward declare the template arguments.

Here’s a use case:

template <typename T>
struct intrusive_shared_ptr {
    ...
    ~intrusive_shared_ptr() {
        if (m_obj)
            m_obj->release();
    }
};

...

class foo;
using foo_ptr = intrusive_shared_ptr<foo>;

You might be tempted, as I was, to constrain the T with concepts:

template <ref_countable T>
struct intrusive_shared_ptr { ... };

… but then our foo_ptr cannot be declared. foo is incomplete. An incomplete type does not satisfy the ref_countable concept.

Oh, well…

So the guideline I use now is:

For the sake of forward declarations, don’t constrain class template arguments, unless you speicifically know that they will not be forward declared

Do I still make use of concepts? Yes. I do prefer their error output, and I enjoy syntax sugar. Here’s how intrusive_shared_ptr looks following the guideline:

template <typename T> // T can be forward declared
struct intrusive_shared_ptr {
    static_assert(ref_countable<T>) // nice error message, thank you
    ...
    ~intrusive_shared_ptr() {
        if (m_obj)
            m_obj->release();
    }
};

As for the other example, I think lock_guard should definitely fall into the “I know its args won’t be forward declared” category. I would define it as template <lowercase_lockable Mutex>.

Today I got hit by the weirdest one.

This is the repro:

#include <memory>
#include <type_traits>

template <typename stream>
struct io {
    io(stream) : b(false) {}
    alignas(64) bool b;
};

int main() {
    auto pi = std::make_unique<int>(543);
    using iio = io<int>;
    io x(7);
    static_assert(std::is_same_v<decltype(x), iio>);
}

Build this with /fsanitize=address (and a contemporary standard) and you get a stack-buffer-overflow.

The program executes fine, mind you. There is no actual error. It’s just the address sanitizer that complains here.

Now, address sanitizer bugs do happen, and I’ve been hit by several with various degrees of annoyance, but this one is especially weird. Let me show you why.

If you remove the heap allocation (the first line in main), this produces no errors. If you remove the alignment of the bool in io, this produces no errors. So far, so good. Heap allocations and exotic alignments are understandable sources of address sanitizer confusion. The crazy thing here is that if you don’t use template argument deduction in io x(7);, and instead specify the type manually as in io<int> x(7);, this produces no errors as well.

This leads me to believe that there is a compiler bug involved as well. There is absolutely no reason for those two lines to produce different code. But indeed they do, as can be seen in this Compiler Explorer demo. Note the subtle differences in stack initialization in both cases. I, for one can’t see anything wrong in both outputs except that they’re subtly different. Someone more knowledgable is welcome to chime in.

I posted a report here and a complete demo with repro (and non-repros) can be found here.

Weird, huh?

I guess the aswer is: almost.

This time I was triggered by handling exceptions from coroutines.

So, you want to throw an exception from a coroutine. The wisdom says that in your promise_type you have to implement unhandled_exception, store the exception in std::exception_ptr, and then rethrow it or handle it otherwise when it’s appropriate. This is a decent approach in many situations. However for synchronous coroutines (think generators) I’d say it’s overcomplicated to the point of being stupid.

In a synchronous coroutine I should be able to implement unhandled_exception like so:

void unhandled_exception() {
    throw; // beauty
}

…and make my exception somebody else’s problem. However the standard didn’t allow this initially. Not expclicitly at least. The coroutine state after such a move was simply not specified. Is it suspended? What does it mean when final_suspend is not called? Apparently no one had thought of this trivial use case. Now, the complex ones, sure, but the standard committee is beyond trivialities…

Anyway.

So, someone finaly figured out that it is stupid to require the overly complicated code for something as trivial as propagating the exception, made a defect report, and it was even reflected in the standard… in 2022, but at least it was retroactive, which means that it applies to C++20 even though it came out later. C++20 conforming compilers must implement it. For example it is available in GCC 11.4.

Clang prior to 17 however, doesn’t care. Doing this in pre-17 clang will leave the coroutine in a crazy state where its local variables want to be destroyed by both the exit of scope from throw and by handle.destroy().

OK. So pre-17 clang doesn’t work. If you target Apple clang, you can’t use the pleasant rethrow. As of this writing stable Apple clang is at 16, and with the speed of Apple, by the time it reaches 17 we will have colonized Mars.

Back to storing it into std::exception_ptr I guess.

However(!), what no one had thought of was what to do when you throw an exception from an eager coroutine. That would be one which does not suspend on initial_suspend or at all. Now, the defect report from above seems to cover it well. You can rethrow in unhandled_exception so it should just work, right? Well, as is the norm with C++, it’s not so easy. From a pedantic reader’s perspective, it is not defined what happens with the coroutine state. Since you throw before the first suspend, it should be the compiler’s job to own (and free) the coroutine state, but since there is an exception and the coroutine must be “suspended at its final suspend point”, it should be the user code who owns (and must free) the state. As a result no one really owns the state and it may be leaked.

I’m not the first one to notice this. There is a defect report about this, too, but it’s not yet reflected in the standard. This literally means that according to the standard, rethrowing from an eager corotuine before the first suspend can be a leak and there’s nothing you can do about it.

Sigh.

Ok, but since you want to target Apple clang (silly you), you accepted that you’re storing the exception in a pointer and handling it later, right? Can this be done here, too? Yes it can! If you don’t rethrow from unhandled_exception, you own the state. You can free it and there will be no leak. But when will you handle it? At the first suspension? What if there is none? But more importantly, this breaks RAII. Let me tell you why.

A class and a coroutine are functionally (well… mostly) equivalent. Sure it’s not practical to forget about classes and always use coroutines, but it can technically be done:

template <typename T, typename Alloc = std::allocator<T>>
vector_coro vector() {
    T* mybegin = nullptr;
    T* myend = nullptr;
    ...
    while (true) {
        auto method = co_await method_call{};
        if (method.type == vector_coro::methods::size) co_yield myend - mybegin;
        if (method.type == vector_coro::methods::begin) co_yield mybegin;
        ...
    }
}

Yes, it’s an abomination, but still, possible.

So yeah. They are equivalent. Some of these equivalencies are not as contrived as methods. For example, the code in a corotuine before its first suspend is equivalent to a class’s constructor. That’s obvious when you think about it. And in C++ the only way to handle an error in a constructor are exceptions.

Some people are exception opponents. According to them exceptions are a bad pattern to do error handling. I, for one, am not one. Certainly there are many examples where exceptions are a bad idea¹, but I’d argue that in some cases they are actually quite useful. That’s mainly errors due to user input… but I really don’t want to turn this into an exceptions vs no-exceptions post.

Exceptions opponents have devised many ways of dealing with errors in constructors. They all boil down to this pattern:

myobj obj;
obj.complete_initialization(); // ... and handle errors from this call however you see fit

For example that’s how std::fstream works. You open a file and then check if the stream is bad. That complete_initialization is not necessarily a class method. It could be get_last_error, it could be checking an output arg of the constructor. The pattern is that after the constructor completes, you do something else and only then can you have a complete² object. Well this is not RAII. I consider having this intermediate object state error prone and clunky³. If you like it, then sure, the standard allows you to safely write your eager coroutines in the manner you know and love:

auto obj = generate_stuff_coro(data);
if (obj.has_eager_errors()) {
    // handle them
}
else {
    // generate away
}

I hate this. I want to have the exception thrown from generate_stuff_coro exactly the same way I would want the exception thrown from a constructor. The standard doesn’t allow this. Not without the threat of a leak, at least.

So what can we do?

• Begrudgingly use the complete_initialization pattern? NEVER!
• Live with the leaks? They are expected to be small and rare. This is tempting and likely acceptable in many pieces of software, but the problems with deliberate leaks is mainly that tooling (leak detectors and sanitizers) will flood you with this false positive (in practical terms) forever. I don’t like it.

So I decided to do something else. Create a non-standard experimental solution which works in practice. That is, write some code: an eager coroutine which can throw before its first suspend, or after, or not throw at all, and tweak it until it works on popular compilers with no crashes or leaks. These tweaks would be pretty evil and work around specific compiler idiosyncrasies, but since the standard can’t help me, I guess I have to get creative.

Here’s the repo in which I did it.

And how did it go?

First I tested how the simplest approach fares. The one I would expect to work after all standard issues are resolved. Here’s my trivial wrapper:

struct simple_wrapper {
    struct promise_type {
        int last_yield = no_value;

        simple_wrapper get_return_object() {
            return simple_wrapper{std::coroutine_handle<promise_type>::from_promise(*this)};
        }

        std::suspend_never initial_suspend() noexcept { return {}; } // eager
        std::suspend_always final_suspend() noexcept { return {}; } // preserve the final yield

        std::suspend_always yield_value(int v) noexcept {
            last_yield = v;
            return {};
        }

        void return_void() noexcept {}

        void unhandled_exception() {
            throw; // perfection
        }
    };

    std::coroutine_handle<promise_type> handle = nullptr;

    explicit simple_wrapper(std::coroutine_handle<promise_type> h = nullptr) noexcept : handle(h) {}
    ~simple_wrapper() noexcept {
        if (handle) {
            handle.destroy();
        }
    }

    int get() {
        if (!handle || handle.done()) return -1;
        auto ret = handle.promise().last_yield;
        handle.resume();
        return ret;
    }
};

simple_wrapper generator(int from, int to, int throw_on = -1) {
    for (int i = from; i < to; ++i) {
        if (i == throw_on) {
            throw std::runtime_error(std::to_string(i));
        }
        co_yield i;
    }
}

• On MSVC this fails when throwing an eager (pre first suspend) exception because of a double free of the coroutine state buffer.
• On stable GCC versions (11-14) it fails in the exact same way.
  • But! On GCC trunk this works.
• On clang <17 throwing eagerly to my surprise passes, but as mentioned before, because pre-17 clang doesn’t cover the first defect report, it crashes when throwing after the first suspend. The local coroutine vars get destroyed two times for some reason⁴.
  • On clang 17 and later (17-19) this passes.

Wow! So, by the sheer benevolence of our compiler-writing overlords, gcc trunk and clang 17-19 actually do something sane about the second defect report. Color me suprized.

Alas the use of clang 17-19 in production is, I suspect, pretty small (mostly Android NDK) and, as for gcc trunk, I guess pretty much zero.

So, the problem is twofold. GCC and MSVC don’t want me to destroy the coroutine handle on eager throws, and pre-17 clang doesn’t want me to directly rethrow from unhandled_exception on non-eager throws. How about if I keep track of my first suspend, and if it hasn’t happened yet, I rethrow, otherwise I store the exception (like a caveman):

struct workaround_wrapper {
    struct promise_type {
        int last_yield = no_value;

        std::exception_ptr exception;
        bool has_been_suspended = false;
        bool has_exception_before_first_suspend = false;

        workaround_wrapper get_return_object() {
            return workaround_wrapper{std::coroutine_handle<promise_type>::from_promise(*this)};
        }

        std::suspend_never initial_suspend() noexcept { return {}; } // eager
        std::suspend_always final_suspend() noexcept { return {}; } // preserve the final yield

        std::suspend_always yield_value(int v) noexcept {
            has_been_suspended = true;
            last_yield = v;
            return {};
        }

        void return_void() noexcept {}

        void unhandled_exception() {
            // imperfection
            if (has_been_suspended) {
                exception = std::current_exception();
            }
            else {
                has_exception_before_first_suspend = true;
                throw;
            }
        }
    };

    std::coroutine_handle<promise_type> handle = nullptr;

    explicit workaround_wrapper(std::coroutine_handle<promise_type> h = nullptr) noexcept : handle(h) {}
    ~workaround_wrapper() noexcept {
        if (handle && !handle.promise().has_exception_before_first_suspend) {
            handle.destroy();
        }
    }

    int get() {
        if (!handle || handle.done()) return -1;
        auto ret = handle.promise().last_yield;
        handle.resume();
        if (handle.promise().exception) {
            std::rethrow_exception(handle.promise().exception);
        }
        return ret;
    }
};

Got it! This passes on MSVC and GCC and pre-17 clang. Yay!

But this is actually surprising. I expected this to fail. Specifically I expected it to pass on GCC and MSVC, but fail on clang. After all, the eager throw passed on clang before, so not destroying the handle on an eager throw here should have caused a leak. No leaks though. Huh? I guess some kind of hidden reference counting is in play here. Free lunch. Who whould have thought?

On GCC trunk, the state buffer leaks as expected.

So… I decided not to accommodate gcc trunk and all three of its users in production. I’ll just leave it as is and have that as a problem to future me (screw that guy).

Can this be librarified? Sort of, I guess. The problem is that from a library’s perspective it can’t possibly be known where the coroutine would be suspended. The library could try to wrap all awaitables, but this will be too much work and it would make the code which uses it very ugly. So I decided to make this semi-manual helper:

struct throwing_eager_coro_promise_type_helper {
protected:
    std::exception_ptr m_exception;
    bool m_has_been_suspended = false;
    bool m_has_exception_before_first_suspend = false;
public:
    void unhandled_exception() {
        if (m_has_been_suspended) {
            m_exception = std::current_exception();
        }
        else {
            m_has_exception_before_first_suspend = true;
            throw;
        }
    }

    void on_suspend() noexcept {
        m_has_been_suspended = true;
    }

    void rethrow_if_exception() {
        if (m_exception) {
            std::rethrow_exception(m_exception);
        }
    }

    template <typename PT>
    static void safe_destroy_handle(const std::coroutine_handle<PT>& h) noexcept {
        static_assert(std::is_base_of_v<throwing_eager_coro_promise_type_helper, PT>);
        if (h && !h.promise().m_has_exception_before_first_suspend) {
            h.destroy();
        }
    }
};

… to be used like so:

struct workaround_wrapper {
    struct promise_type : public throwing_eager_coro_promise_type_helper {
        int last_yield = no_value;

        workaround_wrapper get_return_object() {
            return workaround_wrapper{std::coroutine_handle<promise_type>::from_promise(*this)};
        }

        std::suspend_never initial_suspend() noexcept { return {}; } // eager
        std::suspend_always final_suspend() noexcept { return {}; } // preserve the final yield

        std::suspend_always yield_value(int v) noexcept {
            last_yield = v;
            on_suspend(); // manually mark suspend point
            return {};
        }

        void return_void() noexcept {}
    };

    std::coroutine_handle<promise_type> handle = nullptr;

    explicit workaround_wrapper(std::coroutine_handle<promise_type> h = nullptr) noexcept : handle(h) {}
    ~workaround_wrapper() noexcept {
        // helper destroy
        throwing_eager_coro_promise_type_helper::safe_destroy_handle(handle);
    }

    int get() {
        if (!handle || handle.done()) return -1;
        auto ret = handle.promise().last_yield;
        handle.resume();
        handle.promise().rethrow_if_exception(); // helper
        return ret;
    }
};

Oh, and to make sure that I know when GCC 15 comes around (and ruins my day) I also added this:

#if defined(__GNUC__)
#   if defined(__clang__)
#       if __clang_major__ > 19
#           error "Clang version > 19 is not tested"
#       endif
#   elif __GNUC__ > 14
#       error "GCC version > 14 is not tested"
#   endif
#endif

Hacky? Check. Evil? Check. UB? Check. Works? Yes. Now this is programming in C++!

Here I complain about CMake presets. I did some (perhaps an hour or so) of research, but it’s not impossible that I completely missed something that actually solves my problem. In case I have, I’d be really happy to know what it is.

So CMake presets have been around for some time now and at first glance they’re pretty nice.

Now, I have some minor complaints about verbosity, the syntax of conditions, even the choice of JSON as a format (Hello! Comments?), but really, they’re mostly minor stuff and I won’t go further into them in this post.

I have a huge problem with the way presets other than configure are handled.

So, let’s imagine a use case: You have many configure presets, say 20. You want to set up a CI to build and test all of them.

I don’t believe this is an uncommon use case. In fact I believe this should be the most common one. And how is one supposed to do this? There are two solutions that I can think of.

• Annoying: Don’t create build and test presets. Once you configure, navigate to the binary directory and run cmake --build . && ctest
  • And how do you know where the binary directory is?
  • You don’t. No way to query preset values.
  • You can parse the output of cmake --preset mypreset and look for -- Build files have been written to: .... Ew
  • You can force a change by specifying -B someBinaryDir after --preset and then use that directory. Then you will have to forget all the fancy reasons for which you specified a binary directory in the preset.
• Terrifying: Create 20 build presets and then 20 test presets for each configure preset which are exactly the same except for the configurePreset field.
  • …and you will have to keep these additional two lists of presets in sync with the list of configure presets.
  • Manually? Double ew! Annoying and error prone. The worst of all worlds.
  • Yes, yes, it can be atomated. Perhaps using the vendor field to store metadata for you automation code (since you can’t have comments-based metadata in JSON) or by creative use of includes… The problem of automating this means the proliferation of ad hoc solutions which are not compatible between one another.

And if you want to have fancy build and test presets which actually do something, and you use some IDE or editor which has integration with CMake presets, things get really ugly.

My main point is that there already are tens if not hundreds of scripts, tools, even IDEs like Visual Studio and QtCreator, which predate CMake presets and have their own version of presets along with ways of dealing with this problem. If there is to be a unifying standard way of dealing with presets, it should not require yet more third-party ad hoc tooling to do basic stuff.

So, I have a proposal or two for the CMake developers. Four years ago after my previous ranty post about issues with CMake Craig Scott was so kind to take issue with the problem and work on it until finally, after years, there was a solution. So, Craig, please, how about:

Simple: Implicit Presets

To cover the most basic use-case and probably 99% of the needs out there, a simple change can be made to CMake.

I would suggest to parse build and test (and why not package and workflow) presets names and have a way to infer a configure preset from there. If we have a configure preset called myconfig, how about something like:

• cmake --build --preset=myconfig-default
• or ctest --preset=cfg/myconfig
• or why not cmake --build --configure-preset=myconfig

…or something in this spirit. Just think of this as having implicit build, test, and package presets for each configure preset. The implicit ones only use the default value for each field. 99% of problems solved.

I posted an issue in the CMake tracker for this.

Complex: Multi Presets

Allow defining non-configure presets which can match multiple configure presets. Thus not just the default values will be accessible, but also custom ones. Something like:

"buildPresets": [
    {
        "multiConfig": true,
        "description": "same efect as the previous proposal",
        "name": "build-${configurePreset}"
    },
    {
        "multiConfig": true,
        "name": "build-${configurePreset}-bench-ab",
        "targets": ["benchmark-a", "benchmark-b"],
    }
]

This can be combined with the introduction of tags in configure presets and then such “multiConfig” presets can match them to indicate their applicability.

Anyway, having a way to define umbrella or wildcard presets can be really powerful, but more thought needs to be put into this. I don’t pretend to be thorough in the suggestion above. It’s just an idea.

Setting it up wasn’t an entirely flawless experience and I’ll document the issues I faced and how I resolved them in the next post. This post contains my thoughts of the setup and an analysis of this idea.

Now, I didn’t sit on my sofa with my phone in one hand, typing code on an onscreen keyboard with the other and with the editor on the glorious 25 square centimeters of remaining screen area. This is obviously not viable. I connected my phone to an external display, a physical keyboard, and a mouse and I sat on a desk.

Yes, I did clean my desk for the photo

Also, I may be late to the party as people have been posting similar things for years now. I’ve stumbled on posts and videos about using phones for stuff typically done on desktops or laptops, or connecting them to external displays and physical keyboards for business or pleasure since at least 2019. But I haven’t seen anything about doing actual software development with a smartphone. So here goes.

What?

First and foremost, I used another computer for the actual heavy computational work. I didn’t even attempt setting up compilers or interpreters on Android.

Running everything locally seems quite feasible on a rooted Android device, with Ubuntu Touch, or with other more open Android variants, but powerful as they are, smartphones and tablets just cannot compare in terms of computational power to even moderately powerful desktops or laptops. If you spend the same amount on a smartphone and a laptop, the laptop would significantly outperform the phone in computational power.

Running everything locally is perhaps an adequate option for intro-level educational work, where the programs you create are small and modest, and tooling is not of the essense. You don’t even have to root your device for that. The Google Play Store is full of educational software for programming. If anything, the issue would be finding the best solutions in the myriad of existing options.

So, I used another computer which builds and runs the actual software, but I did not rely on VNC or Remote Desktop. Such solutions exist for Android and they may be adequate for some. My gut tells me that there’s going to be network issues if one goes that route, but I have not tested them and my use case does not benefit from them.

I use computers which in most cases have no graphical desktop set up. I use them via SSH. I use many computers: cloud instances (like Azure, EC2, or Lambda Labs) and my personal computer with port forwarding.

The smartphone in this setup is a console for the actual software development part. What it does run locally is the terminal and IDE. Well, of course also all other apps that are otherwise there.

Why?

For science!

But the thing that prompted me to explore this was actually cost.

Don’t get me wrong. I’m not trying to propose a budget solution for people who can’t afford a workstation. Such a solution would be a second hand laptop.

My idea was more in the realm of avoiding waste. I hate waste. My first observation was that I was spending increasingly more time working on remote machines. For my pesonal projects I do use my own computer, but sadly I don’t have that much time for them. No more than several hours a week. So, I wondered what it would be like to use a modest (old) laptop for personal stuff and rent cloud compute when I need to get serious. With prices of about $1/hour (and without a GPU, considerably less), even if I have the luxury of 10 hours a week for personal projects, such a plan would add up to roughly $500 dollars a year. And always using the best current hardware at that. A top of the line home computer can cost 10 times that and it will likely be close to obsolete in 10 years. It doesn’t add up. Not if you only use it for 10 hours a week or less. It then dawned on me that I have a modest computer in my pocket at all times. And it’s not even that modest. The Galaxy S23+ has 8 GB of memory, an 8-core ~3GHz CPU, and even a decent GPU. This would’ve been a pretty expensive PC 10 years ago. It’s only logical not to waste this great computational power by only using it for phone calls, solitaire, and cat videos. 🖖

That is why I decided to give it a try, but I can think of other reasons:

Mobility, naturally. My mobile phone is with me at all times. It has an internet connection and doesn’t even need Wi-Fi. It’s definitely not enough to do actual work on, but it will do for something small and urgent. And to do actual work with such a setup I need a display, a keyboard, and, preferably, a mouse. The configurations, passwords, SSH keys, and everything else I need is in my pocket.

I mentioned running everything locally can be a decent option for educational purposes. And practically everyone has a smartphone these days. It seems to me that making a desktop from their smartphones can turn out to be a good way of introducing kids and teens to more… well, “serious” use of computers. Be it software development, graphical design, or audio/video editing and creation. At a beginner level, all of these activities are very well covered by existing software for handheld devices.

And, of course, it’s cool. “I work on my phone” has a whole new meaning now.

How Was It?

After the somewhat unpleasant experience of setting up everything, it just worked. There was no long adjustment period in order for me to start doing things efficiently. I had no crashes or freezes, or even stutters. I managed to do a full workday on my phone connected to a display, keyboard, and mouse with pretty much no issues.

But keep in mind, I only explored a setup which is viable for backend development. The local tools I absolutely need for this are few: an SSH-capable terminal with SCP or SFTP, an IDE, and a browser. Now, I don’t use vim or another terminal-based editor, but if you do, your list will be even shorter.

I also made use of the software that otherwise exists on my phone. Apps for communication: Slack, Zoom, other messengers, email; and for multimedia: music, videos, games, and the rest. I’m not going to talk about these anymore as smartphones excel in communication (literally their purpose) and multimedia, so there was simply no need to do any special setup there. It wasn’t expected to be a problem, and it wasn’t. But it’s worth mentioning that given the quality of modern smartphone cameras, with such a setup you get perhaps the best webcam you’ve ever used.

I don’t think that a good web frontent development environment can be set up on Andriod. I may be wrong. Chrome’s DevTools don’t work on Android. To my knowledge Firefox is the only browser which has a developer console on Android. And that’s not all. With my SSH-only setup there is no localhost. You’ll have to serve HTTP (and possibly HTTPS) from the remote machine and this seems to make things too complicated for my taste. That is not to say that running a local web server is impossible. Perhaps a rooted phone or one with Ubuntu Touch may be turned into a viable web frontend workstation.

I am fairly certain that this is not a good way to do desktop development. Even if you do end up running VNC or Remote Desktop succesfully, I suspect everything related to animations, framerates, video, and sound will be completely unreliable.

Naturally using Android to create Android applications is not a good idea. It would make the whole thing into a giant chicken-or-egg problem.

So, will I ditch or shelf my PC in favor of my phone? No. Not yet. But I can see myself possibly doing it in a generation or two of smartphones. My problem is that everyhing… well, everything directly involved with software development needs to be done on SSH. I still like to do graphical programming occasionally. I still make use of localhost and Chrome DevTools. I even play (gasp) games once in a blue moon (sure, there are some pretty decent games for Android, but I’m talking StarCraft and Titan Quest, and other old timey stuff). Maybe that will be a reality on phones in a couple of years, I won’t be surprised if it will, but until then I am keeping my PC, thank you very much.

But. There is one thing that I am about to do. I will get a lapdock (which is a thing, apparently), likely this one though I’m still researching, and when I travel, I will be able to do it very light. I am not afraid to actually work on my phone.

Want to Give it a Go?

I will go into my concrete setup in the next blog post, along with all the challenges I encoutered and their solutions. It took me about 5 hours (I lost a $5 bet to my wife by wildly underestimating how long it would take), including research, to go from zero to hero. With the info from that post, I’d say it would take me less than 15 minutes to set up a brand new phone the same way.

Before moving to the next post, though, do take a look at the list of limitations and minor nuisances for which there is no solution or, rather, I haven’t found any. I mean, they’re minor nuisances to me, but they may be deal-breakers to others.

• You can’t have two displays connected to an Android device. This may change in the future (and I think that it likely will), but in order to work on your phone, you have to be OK to work on a single display. I have a huge one, as seen in the photo, and I’m perfectly satisfied with it, but some people can only work in an igloo of monitors and they definitely won’t be.
• Customization options for your desktop experience on Android are pretty much non-existent. This doesn’t matter to me, but if you’re the type of person who likes to tweak window transitions and use desktop widgets for everything, you’re out of luck. Android does have widgets, but for some reason not on the desktop. Plus, there is no “general look and feel” to speak of. It’s every app on its own. Changing the wallpaper is basically all you get.
• Window management is bare bones. You can maximize and manually stack windows and that’s it. No tiling whatsoever. I manually stack windows all the time. It’s how I naturally work. I didn’t even feel the lack of a decent window manager. I realize though that it might be an issue for some. Samsung’s One UI interface does have some fancy Window arrangement tiling-like features, but I have not tested them.
• No Android browser that I know of supports multiple profiles. This was a problem for me as I usually use two profiles on Chrome for personal and professional tasks. My solution was not elegant. I used two browsers: Chrome and the built-in Samsung Internet.
• Chrome extensions don’t work on Android. This was a bit of a problem for me, but luckily I don’t use too much of these so I just used a vanilla browser. Extensions do work on Firefox and there are also extensions for Samsung Internet, but if you’re entirely dependent on Chrome extensions, this is not the setup for you.
• Certain websites show their mobile version, not based on aspect, but on userAgent. I did have to explicitly request a desktop version for a website a couple of times. Then, of course, this was “remembered” and I had to manually switch back to the mobile version once I opened them on my phone again.

The TLDR of my setup is:

• IDE: vscode.dev with tunnel from the dev machine
• SSH Terminal: ConnectBot
• SFTP: termius
• Browser: Google Chrome + Samsung Internet
• Email: Gmail + Outlook for Andoird

And now, on to the details…

I just released version 2 which is a complete rewrite of v1. The basic ideas are still there, but the implementation is different.

If you’re frustrated with vanilla C++ OOP, check it out.

And now to my woes…

I have a hard time introducing the library. I have no good elevator pitch. I think that the few people that have spent the time to get what it does did like it and some started using it. There is a small user base out there which does pretty neat things with it.

To the best of my knowledge it takes at least several hours for one to grasp the idea. Better yet if one sleeps on it. It benefits a lot if one has experience with “dynamic” languages like Ruby, Dart, Scala, or PHP, but if one’s experience is mainly with C++ or other languages which have a similar approach to OOP, like C# or Java, it’s pretty tough.

I think it can be very beneficial in many situations, but I’m struggling with making such an approach more known.

About ten years ago I submitted it to Boost, but since it usually takes hours for one to “get it”, it never got any reviews. The questions and comments I hear are “So what does it do?”, “I don’t think it’s useful”, “My needs are covered by virtual functions and inheritance. This is a pointless overcomplication”, and so on.

So yeah, I should focus on marketing I guess.

Until I come up with a better way to explain it, if you like Ruby or Scala, but also write a lot of C or C++, yes, all five of you, do check it out. I think you’ll like it.

Ever since Visual Studio had CMake support with Open Folder I’ve been using this workflow exclusevly and I have absolutely no desire to go back to manually generated .sln/.vcxproj files. That’s mostly because I would have to ditch ninja, but there are many reasons as well. Custom CMake configurations³ are much easier to manage like this. The folder view is much better than the project view… anyway, Open Folder is great!

Another thing I use all the time is Compile Single File (Ctrl-F7). When writing code I find it superior to a full build in every way. You can quickly check that a source file compiles and fix (often anticipated) compilation errors without having to wait for many other sources to compile in parallel or waiting for the linker and whatnot. The most common use case here is when writing code in a header which is included in several source files. While writing the code I often compile one source file (the fastest one to compile) and deal with compilation errors there. A full build step would trigger the parallel compilation of many other sources and I would first have to wait for the slowest one to finish, and second, have my error output cluttered with the same compilation error in different contexts for every source file. So yeah, compiling individual sources is a second nature to me. I’m sure I even do it more often than strictly needed, but it’s a negligible overhead compared to the rest of the situations.

So, Most often I use Visual Studio with CMake and the Open Folder workflow. I use the ninja generator. I compile single sources all the time.

That’s precisely what got broken in Visual Studio 17.4 a couple of months ago.

It doesn’t work anymore except for the simplest of targets. Trying to compile a source file works if the owning binary target is defined in CMake in a trivial manner like add_executable(name src.cpp), but for anything more “complex” than this it doesn’t. If a target is added through a macro - nope. If the sources are set at a later point with target_sources - nope. What happens in these cases is that a bogus source file target name is issued and I get an error. Visual studio tries to invoke CMake with a source file target like a/b/foo.cpp.obj, but the correct target should be something like a/b/CMakeFiles/b.dir/foo.cpp.obj.

Here’s what I think happened. Now, I don’t have internal infomation from the dev team and I don’t know it for certain, but I’m fairly sure about it:

Before VS 17.4 a CMake project would get reconfigured two times when a CMake source is changed. My guess is that the first configuration is used by Visual Studio to generate hidden vcxproj files, so it could parse the targets and sources for IntelliSense and other IDE-specific stuff (like compiling a single source file). The other configuration would be the one used to actually build the project. In my case the ninja one. Visual Studio can’t read ninja or CMake scripts, but it can definitely read vcxproj files. That’s why it needs the first configuration. This double configure was somewhat annoying but not a terrible pain. If anything it was a motivator to optimize the CMake scripts so that configuring doesn’t take an excessive amount of time⁴.

With VS 17.4 it started configuring only once. Great! Right?

How does it get the IDE-specific metadata for the project, then? It seems to me that the developers have added a custom CMake parser to Visual Studio for that. I don’t know whether it is a reimplementation of CMake (yikes!) or they’re integrating some of CMake’s code, but they seem to have bugs. The information for single-source targets is lost unless they are a part of a trivially defined binary target. And hence compiling a single source doesn’t work most of the time. Well, at least for my not-so-trivial CMakeLists.

I posted an issue here. But it I doesn’t seem to be getting a lot of action. It seems to me that it would take a lo-o-o-ong time until it’s addressed.

And until then…

• On my personal computer I’ve resorted to using VS Code on Windows as well. It really is quite good for C++ programming, but still vastly inferior to Visual Studio for debugging. The fact that it supports only a single loaded .natvis file is also unpleasant. If I have to do more complex debugging, I launch Visual Studio.
• On my work computer I just haven’t upgraded to Visual Studio 17.4. I’ll try to stick with 17.3 for as long as possible and when I can’t, I’ll probably switch to VS Code as well.
• I’ll try to find time this month to evaluate CLion. As I said, I’ve been reading a lot of good stuff about it. Perhaps it will become my next IDE.

So… yeah. Seems kinda prosaic, but this little thing will possibly be the Visual Studio killer for me.

Sad.

Here’s some example code:

#include <iostream>
#include <string>

template <typename T>
T galactus_the_devourer_of_const(const T& v) {
    return false ? std::move(T{}) : std::move(v);
}

int main() {
    const std::string food = "asdf";
    std::cout << "before: " << food << '\n';
    galactus_the_devourer_of_const(food);
    std::cout << "after:  " << food << '\n';
    return 0;
}

Live demo here.

Even though food is const it still gets its value “taken”.

I first came upon it more than a year ago in September of 2021 and at first it was infuriatingly annoying, but then I noticed that it somehow happened in one of my projects and didn’t in another. Then I found out that it only happens with the compiler flag /permissive, which is the default, and doesn’t with /permissive- which is the only sensible option for people even thinking about writing multi-platform C++.

Since all of my projects use /permissive- and I only encountered the bug due to an oversight, the severity was scaled down to a minor nuisance.

Still, it happens with the default settings on. It’s somewhat contrived, but I can imagine someone else getting bitten by it. I opened an issue on Miscrosoft Developer Community, but (as is tradition) it’s just sitting there, stale and unloved.

I hope it doesn’t bite you.

I have prioritized these which I deemed more useful to the community and have been witholding ones that I can do nothing about, or, rather, ones which would require too much of investment to address, much in the spirit of this famous tweet.

I have decided to write posts about the rest as well. Perhaps others will get as mad as I am about them, or more, and they will do what I wouldn’t. Perhaps, even though I don’t find them educational, others will.

It’s mostly just venting, though.

So I’ll create a tag rants and post some stuff under it.

And if anyone in power to do something about any of them reads,

… please.

But first…

What Are Shared Pointer Leaks?

A “classic” leak would be memory¹ not being freed after use. Smart pointers including shared ones are there to prevent just that. They free the memory appropriately in their destructors.

Shared pointers specifically use reference counting. Every copy of a shared pointer increases the reference count, also known as a use count, in an object shared between them called a control block. Every shared pointer destructor decreases the use count. In the destructor of the last shared pointer to reference a given control block, this count would reach zero and the associated resource will be destroyed and the associated memory likely freed. Why the use of “likely”? Some shared pointers such as std::shared_ptr also allow non-owning weak pointers (std::weak_ptr). A weak pointer will also reference a control block, but won’t touch the associated use count. Instead it would use a different counter - the weak count. Thus if all shared pointers for a control block get destroyed, the strong use count will reach zero and the managed resource will be destroyed. However if weak pointers remain, the weak count will not be zero and the memory allocated for the control block will still be preserved. When all weak pointers also get destroyed (or if there were none to begin with) the weak count will reach zero and only then will the control block be freed and all trace of our object will evaporate from the process.

As you can see this presents us with several leak opportunies:

• Circular referencing. If an object in a shared pointer A references another object through a shared pointer B, and B also references A in the same manner, the use count can never reach zero. In a dead lock of sorts each object has to be destroyed for the other to be destroyed. The cycle can be long, spanning tens of objects, or short: an object may end-up holding a reference to itself.
• Loose references. A shared pointer may make its way in a global collection like a manager, a log, or a garbage collector, and due to a bug or an oversight not get removed from there. Only stopping the process clears the memory
• Weak leaks². Basically the same as above but with weak pointers. The objects do get destroyed but the memory for the control blocks remains.

Noticing these leaks can be pretty hard. Typically they are noticed when the memory begins growing uncontrollably and at this point it’s usually hard (or impossible) to tell exactly which use of shared pointers is to blame. Moreover, due to the facts that even with heavy use, shared pointers are not typically found in hot loops and new shared pointers don’t have a high velocity of creation, the suspicious memory growth can take hours, or days, or weeks of run time to become noticeable. Getting a stable repro of such an issue can be quite annoying.

Now, there are many good practices one can employ in order to minimize the chance of a shared pointer leak. Unfortunately mistakes can be made. Bugs can happen. I won’t delve into good practices here. By all means employ them, but if there is a shred of doubt in their effectiveness in a given situation, one needs something “heavier”.

Something Heavier Than Good Pracices

This really got me thinking a couple of months ago.

First, what do classic leak detectors do? They log every allocation and every deallocation. At a given point they can provide information about an allocated block, or about all currently living allocated blocks. They can’t “know” whether something is a leak. They can strongly suspect so at termination time, but deliberatly not freeing memory upon termination is a widely practiced, though dubious, pattern. Still, in the middle of execution a leak detector can’t possibly tell whether an allocated block is a leak or not.

This can still be useful. If I log all currently allocated blocks (or a select suspicious few), with my domain knowledge I can find or clear leak suspects based on the provided metadata. “Hey, I don’t expect this 10 MB buffer, allocated two hours ago in allocate_temp_blob to be still alive at this point!”

So, it’s settled. I’ll attach metadata to each shared pointer control block. Then I can log the current state of affairs and find or clear suspects. “Hey, SessionManager::m_activeSessions should not a hold a reference to a session which disconnected an hour ago!”. Great! How do I do that?

Ok, how do classic leak deterctors work? They hook themselves to malloc and free or sometimes to new and delete and collect metadata at these points. This is relatively easy and is a documented extension point.

Can this be done for the control block of std::shared_ptr?

Nope.

The control block is not standardized. It’s opaque and an implementation detail for all intents and purposes. The only way to achieve such behavior would be to reimplement std::shared_ptr with a custom control block defined by the implementation.

So I went ahead and did that in a library I called xmem.

xmem

In short xmem is an alternative implementation of the smart pointers from the standard header <memory>: unique_ptr, shared_ptr, and weak_ptr. It’s a drop-in replacement, too. You should be able to replace all instances of these pointers in a codebase from std:: to xmem:: and achieve the exact same functionality.

Notably it offers several additional features: the most important one being that the control block (or the control block factory, rather) is a template argument to shared_ptr and weak_ptr. It can be replaced with one which collects metadata, which can then be logged and inspected at a given point. Replacing the control block can be used for other features as well. One side effect of this is that local_shared_ptr³ is possible and implemented.

The main drawback is that it’s not just an optional plug-in for existing code. To make use of it, you must change the uses of std::shared_ptr to xmem::shared_ptr and so on. One can conditionally compile say mymem::shared_ptr to be one or the other, but it would still involve a significant code change.

How Does Tracking Work?

A shared_ptr instance refers to an object. A weak_ptr instance referes to a control block. Every time a referer is added (via copying or creation), or changed (via moving or swapping), the control block gets notified with special method calls. The default implementation of the notification methods is empty, thus achieving identical behavior and performance to standard shared and weak pointers⁴.

Since the control block factory is a template argument, one can change the default identity control block to be something else. Something which records metadata at the given notification points. Thus the information which living pointers refer to an object and a control block can be queried at any time.

If collecting the information for every single pointer instance is too much and overburdens the system, one has the power to choose collect it only for certain pointee types, or even for selected “suspicious” pointer instances.

I guess it will all become easier to understand with…

An Example

This is a step-by-step replication of the library example shared_ptr-leak

Let’s create a program with a shared pointer leak:

#include <iostream>
#include <memory>
#include <vector>
#include <ctime>
#include <cstdlib>

using session = int;

auto session_factory(int id) {
    return std::make_shared<session>(id);
}

int main() {
    std::shared_ptr<session> leak;

    std::vector<std::weak_ptr<session>> registry;

    constexpr int N = 20;
    srand(unsigned(std::time(nullptr)));
    auto i_to_leak = rand() % (2 * N);
    for (int i = 0; i < N; ++i) {
        auto sptr = session_factory(i);
        registry.push_back(sptr);
        if (i == i_to_leak) {
            leak = sptr;
        }
    }

    for (auto& w : registry) {
        if (w.use_count()) {
            std::cout << "found a leak in " << w.lock() << "\n";
        }
    }
}

As you can see, this program collects weak pointers to sessions and expects them all to be expired by the time it completes. In about 50% of the cases a stray shared pointer to a session remains. A leak.

Of course in such a small example it’s easy to see which shared pointer is the stray one and where it was assigned a session. It’s right there, called leak on the first line of main. It gets assigned a session on line 25. Easy! A real world piece of software, of course, might not be that simple to debug.

Let’s try and make the program itself reproduce this information.

First, as mentioned before, we will have to ditch <memory>, std::shared_ptr, and std::weak_ptr for xmem and its smart pointer counterparts. Let’s say that we will use standard smart pointers most of the time to avoid worying about third party software and only resort to xmem occasionally, when we suspect leaks or when we run tests. This means that we will need conditional compilation to choose one or the other:

#define TRACK_SHARED_PTR_LEAKS 1

#if TRACK_SHARED_PTR_LEAKS
#include <xmem/shared_ptr.hpp>
#include <xmem/ostream.hpp> // so we can cout << xmem::shared_ptr

namespace myapp {
using xmem::shared_ptr;
using xmem::weak_ptr;
using xmem::make_shared;
}

#else

#include <memory> // don't include <memory> otherwise
namespace myapp {
using std::shared_ptr;
using std::weak_ptr;
using std::make_shared;
}

#endif

We defined myapp::shared_ptr, myapp::weak_ptr, and myapp::make_shared to mean xmem pointers or std pointers. The code is almost identical, and behaviour is exactly identical. We mentioned the default implementation of the control block is the same as the standard one. Doing just this is not enough to gain metadata for our pointers. It’s still an important step in the process because it ensures that the code builds and works with both sets of pointers.

We will now focus on the xmem part of this #if check. As a second step of the setup, we will reimplement xmem::shared_ptr to still be identical to std::shared_ptr but with the code expanded so we can see where our metadata collection will happen.

Replacing the control block can be very powerful, but during the implementation I noticed there is a lot of copy-pastable boilerplate involved in the typical cases. That’s why I created the header xmem/common_control_block.hpp. It contains most of the boilerplate in reusable template classes.

So, using it, we can continue:

#if TRACK_SHARED_PTR_LEAKS
#include <xmem/common_control_block.hpp>
#include <xmem/atomic_ref_count.hpp>
#include <xmem/ostream.hpp>

namespace myapp {

using bookkeeping_control_block = xmem::control_block_base<xmem::atomic_ref_count>;

using bookkeeping_control_block_factory = xmem::control_block_factory<bookkeeping_control_block>;

template <typename T>
using shared_ptr = xmem::basic_shared_ptr<bookkeeping_control_block_factory, T>;

template <typename T>
using weak_ptr = xmem::basic_weak_ptr<bookkeeping_control_block_factory, T>;

template <typename T, typename... Args>
[[nodiscard]] shared_ptr<T> make_shared(Args&&... args) {
    return shared_ptr<T>(bookkeeping_control_block_factory::make_resource_cb<T>(
        std::allocator<char>{}, std::forward<Args>(args)...));
}

}

#else // ...

With this we reimplemented xmem::shared_ptr in myapp::shared_ptr. We did create the type bookkeeping_control_block, but it does no bookkeeping yet. It continues to have behavior identical to the standard control block which can be found in std::shared_ptr. And this control block is what we’re going to change. The rest of the typedefs below it can remain exactly the same.

To have xmem::basic_shared_ptr and xmem::basic_weak_ptr compile, the control block needs to have a set of methods. control_block_base<atomic_ref_count> naturally has them, so instead of reimplementing them, let’s make use of it in our bookkeeping implementation:

class bookkeeping_control_block : protected xmem::control_block_base<xmem::atomic_ref_count> {
public:
    using super = xmem::control_block_base<xmem::atomic_ref_count>;

    // new shared pointer created
    void init_strong(const void* src) noexcept {
        super::init_strong(src);
    }

    // increment use count (shared_ptr copy)
    void inc_strong_ref(const void* src) noexcept {
        super::inc_strong_ref(src);
    }

    // decrement use count (shared_ptr destoyed, reset, or overwritten)
    void dec_strong_ref(const void* src) noexcept {
        super::dec_strong_ref(src);
    }

    // icrement use count only if not zero (weak_ptr lock)
    bool inc_strong_ref_nz(const void* src) noexcept {
        if (super::inc_strong_ref_nz(src)) {
            return true;
        }
        return false;
    }

    // control block transferred between shared pointers (move or swap)
    void transfer_strong(const void* dest, const void* src) {
        super::transfer_strong(dest, src);
    }

    // get use count
    using super::strong_ref_count;

    // increment weak count (weak_ptr copy)
    using super::inc_weak_ref;

    // decrement weak count (weak_ptr destoyed, reset, or overwritten)
    using super::dec_weak_ref;

    // control block transferred between weak pointers (move or swap)
    using super::transfer_weak;
};

Since our application only cares for the use count and not the weak count, we provided no bodies to the weak count functions. We will add our bookkeeping code in the use count ones. For now however bookkeeping_control_block still does no bookkeeping. It is yet another reimplementation of the default and standard control block. Those void pointers? They are the shared_ptr instances which triggered those calls.

Now, what kind of bookkeeping shall we do here? How about we store the stacktrace for the point where each shared pointer acquired a reference to the object. For this we will use two new functions, on_new_strong and on_destroy_strong. We will store the information for a shared pointer in the first and we will remove it in the second. First let’s add the calls:

class bookkeeping_control_block : protected xmem::control_block_base<xmem::atomic_ref_count> {
public:
    using super = xmem::control_block_base<xmem::atomic_ref_count>;

    void on_new_strong(const void* src) {}

    void on_destroy_strong(const void* src) {}

    void init_strong(const void* src) noexcept {
        super::init_strong(src);
        on_new_strong(src); // new pointer here
    }

    void inc_strong_ref(const void* src) noexcept {
        super::inc_strong_ref(src);
        on_new_strong(src); // new pointer here
    }
    void dec_strong_ref(const void* src) noexcept {
        on_destroy_strong(src); // remove pointer here
        super::dec_strong_ref(src);
    }
    bool inc_strong_ref_nz(const void* src) noexcept {
        if (super::inc_strong_ref_nz(src)) {
            on_new_strong(src); // new pointer here
            return true;
        }
        return false;
    }

    void transfer_strong(const void* dest, const void* src) {
        super::transfer_strong(dest, src);
        // on a transfer we...
        on_new_strong(dest); // have a new pointer in dest
        on_destroy_strong(src); // lost a pointer with src
    }

    // ...
};

Let’s store the stacktrace for each pointer in our two new functions. For the stacktrace, I’m using a simple stacktrace library: b_stacktrace⁵. Since we’re anticipating multi-threaded usage, we will also add a mutex lock for the cases where we update the bookkeeping information. We will also store the creation time of the control block. Thus we can track its lifetime completely

class bookkeeping_control_block : protected xmem::control_block_base<xmem::atomic_ref_count> {
    std::time_t m_creation_time;
    stacktrace m_creation_trace;

    struct entry {
        const void* ptr; // associated shared pointer
        stacktrace trace;
    };
    mutable std::mutex m_mutex;
    std::vector<entry> m_active_strong;
public:
    bookkeeping_control_block()
        : m_creation_time(std::time(nullptr))
        , m_creation_trace(stacktrace::init)
    {}

    void on_new_strong(const void* src) {
        std::lock_guard _l(m_mutex);
        auto& e = m_active_strong.emplace_back();
        e.ptr = src;
        e.trace.record();
    }

    void on_destroy_strong(const void* src) {
        std::lock_guard _l(m_mutex);
        auto f = std::find_if(m_active_strong.begin(), m_active_strong.end(),
            [&](const entry& e) { return e.ptr == src; });
        m_active_strong.erase(f);
    }
    // ...
};

Now we only need query functions for the bookkeeping data:

class bookkeeping_control_block : protected xmem::control_block_base<xmem::atomic_ref_count> {
public:
    // ...
    const time_t& creation_time() const { return m_creation_time; }
    const stacktrace& creation_trace() const { return m_creation_trace; }
    void log_active_strong(std::ostream& out) const {
        std::lock_guard _l(m_mutex);
        for (auto& ref : m_active_strong) {
            out << ref.ptr << ":\n";
            out << ref.trace << "\n";
        }
    }
};

We don’t need locks for the creation data, but we need a lock for the active strong refs list. It can be updated at any point.

The last thing we need to do is log the bookkeeping data in main at the point where we detected the leak:

for (auto& w : registry) {
    if (w.use_count()) {
#if TRACK_SHARED_PTR_LEAKS
        std::cout << "\n====================\n";
        std::cout << "found a leak:\n";
        auto cb = w.t_owner();
        auto tm = std::localtime(&cb->creation_time());
        std::cout << "in object: " << cb << " created on " << std::put_time(tm, "%c %Z") << " here:\n";
        std::cout << cb->creation_trace();
        std::cout << "\nwith living refs:\n";
        cb->log_active_strong(std::cout);
#else
        std::cout << "found a leak in " << w.lock() << "\n";
#endif
    }
}

Then after we start the program several times until we get a leak, we can confirm which pointer leaked where:

====================
found a leak:
in object: 0000027B1408E6E0 created on 12/30/22 20:45:27 FLE Standard Time here:
C:\cpmcache\b_stacktrace\8f002d8131cb3c66e10d56856149f16395c99c44\b_stacktrace.h(184): b_stacktrace_get
C:\prj\xmem\example\e-shared_ptr-leak.cpp(41): myapp::stacktrace::record
C:\prj\xmem\example\e-shared_ptr-leak.cpp(36): myapp::stacktrace::stacktrace
C:\prj\xmem\example\e-shared_ptr-leak.cpp(71): myapp::bookkeeping_control_block::bookkeeping_control_block
C:\prj\xmem\code\xmem\common_control_block.hpp(63): xmem::control_block_resource<myapp::bookkeeping_control_block,int,std::allocator<char> >::control_block_resource<myapp::bookkeeping_control_block,int,std::allocator<char> >
C:\prj\xmem\code\xmem\common_control_block.hpp(71): xmem::control_block_resource<myapp::bookkeeping_control_block,int,std::allocator<char> >::create
C:\prj\xmem\code\xmem\common_control_block.hpp(120): xmem::control_block_factory<myapp::bookkeeping_control_block>::make_resource_cb<int,std::allocator<char>,int &>
C:\prj\xmem\example\e-shared_ptr-leak.cpp(161): myapp::make_shared<int,int &>
C:\prj\xmem\example\e-shared_ptr-leak.cpp(184): session_factory
C:\prj\xmem\example\e-shared_ptr-leak.cpp(196): main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): invoke_main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): __scrt_common_main_seh
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): __scrt_common_main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): mainCRTStartup
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): BaseThreadInitThunk
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): RtlUserThreadStart

with living refs:
000000D48C6FFC78:
C:\cpmcache\b_stacktrace\8f002d8131cb3c66e10d56856149f16395c99c44\b_stacktrace.h(184): b_stacktrace_get
C:\prj\xmem\example\e-shared_ptr-leak.cpp(41): myapp::stacktrace::record
C:\prj\xmem\example\e-shared_ptr-leak.cpp(89): myapp::bookkeeping_control_block::on_new_strong
C:\prj\xmem\example\e-shared_ptr-leak.cpp(113): myapp::bookkeeping_control_block::inc_strong_ref
C:\prj\xmem\code\xmem\basic_shared_ptr.hpp(174): xmem::basic_shared_ptr<xmem::control_block_factory<myapp::bookkeeping_control_block>,int>::init_from_copy<int>
C:\prj\xmem\code\xmem\basic_shared_ptr.hpp(35): xmem::basic_shared_ptr<xmem::control_block_factory<myapp::bookkeeping_control_block>,int>::operator=
C:\prj\xmem\example\e-shared_ptr-leak.cpp(199): main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): invoke_main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): __scrt_common_main_seh
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): __scrt_common_main
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): mainCRTStartup
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): BaseThreadInitThunk
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): RtlUserThreadStart

A session was assigned to the stray pointer called leak in main, line 199?! Who would’ve thought!