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