Maybe I’m missing something, but you seem profoundly confused.

If all this whole thing is about is keeping objects alive for arbitrary amounts of time, not connected to any particular scope, then there doesn’t seem to be a need for shared ownership. So shared_ptr makes no sense to begin with.

And if you’re making a statically-allocated map in any case, what is the point of all the handle/view shenanigans? Why not just use the map directly?

template <typename Device>
auto device_map = std::unordered_map<std::string, Device>{};

struct led 
{
    auto on() {}
    auto off() {}
};

auto main() -> int
{
    device_map<led>.emplace("led@1", led{});

    {
        auto&& led = device_map<led>.at("led@1"); // throws if device not found
        led.on();
    }
}

If you want, you can wrap the map and give it a nicer interface. You could even reference count and automatically delete the device when there are no more references (but that doesn’t really make a lot of sense, because it will always start with a reference count of zero, and thus should be immediately deleted).

But it’s still just a map. I don’t see the point of all the nonsense you have going on with views and handles (which are not even handles, because they literally hold the device inside them).

You don’t need shared_ptr. You don’t need polymorphic allocators. You don’t need intrusive_ptr. You don’t even really need reference counting, unless you want to remove devices when no longer in use (in which case, you might want to rethink your design concept, because at least in your example code, you are literally creating devices that are not in use, and thus should logically be deleted before they are ever used).

You just need a registry of devices—a list, a map, whatever—that lives longer than any device has to… and an obvious choice for that is static lifetime. Another option is to create it at the start of main(), and clean up when main() exits. Your device_map has static lifetime, and that’s all you need. Just put the devices in it, and forget all that handle/view nonsense.

If you also want reference counting and automatic clean-up, fine… but think more carefully about what that means. If devices are being “populated somewhere” before actually being used, then how is anything to know whether they are in use or not? How is anything to know whether a device is safe to delete, or whether it was just “populated” and hasn’t been used yet?

It's not thread safe

Making ref atomic does not make operations on Handle as a whole atomic. Consider a case where ref is 1, and a thread calls handle_dec_ref(). It the executes:

if (--handle->ref == 0) {
    std::cout << "Deleting handle\n";

Then at this point the thread might be interrupted by another thread, which calls handle_inc_ref(), and starts using the object. But then the first thread continues and executes:

    device_map<T>.erase(handle->id);

Then the second thread think it has a valid pointer to an object which has been deleted.

You have to use a std::mutex here that makes the whole operation atomic. That means the mutex must guard any access to device_map.

A slightly different approach

A big problem here is that you not only have Handle and View, but device_map as well. What if Handle would be able to take care of allocating and deleting a T itself?

template <typename T>
struct Handle {
    std::mutex mutex;
    std::size_t refcount{};
    std::optional<T> device;

    struct View {
         Handle* handle;

         View(Handle* handle): handle(handle) {}

         ~View() {
             handle->put();
         }

         T* operator->() {
             return &*handle->device;
         }
         …
    };
 
    View get() {
        std::lock_guard lock(mutex);
        if (refcount++ == 0)
            device.emplace();
        return View(this);
    }

    void put() {
        std::lock_guard lock(mutex);
        if (--refcount == 0)
            device.reset();
    }
};

A possible use is then:

int main()
{
    /* Does not create a `Led` yet */
    Handle<Led> led1;

    {
        auto led = led1.get();
        led->on();
    }
}

The advantage is that there is no more device_map and std::string identifiers, but just regular variable names. And the device now actually lives outside of the heap, instead of with your solution where they were still allocated on the heap by the std::unordered_map device_map.

Note that you can still create a std::unordered_map<std::string, Handle<T>> from this, it just won't remove elements from the map automatically when the handle's reference count drops to zero.

Make your types safer

Your structs have no private data members. It's therefore easy to modify the member variables and cause incorrect behavior. Make everything a class, and only make things public if strictly necessary.

I would also hide device_map away, for example by making it a static inline member of Handle, but even better is just removing it entirely.