Struct beeing moved around

[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.

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