Am 20.05.2011 22:57, schrieb Michel Fortin:
On 2011-05-20 14:46:03 -0400, Benjamin Thaut <c...@benjamin-thaut.de> said:
Am 20.05.2011 19:51, schrieb Michel Fortin:
On 2011-05-20 13:36:58 -0400, Benjamin Thaut <c...@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
