type checking

[Alex Martelli]

Stephen Horne wrote:
   ...
>>By the same token, Java and C# will give few benefits if you already
>>master C++ -- perhaps a little help with memory management to be
>>offset against losing templates, a HUGE loss to adjust to, and such
>>niceties as the "resource allocation is construction" idiom.
> 
> Yes, that is very true. I believe MS are adding generics to C#, but

Generics are also coming in Java (I've lost track of the # of times
i've heard them announced as imminent over the last few years, but
surely ONE of these times it will be true:-).

> with such big changes being planned that just rubs in the fact that C#
> is an immature language resting on an immature library.

Can't say that of Java, yet "generics are coming" applies to both:-).


> I had assumed that the "resource allocation is construction" idiom
> could be applied in any language with both constructors and
> exceptions. There are only two issues that I can think of that would
> seriously affect it...

[then listing 3 of them -- nobody expects the spanish inquisition!-)]

4. the destructor is called when it happens to be called, including
   perhaps never if the garbage collector never needs to reclaim
   _memory_, which is the only resource it directly tracks

C++'s idiom depends on destruction happening _at once_ for
automatic variables going out of scope:

    // some preliminaries executed w/o holding the lock
    {
        LockHolder holder(thelock);

        // the guts, executed while holding the lock
    }

with LockHolder's ctor calling the acquire, and its dtor the
release, for the lock being held; making the whole idiom roughly
equivalent to, but handier than, Java's or Python's try/finally.

If holder's destructor is liable to be called hours later when
the GC needs it to recover a little memory, the idiom is no use.

> rely on. For instance, what happens if you need to access one of those
> resources before the GC frees it.

Exactly.

> In Python, it doesn't seem to be an issue - presumably because Pythons
> garbage collection is based on reference counting so destruction
> happens immediately when the last reference has gone. I'm not sure
> what happens when there are reference cycles, though - I know Python
> handles them, but I'm not sure if they delay the garbage collection.

Yes, they do (delay the GC, and perhaps delay it indefinitely, since,
in particular, reference loops including objects with __del__ are NOT
unraveled -- the GC punts on the need to call the __del__'s in some
order it cannot possibly infer).

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees.  So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).


> Hmmm - a thought provoking issue. Thanks for pointing it out.

You're welcome!


Alex