simplify handling for mixed allocator usage

[olesenm]

Coming back to this (was partly discussed off-line elsewhere). I am looking at supporting the use of umpire for large fields, as well as standard new[] for smaller fields. Now run into the slight problem of needing to handle the deletions differently. This is one idea:

namespace Foam::memoryPool
{

//- Deallocate iff actually managed by Umpire
inline bool deallocate_if(void *ptr)
{
    if (ptr)
    {
        if
        (
            auto& rm = umpire::ResourceManager::getInstance();
            rm.hasAllocator(ptr)
        )
        {
            rm.deallocate(ptr);
            return true;
        }
    }

    return false;
}

} // End namespace Foam::memoryPool

It's not really pretty, but could perhaps be made more efficient if the hasAllocator returned a pointer to the Allocator instead (which could also be tested as bool). Then the code would look like this:

namespace Foam::memoryPool
{

//- Deallocate iff actually managed by Umpire
inline bool deallocate_if(void *ptr)
{
    // Assuming we could have an internal short-circuit for nullptr
    if (auto* handler = umpire::ResourceManager::getInstance().hasAllocator(ptr))
    {
         handler->deallocate(ptr);
         return true;
    }
    return false;
}

} // End namespace Foam::memoryPool

This would avoid calling findAllocatorForPointer twice (not sure how expensive that is).

Thoughts?

[olesenm]

The code using it would then look something like this:

#ifdef USING_UMPIRE
if (!Foam::memoryPool::deallocate_if(ptr))
#endif
{
    delete[] ptr;
}
ptr = nullptr;

@mattijsjanssens

[davidbeckingsale]

We are preparing to move to C++17, once we do, would having getAllocator return a std::optional<Allocator> be an acceptable solution?

[MrBurmark]

Then std::expected in 23?

[olesenm]

We are preparing to move to C++17, once we do, would having getAllocator return a std::optional<Allocator> be an acceptable solution?

This sounds reasonable. Not urgent though.