auto classes and finalizers

[kris]

Mike Capp wrote:
> In article <e1c6vl$moj$1 at digitaldaemon.com>, kris says...
> 
>>I think we can safely put aside the entire-program-as-one-function as 
>>unrealistic. Given that, and assuming the existance of a dtor implies 
>>"auto" (and thus raii), how does one manage a "pool" of resources? For 
>>example, how about a pool of DB connections? Let's assume that they need 
>>to be correctly closed at some point, and that the pool is likely to 
>>expand and contract based upon demand over time ...
>>
>>So the question is how do those connections, and the pool itself, jive 
>>with scoped raii? Assuming it doesn't, then one would presumeably revert 
>>to a manual dispose() pattern with such things?
> 
> 
> Two different classes. A ConnectionPool at application scope, e.g. in main(),
> and a ConnectionUsage wherever you need one. Both are RAII. ConnectionPool acts
> as a factory for ConnectionUsage instances (modulo language limitations) and
> adds to the pool as needed; ConnectionUsage just "borrows" an instance from the
> pool for the duration of its scope.
> 
> cheers
> Mike

Thanks!

So, when culling the pool (say, on a timeout basis) the cleanup-code for 
the held resource is not held within the "borrowed" dtor, but in a 
dispose() method? Otherwise, said dtor would imply raii for the borrowed 
connection, which would be bogus behaviour for a class instance that is 
being held onto by the pool? In other words: you'd want to avoid 
deleting (via raii) the connection object, so you'd have to be careful 
to not use a dtor in such a case (if we assume dtor means raii).

What I'm getting at here is a potential complexity in the implementation 
of pool-style designs. Perhaps not a big deal, but something to be 
learned anyway? And it retains a need for the dispose() pattern?

I /think/ I prefer the simplicity of removing dtor invocation from the 
GC instead (see post "GC and dtors ~ a different approach?"). How about you?