On Sat, Oct 12, 2024 at 2:29 PM Jonathan Wakely wrote:
>
> Using it with new would also mean the objects are not going
> to be destroyed either, that's potentially more than just a
> memory leak.


The function, std::deliberate_leak, could have a constraint on it:

    template<typename T> requires is_trivially_destructible_v<
remove_cvref_t<T> >
    void deliberate_leak(T*);

But then you might want to use it on a class which is not trivially
destructible. If you have such a class in mind, and if you're sure
that its destructor only closes files and deallocates memory, then
perhaps we can have a form which allows the elision of destructors:

    template<typename T, bool elide_destruction = false>
    void deliberate_leak(T*);

    template<typename T> requires is_trivially_destructible_v<
remove_cvref_t<T> >
    void deliberate_leak<T,false>(T*);

    template<typename T>
    void deliberate_leak<T,true>(T*);

std::deliberate_leak would be most useful when dealing with
allocations that happen in 3rd party libraries. Let's say for instance
you have a proprietary DLL file which exports a function something
like:

    WindowManager CreateWindowManager(void);

Well then you could use it as follows:

    int main(void)
    {
        WindowManager *const wm = CreateWindowManager();
        std::deliberate_leak( wm->fonts ); // The 3rd party lib
never deallocates the fonts
    }

This would mean you don't get false positives in your memory
debuggers, such as the one built into the GNU compiler (which I really
like), or valgrind.