Struct beeing moved around

[Benjamin Thaut]

Am 20.05.2011 22:57, schrieb Michel Fortin:
> On 2011-05-20 14:46:03 -0400, Benjamin Thaut <code at benjamin-thaut.de> said:
>
>> Am 20.05.2011 19:51, schrieb Michel Fortin:
>>> On 2011-05-20 13:36:58 -0400, Benjamin Thaut <code at benjamin-thaut.de>
>>> said:
>>>
>>>> What if I need a value type that may be copied, but may not be moved?
>>>
>>> I don't think that's possible. Why would you want that?
>>
>> [...]
>>
>> If there is no garantuee that a struct stays on the same memory
>> location within 1 Stack frame, you pretty much can not implement a
>> other GC unless you hack into the compiler.
>
> But... is that a real problem or just something you've come up with to
> argue that a move constructor can be useful? I ask because it looks
> pretty synthetic: if you're going to call something alike
> GC.addRoot/GC.removeRoot upon construction and destruction of this smart
> pointer you could as well implement standard reference counting. And
> reference counting does not need a move constructor since moving doesn't
> change the reference count.
>
> But this is an interesting topic. I'm currently hacking the compiler to
> support Objective-C objects. As part of this I want the memory to be
> managed automatically, which isn't so easy because Objective-C objects
> have to live in a separate heap. So I'll need to add support for an
> external memory management system and make it work seamlessly with the D
> GC. I already know how I'm going to implement it, and it won't require
> anything like a move constructor.
>
This is acutally a real problem. I'm currently implementing a Baker GC 
for the Lisp VM I'm implementing in D 2.0. A Baker GC needs to know 
exactly where the pointers are located, because it needs to change the 
pointers during collection. I'm only doing the GC.addRoot/GC.removeRoot 
for refernces that are allocated on that Stack. Not for every reference. 
And reference couting is not sufficient, because it does not break 
cycles. As the GC needs to change the pointers, I would need a move 
constructor, so I can update the pointers memory location.

I'm curious, are there plans that D is going to use something that is 
not a Mark & Sweep?
-- 
Kind Regards
Benjamin Thaut