auto classes and finalizers

[kris]

Georg Wrede wrote:
[snip]

> So much for "regular" instance deletion. Then, we have the case where 
> the instance "owns" some scarce resource (a file handle, a port, or some 
> such). Such instances should be destructed in a _timely_ fashion _only_, 
> right?
> 
> In other words, instances that need explicit destruction, should be 
> destructed _at_the_moment_ they become obsolete -- and not "mañana".
> 
> It is conceivable that the "regular" instances do not have explicit 
> destructors (after all, their memory footprint would just be released to 
> the free pool), wherease the "resource owning" instances really do need 
> an explicit destructor.
> 
> Thus, the existence of an explicit destructor should be a sign that 
> makes [us, Walter, the compiler, anybody] understand that such an 
> instance _needs_ to be destructed _right_away_.
> 
> This makes one think of "auto". Now, there have been several comments 
> like /auto can't work/ because we don't know the scope of the instance. 
> That is just BS. Every piece of source code should be written 
> "hierarchically" (that is, not the entire program as "one function"). 
> When one refactors the goings-on in the program to short procedures, 
> then it all of a sudden is not too difficult to use "auto" to manage the 
> lifetime of instances.

That was all sounding reasonable up until this point :)

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?