Memory Safety without a GC or Ref Counting

[F i L]

F i L wrote:
> [...code...]
>     global_foo = getFoo()
> [...code...]

Typo, that should have been:

     global_foo => getFoo()




H. S. Teoh wrote:
> [...] because the concept has limitations:
>
> 1) It required code to be manually written to deal with owner 
> pointers
> correctly (auto_ptr mostly made this automatic, but it is 
> certainly NOT
> a drop-in replacement for pointers);

I don't do a whole lot of C++, so I don't know a lot about their 
smart_ptr types, however, I doubt you could do anything like my 
idea in C++ (without a lot of extra syntax like you described) 
since it requires a lot of automatic per-scope bookkeeping I 
doubt C++ types alone could accomplish.


> 2) It can't deal with cyclic structures correctly;

That's why there would be a 'ptr' type :)


> 3) It is still unsafe: you can have a dangling reference to 
> owned
> memory, because the owner pointer goes out of scope and the 
> memory gets
> deallocated, but there can still be references lingering around
> somewhere.

This is why there would need to be a lot of magic happening in 
the compiler. When the compiler can't know, for sure, weather a 
reference that was assigned to a local-scope var is *still* 
referencing that var at the end of the scope (pretty common), 
then it asks before setting assigning to null. If the compiler 
can't determine, at all, which refs will be pointing to a 
particular local-var, it falls back to regular ref-counting (for 
the var in question).

I've given it a bit of thought, and while runtime checks and even 
regular ref-counting wouldn't be too uncommon, due to it's 
var/ref design there would be a great many places where the 
compiler could optimize away all the runtime checks and you 
normally wouldn't have to deal with the cyclic-ref problem 
ref-counting memory-management usually bring to the table 
(granted ptr's aren't much better). Also, I can't remember 
exactly, but because var's are tied to scopes, I think there's 
more optimization that can happen with ref-counting because it 
happens at the scope level... more thoughts needed here though.

One benefit of this I forgot to mention is that, like 
ref-counting, memory is deterministic (with optional 
late-collection). That wou


Thanks for your feedback!




Arne wrote:
> I haven´t found any hole or improvement suggestion yet, my only 
> comment is, I`d really love to use a system like this.

Me too! Let me know if you think of any flaws.




Jacob Carlborg wrote:
> Seems a bit like ARC (Automatic Reference Counting) that Clang 
> has implemented for Objective-C (and some C libraries on Mac OS 
> X). The compiler automatically inserts calls to "retain" and 
> "release" where appropriate.

Interesting, I will have to look into that. Thanks for the info.