Is there a name for a design paradigm where a class has a static "list of all objects of my own type" member, inserted by the constructor and removed by the destructor, and you can iterate over them for $REASONS?
@azonenberg If it's C++ then a member can't be both static and set up by the constructor of the class it's in. I'm sure you know this but I'm just being pedantic.
We use that pattern a lot though, sometimes just to contain a fixed list of constants, sometimes a collection of pointers to members that have to be visited in some way. So I'd like to know the name for it too.

@kbm0 I think we're describing something different.

It's a static std::set<T> and the constructor does a emplace(this) and destructor erase(this). With appropriate locking if you're multithreading you get a real time snapshot of all of the objects in existence

@azonenberg Ah I see. A global object registry of sorts. Yes totally different, but I get it.

@kbm0 The immediate use case is enumerating all of my GPU memory buffers along with metadata like the debug name for the object, the C++ object type being stored in the buffer, how many elements are allocated and how many used, etc.

Purely as a debug tool for introspection so I can optimize for reduced VRAM usage

@kbm0 Right now I have statistics on how much VRAM I'm using reported by Vulkan, but I don't have any breakdowns for where it's going
@azonenberg I've done something similar in the past with Qt: Because it forces you to new objects all over the place, storage management can get sloppy. Accounting for every object you create in a global collection is much more efficient than debugging with valgrind.
@kbm0 also video memory isn't even something valgrind/asan understand, it's a completely different allocation system

@kbm0 i'm not looking for leaks so much as overallocations, keeping objects around longer than needed, inefficient algorithms, etc.

Right now I just have no visibility

@kbm0 and there should only be a few dozen to a few hundred objects around but each might be hundred of MB to GB (plus some really tiny ones)
@kbm0 in this particular case there's another level of indirection because the enumeration is done by a base class of a templated type, and I want a single list containing all instances of the child type with virtual methods to find out what type any given child is.
@azonenberg As an aside on performance, if your collection is *really* huge you will probably get a slight edge doing type selection with an enumerated field rather than using polymorphism.
@kbm0 I'm not trying to index by type, just display it in a table when debugging
@azonenberg @kbm0 What about a tracing approach? Record alloc/dealloc events and crunch it afterwards?
@taral @kbm0 no i want something I can use dynamically as i manipulate the software and see what changes as i do things
@azonenberg @kbm0 Welp, that's a global object registry, yeah.
@taral @kbm0 i have some wip stuff will post screenshots in the evening