Memory Safety without a GC or Ref Counting

TommiT tommitissari at hotmail.com
Fri Jan 25 03:28:15 PST 2013


On Monday, 21 January 2013 at 17:37:38 UTC, F i L wrote:
>     type Foo
>     {
>         var bar = 0
>     }
>
>     func main
>     {
>         ref f : Foo
>         ref b : int
>
>         scope
>         {
>             var foo = Foo # allocates Foo
>
>             f => foo      # f points to foo
>             f.bar = 1     # foo.bar = 1
>
>             b => f.bar    # b points to foo.bar
>             b = 3         # foo.bar = 3
>
>             # auto 'clean up code' at end of scope:
>             #
>             #     Memory.delete(foo)
>             #     f => null
>             #
>         }
>
>         f.bar = 4 # ERROR: f is null

I think there should be also b => null in the implicit 'auto 
clean up' phase.

I think it's good to note whether errors are compilation errors 
or runtime errors. I assume f.bar = 4 in the end there would be a 
compilation error?


On Friday, 25 January 2013 at 02:12:56 UTC, F i L wrote:
>     var nums = int[] # DynamicArray(int)
>     ref a, b : int
>
>     func main
>     {
>         nums += 1 # allocate
>         nums += 2 # allocate
>         nums += 3 # allocate
>
>         a => nums[2] # nums.=>(2, a)
>         b => a       # nums.=>(2, b)

What if we now (after the code snippet above) write:

nums += 4

And nums has run out of room in its place in the heap and needs 
to re-allocate its data (4 ints now). I guess that would mean 
that the call += should nullify all refs pointing to nums (a and 
b). If we now write:

a = -3

...that can't be a compilation error. Because it's not known at 
compile-time whether or not nums += 4 forces a re-allocation. 
Wouldn't this mean then, that all accesses through references 
would require a runtime penalty for checking whether the ref is 
null or not?


More information about the Digitalmars-d mailing list