Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for non-owning deferred_ptr #16

Open
ratchetfreak opened this issue Sep 28, 2016 · 5 comments
Open

Support for non-owning deferred_ptr #16

ratchetfreak opened this issue Sep 28, 2016 · 5 comments

Comments

@ratchetfreak
Copy link

Will there be support for non-owning deferred_ptrs that will not prevent objects being destroyed (don't participate in the mark phase) but will get nulled when the object they refer to gets destroyed? Like the semantics of a weak pointer in garbage collection.

@hsutter
Copy link
Owner

hsutter commented Sep 29, 2016

Yes, I intend to add that eventually because it's natural to want a weak version of a strong (shared) pointer type.

I'll probably put it off for a while as it's lower on the priority list, but I'll keep this issue open as a reminder.

@lichray
Copy link

lichray commented Oct 7, 2016

How about returning a shared_ptr with a customized dtor?

@hsutter
Copy link
Owner

hsutter commented Oct 7, 2016

How about returning a shared_ptr with a customized dtor?

@zhihao: shared_ptr is an owning strong pointer, not a non-owning weak pointer, so users would expect it to keep the object alive. Also, the layout is incompatible – flavors of either shared_ptr or weak_ptr wouldn’t work because copying either one tries to access a reference count control block which doesn’t exist. The reason a different pointer type than shared_ptr was needed is because shared_ptr doesn’t have the copying and destruction properties needed, and the deleter doesn’t support sufficient customization to try to shoehorn it in.

@lichray
Copy link

lichray commented Oct 7, 2016

I see. I kind of want to save some types so that people can gain some homogeneity in containers etc. Well.

@hsutter hsutter added this to the Future - Backlog milestone Nov 27, 2016
@hsutter
Copy link
Owner

hsutter commented Nov 27, 2016

Thanks again for this suggestion. For now I'm waiting for feedback and bug reports from actual use of the library, and deferring enhancements and optimizations until then but keeping them in the backlog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants