So I've been thinking about this problem off and on for awhile,
and I think I have a rather simple solution. I highly doubt I'm
the first to think of it, but haven't found any info about a
similar idea on the net. So in the interest of science I'm
posting it here so anyone interested can attemp
On Mon, Jan 21, 2013 at 06:37:36PM +0100, F i L wrote:
> So I've been thinking about this problem off and on for awhile, and
> I think I have a rather simple solution. I highly doubt I'm the
> first to think of it, but haven't found any info about a similar
> idea on the net. So in the interest of
On Monday, 21 January 2013 at 17:37:38 UTC, F i L wrote:
This isn't really D related, but I usually like the feedback I
get from this community, plus, if there's any value in the
idea, maybe it would be a worth while discussion for future
directions D might make use of.
I haven´t found any
On 2013-01-21 18:37, F i L wrote:
So I've been thinking about this problem off and on for awhile, and I
think I have a rather simple solution. I highly doubt I'm the first to
think of it, but haven't found any info about a similar idea on the net.
So in the interest of science I'm posting it here
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 th
F i L wrote:
... 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.
Ah right I remember. Since vars only ever get collected at the
On Mon, Jan 21, 2013 at 09:27:20PM +0100, F i L wrote:
[...]
> H. S. Teoh wrote:
[...]
> >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
>
Am 21.01.2013 22:25, schrieb H. S. Teoh:
On Mon, Jan 21, 2013 at 09:27:20PM +0100, F i L wrote:
[...]
H. S. Teoh wrote:
[...]
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 sti
On 2013-01-21 19:22:04 +, Jacob Carlborg said:
On 2013-01-21 18:37, F i L wrote:
So I've been thinking about this problem off and on for awhile, and I
think I have a rather simple solution. I highly doubt I'm the first to
think of it, but haven't found any info about a similar idea on the
On Mon, Jan 21, 2013 at 11:36:58PM +0100, Paulo Pinto wrote:
> Am 21.01.2013 22:25, schrieb H. S. Teoh:
[...]
> >Hmm. So you're essentially saying that the compiler will do
> >compile-time analysis of variable usage, and based on that choose the
> >simplest memory management model for it?
> >
> >Th
On 2013-01-22 01:46, Michel Fortin wrote:
And I'll confirm that it's no magic either. Avoiding cyclic references
isn't that easy when you start mixing implicitly retained pointers with
Objective-C's blocks (lambas in C++ or delegate literals in D).
I'm a little sad Apple decided to deprecate it
H. S. Teoh wrote:
The problem is that quite often, the compiler will not be able
to prove
much about the data structure, esp. when you have non-trivial
manipulation of pointers -- it requires solving the halting
problem to
achieve that level of analysis on arbitrary code -- so it will
probably
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
On Friday, 25 January 2013 at 11:28:16 UTC, TommiT wrote:
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 => fo
On Friday, 25 January 2013 at 12:05:42 UTC, F i L wrote:
The issue you raise isn't really a problem though. If the
memory gets rearranged then the runtime could inform the
DynamicArray, and it, in turn, could reassign those refs to the
new memory address.
Oh, of course. By the way, what exa
What if we re-assign a ref variable to another (or same) element
of a DynamicArray:
var nums = int[] # DynamicArray(int)
ref foo : int
nums += 1
nums += 2
foo => nums[0] # nums.=>(0, foo)
foo = 42
foo => nums[1] # nums.=>(1, foo)
Given the definition of DynamicArray's operator =>:
func => (i
On Friday, 25 January 2013 at 13:14:43 UTC, TommiT wrote:
What if we re-assign a ref variable to another (or same)
element of a DynamicArray:
var nums = int[] # DynamicArray(int)
ref foo : int
nums += 1
nums += 2
foo => nums[0] # nums.=>(0, foo)
foo = 42
foo => nums[1] # nums.=>(1, foo)
Give
17 matches
Mail list logo
