Thanks, Miguel, for your response.

> On Nov 10, 2020, at 3:54 AM, Miguel Ojeda <miguel.ojeda.sandonis_at_[hidden]> wrote:
>
> On Tue, Nov 10, 2020 at 4:28 AM Kyle Knoepfel via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> This can be helpful for flagging expensive operations at runtime, poor library use, etc.
>
> It sounds useful for quick printout-style debugging, although those
> example use cases need more detail. How would you use `memory_use` for
> flagging expensive operations or detect poor library use?

The STL supports utilities for tracking time spent in particular algorithms (through <chrono>, which does much more than that, of course). For example:

auto start = std::chrono::steady_clock::now();
foo();
auto stop = std::chrono::steady_clock::now();
std::cout << "Time spent in foo: " << (stop - start).count() << '\n';

The motivation here would be to do something similar, but for memory use:

user_plugin* plugin = create_plugin();
auto start_mem = std::memory_use(plugin);
plugin->execute(...);
auto stop_mem = std::memory_use(plugin);
std::cout << "Heap memory increase attributed to plugin: " << (stop_mem - start_mem).heap << '\n';

>> So the reported memory wouldn't necessarily correspond to what the object is responsible for, but rather what memory is attributed in anyway with that object.
>
> I think it is more clear if it is only implemented for containers and
> other RAII classes wherever it may make sense. For raw pointers, there
> is no way to tell how much memory might be allocated behind them, if
> any, unless you ask the allocator.

Yes, I think I understand what you mean. I'm curious whether the ideas above can be focused a bit more to provide something useful as opposed to something too general. Perhaps targeting containers is the right approach.

Thanks again for your thoughts,
Kyle