Re: Have the Itanium critics all been proven wrong?

[Brian Drummond <brian@shapes.demon.co.uk>]

On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:

> On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:

[... discussion of private types exported to module A from B]
>> This puts B in charge of the object lifetimes; if A wants to access a
>> stale object, expect an exception.
> 
> Exception, if I am lucky.
> If I am less lucky, the physical place of old auto object is now
> occupied by new auto object of the same or compatible type and the call
> to accessor caused silent corruption.

If a module has exported a pointer to an "auto object" then the 
accessibility checks have been circumvented by unchecked_access or 
unchecked_conversion. In which case ... yes, caveat programmer!

Pointers passed from a module will generally be to static or dynamic 
objects. Which, if dynamic, can be freed by unchecked_deallocation.
Again : caveat programmer. 

One benefit of the private type, forcing all accesses to an object being 
through its own methods, is that B can be implemented as a "controlled 
type", which allows B's programmer to make such mistakes less common.
For example, B's object may be reference counted, and only freed after 
all its handles are released. (And yet a pathological A may cheat, and 
access it after release.)

Controlled types could probably be used as the basis for a garbage 
collector.

>> > But is not such GC
>> > significantly less efficient than GC aided by compiler?
>> I don't know that would generally be the case. If you need GC, you may
>> often be able to structure the application to gain some advantage from
>> its properties; ...

> That's not a good argument.
> Compiler-supplied GC can also provide hint interface, like
> Compact_righ_now, Please_do_not_compact_if_you_dont_have_to.

True. If the GC implementor has foreseen the pattern you need or 
something close enough, then compiler-provided GC would probably be more 
efficient. 

- Brian