Closed blitz closed 12 years ago
IMO this would be quite unintuitive. Because everyone expects a copy-constructor to actually copy the object. Invalidating the old one with that is a bit strange, so that we should have a really good reason to do that. And I don't see any. If I understood you correctly, the issue of not being able to embed an ObjCap into another one arose only when you wanted to add an Object into Thread that required the Ec cap. The reason was that the construction of thread was done in 2 steps, so that the Ec cap wasn't available in the initializers. I've changed this: https://github.com/Nils-TUD/NRE/commit/e0080faf51eef97bca1b3a4d6fdf81888cf2c5f1. I'll merge it soon into the official repo.
Thanks. Works for me. :-)
Nils Asmussen notifications@github.com wrote:
IMO this would be quite unintuitive. Because everyone expects a copy-constructor to actually copy the object. Invalidating the old one with that is a bit strange, so that we should have a really good reason to do that. And I don't see any. If I understood you correctly, the issue of not being able to embed an ObjCap into another one arose only when you wanted to add an Object into Thread that required the Ec cap. The reason was that the construction of thread was done in 2 steps, so that the Ec cap wasn't available in the initializers. I've changed this: https://github.com/Nils-TUD/NRE/commit/e0080faf51eef97bca1b3a4d6fdf81888cf2c5f1. I'll merge it soon into the official repo.
Reply to this email directly or view it on GitHub: https://github.com/TUD-OS/NRE/issues/21#issuecomment-10360250
Sent from Kaiten Mail. Please excuse my brevity.
The current state is that ObjCaps cannot be copied for various reasons that are listed in ObjCap.h.
I argue for giving them a copy constructor that would immediately invalidate the old copy. Think of unique_ptr semantics.
Benefits are: