"Shark8" <
onewing...@gmail.com> wrote in message
news:8fe47d10-1889-43e7...@googlegroups.com...
Aspect Storage_Pool only applies to access types (13.11(15) and others), and
type Lake is not an access type, so this is illegal (and makes no sense as
well).
You could implement one pool by putting other pools within its
implementation (say Minnesota here including a an array of 10000 Lakes :-).
But you'd then have to have a way to select which item belongs to each,
ahem, subpool. And you'd be reinventing the wheel.
There is also the issue of finalization. The subpool mechanism ensures that
objects don't outlive their subpool (pointers to the objects might outlive
the subpool, but not the object themselves), even when the subpool is
explicitly destroyed early (just as Unchecked_Deallocation does). There's no
good way to do that without language support (every hand-written subpool
implementation that we talked about insisted that no controlled, protected,
or task objects be allocated from it, which is obviously limiting).
Let me assure you, getting this right was hard and contentious. It was
nearly dropped a couple of times. Doing it yourself wouldn't be contentious
(I hope!), but it would still be hard. Since the ARG has already done the
dirty work, it's best to use it.
Randy.
Randy.
Randy.