auto classes and finalizers

[Dave]

In article <e1c9tc$p14$1 at digitaldaemon.com>, Mike Capp says...
>
>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
>

That's a mssing part of the puzzle - up until now IMO the changes to the
compiler would have been minimal to support "only autos can have dtors".

Now it would require another change to the language in that 'auto' is not
currently allowed for module scope classes. To support that, I guess there would
have to be code inserted along the lines of module static dtors for auto class
objects declared at module scope (except it would have to also check that each
class had been actually instantiated, obviously).

Then I guess there would be good potential for circular reference problems like
there is for module ctors and dtors with imported modules. So the compiler would
then have to insert runtime checks like it does for module ctors now, which make
things yet more complicated.