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.
--
Michel Fortin
[email protected]
http://michelf.com/
