nullptr as unique_ptr with Deleter about memory HOT 12 CLOSED

Oh, so you want to have a default constructor for allocator_deleter?

from memory.

Basically yes :), such that I can set the m_data member to nullptr? Maybe its the wrong approach ?

from memory.

I'm not quite sure why you need it, the constructor you've shown takes an allocator anyway.

from memory.

Jeah, exactly, but I want to get rid of this shared_ptr -> I want a CTOR BinaryBuffer() == empty buffer which makes m_data = nullptr but its not that easy because of the deleter.

from memory.

I see. But is there a way to modify the deleter of a smart pointer?

from memory.

What I need is

std::unique_ptr<uint8_t[], Deleter> p(nullptr, Deleter{});
p = foo(); // move assigns to p,  p has now a valid deleter, copied from the return value

This is essentially a very related question on SO: https://stackoverflow.com/questions/35317344/unique-ptrs-assignment-operator-copies-a-deleter-stored-by-a-reference-is-it-a
Hm... might std::reference_wrapper help?

from memory.

If I see correctly: allocator_storage<reference_storage<RawAllocator>, Mutex> is the allocator_reference. If get_allocator in allocator_storage would return a pointer, then we could have a default ctor. The allocator_storage::storage_policy::get_allocator returns a reference, what about returning a pointer?
If that pointer is nullptr, the deleter does nothing

void allocator_storage::deallocate_node(void* ptr, std::size_t size,std::size_t alignment) FOONATHAN_NOEXCEPT
{
    std::lock_guard<actual_mutex> lock(*this);
    auto*  alloc = get_allocator();
    if(alloc)
    {
                traits::deallocate_node(alloc, ptr, size, alignment);
    }
}

If that still fits the design of wrapping a deleter around a RawAllocator concept, i dont know?

from memory.

Some thoughts: The standart says: http://eel.is/c++draft/unique.ptr#single.dtor

Effects: If get() == nullptr there are no effects. Otherwise get_­deleter()(get()).

So the deleter is not called if it is nullptr, so I suppose, we can store an empty deleter in it.

from memory.

sounds awesome, thanks!

from memory.

I have a related question: I store my allocator in the BinaryBuffer as a smart pointer (to make sure it always exists)
Is there already a way of having an allocator_storage which stores a shared_ptr of a RawAllocator. Meaning, the deleter will store not a reference but a std::shared_ptr inside, removing the need to keeping the allocator next to my m_data member.

//! Constructor for a meaningful buffer!
    BinaryBuffer(std::size_t bytes, std::shared_ptr<RawAllocator> allocator)
        : /*m_allocator(allocator) not needed anymore*/ 
        , m_data(foonathan::memory::allocate_unique<uint8_t[]>(allocator, bytes))
// ------------------------------------------------------------->*
//---------------------------------------------------------std::shared_ptr
        , m_bytes(bytes)
    {
    }

from memory.

Yes, you can write your own StoragePolicy (see the documentation for requirements). However, I won't add one using shared_ptr to the library, as I don't think it's an ideal solution. Usually you just have global variables or allocators in a top level function.

from memory.

ok thats true, also better, to be sure where its central location is, instead of wrapping it inside a deleter, hiding it

from memory.