Struct beeing moved around

[Michel Fortin]

On 2011-05-21 05:44:58 -0400, Benjamin Thaut <code at benjamin-thaut.de> said:

> 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?

Not that I know of. There has been some work to make scanning certain 
parts of the memory precise to reduce false pointer issues, but not for 
the stack though.
<http://d.puremagic.com/issues/show_bug.cgi?id=3463>

I don't see many solutions to your problem in the current state of 
things. Assuming the language doesn't change to accommodate your need 
you could add one level of indirection for your stack references and 
update that indirection instead. But that's probably not very 
satisfactory.

I think you should at least fill an enhancement request in bugzilla for 
move-constructors (or at least the ability to disable moves and force 
it to do construct/assign/destruct instead) with an explanation of your 
use case.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/