On 2011-05-21 05:44:58 -0400, Benjamin Thaut <[email protected]> said:
Am 20.05.2011 22:57, schrieb Michel Fortin:
On 2011-05-20 14:46:03 -0400, Benjamin Thaut <[email protected]> said:
Am 20.05.2011 19:51, schrieb Michel Fortin:
On 2011-05-20 13:36:58 -0400, Benjamin Thaut <[email protected]>
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
[email protected]
http://michelf.com/
