4 ms·
Yep. But how would you correctly deal with finalizers in the face of those copies? See my comment a bit deeper in the thread.
by clhodapp 9y ago
Yep. But how would you correctly deal with finalizers in the face of those copies? See my comment a bit deeper in the thread.
- dkersten 9y agoYeah, you're right. I guess it doesn't typically make sense to capture a RAII object and have the copy outlive the original, but it also may not make sense to delay the lifecycle of the original since it breaks the expectation of "i put this on the stack, so expect it to finalize when it goes out of scope". Probably best not to mix the two. That is, a stack-allocated RAII object whose finalizer is called when it goes out of scope, which references some data that can be closed over, with a lifetime separate from the RAII object. At the very least, you would call finalizers on both (the stack one when it goes out of scope and the copy when it gets garbage collected) and then its up to the programmer to make sure that shared resources are finalized correctly (eg by keeping a shared reference count...). (I'm thinking a use case where the object represents some external resource that should be freed only once) Sounds pretty error prone though. I suppose that Java's solution is KISS: simply don't support finalizers on value objects.