Documentation says "signed a and unsigned b", but function just takes the same type. Could be really fancy and use https://en.cppreference.com/w/cpp/types/is_unsigned with an assert_compile if you like ;)

You know, cppreference.com has become my new favorite website over the last few weeks? It's brilliant!

I decided to go for the best of both worlds; an assert_compile to guarantee we're dealing with arithmetic types, and a runtime assert if unsigned b turns out to be signed after all. If I can make the compiler spit out a warning that b should be an unsigned type, then that's all the better 😉

I also threw in a static_cast to the type of a, since that seems to be the in thing to do with these particular functions.

Instead of "signed a and unsigned b" it should probably say something like "positive values of b" or "b > 0".
T does not strictly have to be signed for the function to return correct results.

All the other related functions use an unsigned type for the divisor; and I have rigged the function to work either way; if it's fed s signed divisor, you'll get a run-time assertion, else a compile-time assertion.

For that matter, it will work with an unsigned dividend, too.

Is there any reason why these functions actually need to be templated? I have been toying with templating all the other related functions; and there's a lot of work to get right. I actually got my abomination to compile; but there's no way to guarantee the resulting program is correct (i.e. choosing generic types of an appropriate width). For instance; if supplied with an rvalue of (byte_x * 100), will the templated type be 8 bits, 16 bits, signed, or unsigned?

Random thought: Do we actually need the complexity and overhead of weak pointers here, or would it be better to place viewport management under the memory pool system, where we already get iteration (and, I assume, automagic memory management) for free?

I don't really see why either of these are necessary. struct ViewPort already has a single owner: struct Window.
Using a std::unique_ptr would make sense.

Resorting to std::shared_ptr creates a lot of unnecessary complexity and overheads. You'd be better off just forgetting about the Viewport pointer cache and iterating the window hierarchy like before.

It is true that neither are strictly necessary so long as the program is correct. It's aimed more as a safeguard for that one obscure case where some part of the program takes a (temporary) reference to a viewport and the window owning it gets deleted. Likewise, there should never be a case of a viewport pointer in the cache being invalid; so long as the program can never delete a viewport while another part of it is iterating through them.

Similar story for the viewport overlays: unless it can be proven that nothing can hold a reference to an overlay beyond the lifespan of its owning viewport, it needs to be a shared pointer for the program to remain correct.

I am happy to use unique_ptrs if it makes sense to do so; I was acting upon @michicc's suggestion to move to automatic memory management.