Odpověď na názor

Dále už by to asi bylo na delší diskuzi nad konkrétními potřebami a detaily implementace... Tak jen ještě drobné reakce k několika bodům výše (omlouvám se za délku příspěvku(ů))

* To, že se jedná o zajímavý nápad jsem myslel velmi vážně a ještě dodávám, že je určitě i užitečný.
* Fce Create je v tomhle případě asi taková továrna, jako operátor new itself ;)
- - pardón, já musel... :)
* Problém implicitního konstruktoru lze většinou řešit kopírovacím konstruktorem (allocator::con­struct)
- - nemusí být Váš případ, nebo nemusí být praktické pro Váš případ
* STL alokátory lze instanciovat a taky se to dělá, jelikož žádná z jejich metod neni static. Neřkuli vlastní alokátory.
* Ano, s velikostí bloku při delete je problém. Viz můj povzdech v ps. a Váš povzdech k void operator delete(void *ptr,const DynObjectAlloc­Helper &alloc);
* Virtuální destruktory viz např. http://www.cplusplus.com/reference/std/memory/allocator/destroy/
* S referencí dovnitř objektu jsem se vyjádřil trochu zbrkle. V podstatě jsem měl na mysli Váš allocptr
* používáni alokátorů rozhodně nevede na zprasený neportabilní kód - co celá STL ? (btw std::allokator stejně nakonec volá new a delete)

shrnutí:
Asi jsem se nechal trochu strhnout názvem článku "Alokátory a operator new v C++". Co se týče operátoru new a jeho přetěžování je tenhle článek supr. O Alokátorech toho ale moc neříká. Stále mi tedy připadá nešťastné, že norma zavedla jak operatory new a delete, tak koncept alokátorů (v STL). Osobně bych dal přednost alokátorům, protože zcela abstrahují paměťový model, což:
- právě řeší problém rozštěpené odpovědnosti, tj. přenáší práci s paměťovým modelem výhradně na alokátor a alokované objekty se o to nestarají
- což také zaručuje zpětnou/externí kompatibilitu, což mimo jiné např. zaručuje, že si člověk nemusí psát hned celou podmnožinu STL kontejnerů, kvůli novým paměťovým modelům ;)
- lze alokovat paměť mimo RAM - což je také, proč jsem se o to kdysi zajímal