Odpověď na názor

Velmi zajímavý nápad.

Napadá mě nicméně:
1) Vzhledem k tomu, že je stejně třeba volat pro konstrukci objektu zvláštní verzi operator new(size_t sz, IRuntimeAllocator &a), pak ůže stejně dobře posloužit např. template T * Create(IRunti­meAllocator &a). Pokud bude fce Create napsaná s oddělením alokace a konstrukce objektu T (viz STL), tak není třeba aby všechny třídy poskytovali rozhraní class DynObject, takže celý přístup bude rovněž (zpětně) kompatibilní s externími typy.

2) Co se týká alokátorů v STL tak na nich opravdu nic "zmršeného" nevidím. Pokud už je (výjimečně) opravdu potřeba, aby byl objekt (de)alokován určitou konkrétní instancí alokátoru, pak může být tato (resp. reference na ni) uložena unvnitř Objektu - čímž se vracíme tak trochu zpět k rozhraní DynObject a přicházíme tak o zpětnou / externí kompatibilitu - nebo v mapě Objekt_pointer-Allokator_reference - čímž vzniká určitá režie při (de)alokaci.

p.s.: co se týče tématu "Alokátory a operator new v C++" tak bych osobně spíš normě vytknul, že šla "rozštěpenou" cestou obou přístupů zároveň a ještě k tomu umožnila přetěžovat new jako členskou třídu. Vzniká tak trochu bordel a v podstatě člověk nikdy neví, co externí objekt vlastně dělá při svojí dyn. alokaci. Osobně bych dal naopak přednost pouze objektu Allokator a operatory new a delete vůbec nezaváděl :)