Я имел ввиду пример использования. 

Т.е., допустим, есть жалоба от потенциального пользователя что использование моей штуковины неудобное.

Я не знаю как можно придумать удобнее, сохранив при этом обобщённость:
============================================================================================
garbage::collector cleaner;

...
AnyType* ptr = cleaner.push<garbage::del_single>(new AnyType);
...
AnotherType* array = cleaner.push<garbage::del_array>(new AnotherType[size]);
...
SpecialType* something = cleaner.push<special_clean_array>(special_alloc(SpecialType));
============================================================================================
Если есть идеи, как можно упростить это или сделать более наглядным, буду благодарен... 

Добавлено @ 22:55

traits не подходит по той причине что я могу захотеть удалять указатель на один и тот же тип разными способами.

Т.е.
int* ptr = cleaner.push<garbage::del_single>(new int);
int* array = cleaner.push<garbage::del_array>(new int[size]);

Добавлено @ 22:59
Я переписал утилитку, gcc не хотел собирать (новая версия в первом посте). Получилось даже лучше. Я так же изменил способ хранения указателей на объекты на максимально лёгкий, какой смог придумать. Теперь сборщик уступает scoped_array (для целей локальной автоуборки) только виртуальными вызовами деструкторов. Это плата за универсальность. Хотя, было бы неплохо от этого избавиться. Но как это сделать не меняя способа использования, я не знаю.

Это сообщение отредактировал(а) Леопольд - 30.6.2009, 23:03

Можно поподробнее? Ничего же не понятно...

мне вот прежде всего непонятно, зачем нужен такой контейнер, да еще и локальный.
не проще ли было бы просто пользовать обертку для каждого объекта отдельно ?

так у тебя там и нет особой обобщенности, все довольно жестко задается на этапе компиляции...
например, у меня есть класс - пулл объектов, в котором я выделяю память, допустим, для удаления объекта, нужно вызывать метод free пулла, и передать в него указатель на объект, который нужно удалить.. допустим, в программе может быть несколько таких пуллов
в этом случае, твой deleter должен получать ссылку или указатель на пул объектов, из которого нужно этот объект потом удалить, с твоим кодом это сделать не получится, следовательно он не гибок  

во первых, ты объединяешь множество не связанных операций в одну операцию, это уже не правильно
во вторых, у тебя объекты могут удалятся в произвольном порядке, это зависит от того, как их добавлять, если порядок удаления важен, то это может вызвать сложности


это уже извращение, для массивов есть vector  
к тому-же, если у тебя объект одного типа удаляется несколькими разными способами, то это уже ошибка, лучше всего делать так, что-бы можно было на этапе компиляции однозначно определить как удалять объект, к примеру, если у тебя есть класс Foo, и он может быть создан в куче или с помощью специализированного менеджера памяти(и удаляться с помощью него), то во втором случае, лучше использовать какой-нибудь смарт поинтер вместо обычного указателя, что-бы можно было определить на этапе компиляции, как удалять объект.  
я сделал-бы это так:

ничего не напоминает?  

Это сообщение отредактировал(а) Lazin - 1.7.2009, 08:50

каких именно несвязанных операций и почему они несвязанные?
объекты удаляются в порядке обратном созданию.

Вот ещё одно извращение 


Добавлено через 1 минуту и 56 секунд

Напиши пожалуйста интерфейс пула, а я попытаюсь им воспользоваться...

Это сообщение отредактировал(а) Леопольд - 1.7.2009, 09:17

они удаляются в порядке, обратном вызовам ф-ии push  
если у меня есть объекты А и Б и я хочу, что-бы они были удалены после выхода из scope, то зачем-то создается список, в котором лежат указатели на А и Б(это как минимум два выделения памяти в куче), хотя достаточно пары стековых объектов?
почему удаление объектов А и Б должно для меня выглядеть как одна операция, хотя это 2 операции не связанные между собой? 

Добавлено через 5 минут и 10 секунд




создание


удаление

Т.е. получается что С++ изначально имеет изъян, потому что позволят это делать...  Почему ты считаешь что между типом объекта и способом выделения и освобождения памяти должна быть настолько жёсткая связь? Если это идиома, или code rule, то объясни, пожалуйста, её выгоды.

А разве это не так? Если у тебя объект Foo* можно удалить 2мя способами, то как черт возьми я могу понять, глядя на этот указатель, как мне его удалить, не проследив его жизненный путь до момента создания? Ты хотел-бы разбираться потом в таком коде? Я - нет.

не согласен


Лучше предъявить требование, чтоб создание  и удаление были в "пределах видимости" программиста, что в принципе соблюдается у Леопольда:

операция удаления "выбрана" рядом с операцией создания.


Леопольд, но все же зачем

тоесть вместо garbage_container ипользовать garbage_object.

Это сообщение отредактировал(а) mes - 1.7.2009, 10:07

никто не мешает мне передать в метод push что угодно  

мотивируй

с этим согласен, но это решается путем объеденения создания/удаления в один аллокатор.
и если избавиться от контейнера, то интерфейс создания объекта будет такой

где в принципе этот аллокатор можно поставить по умолчанию:




Объекту не желательно знать о способе своего создания и хранения. Для этого есть врапперы (такие как умные указатели) которые задают нужную политику.





Это сообщение отредактировал(а) mes - 1.7.2009, 12:08

я именно об этом и говорил

  


Cpp позволяет очень многое(и именно с этим связаны многие трудности с его освоением), но это не является изъяном.
Просто он (cpp) полагается на то, что свобода выражения превыше жестких рамок. 

Это сообщение отредактировал(а) mes - 1.7.2009, 13:38

кстати, стоит отметить, что сабж - вовсе не сборщик мусора