Каковы различия между новыми функциями субпулов Ada и пулами пулов?

Question

Я недавно прочитал обоснование 2012 года об итераторах и пулах. Одна из рассмотренных вещей - это новые возможности, касающиеся подпулов, один вопрос, который остался без ответа, - в чем разница между подпулами и пулами пулов - я имею в виду, что, похоже, того же самого [pg.25] можно было бы достичь следующим образом:

-- Minnesota: Land of 10,000 Lakes
type Minnesota(Size: Storage_Count) is new Root_Storage_Pool with private;
type Lake(Size: Storage_Count) is new Root_Storage_Pool with private
     with Storage_Pool => Minnasota;
-- ...
type Pooled is [...] with Storage_Pool => Lake;

Хотя я признаю, что могу быть ужасно неправ, так как я не использовал подпулы, тем более пулы (пока).

Answer 1

От Рэнди Брукардта из Comp.Lang.Ada.

Aspect Storage_Pool применяется только к типам доступа ( 13.11 (15) и другим), а тип Lake не является типом доступа, поэтому это недопустимо (и также не имеет смысла).

Вы могли бы реализовать один пул, поместив другие пулы в его реализацию (скажем, Миннесота здесь, включая массив из 10000 озер:-). Но тогда вам нужно будет выбрать способ, который принадлежит каждому элементу, хм, подпул. И вы бы заново изобрели колесо.

Существует также проблема доработки. Механизм вложенного пула гарантирует, что объекты не переживут свой вложенный пул (указатели на объекты могут пережить вложенный пул, но не сам объект), даже если вложенный пул явно уничтожен рано (так же, как это делает Unchecked_Deallocation). Нет хорошего способа сделать это без языковой поддержки (каждая рукописная реализация подпула, о которой мы говорили, настаивала на том, чтобы из нее не выделялись контролируемые, защищенные объекты или объекты задач, что, очевидно, является ограничением).

Позвольте мне заверить вас, получить это право было трудно и спорным. Это было почти уронено пару раз. Делать это самому не было бы спором (я надеюсь!), Но это было бы все еще трудно. Поскольку ARG уже сделала грязную работу, лучше всего ее использовать.

                                            Randy.