How to resolve objects not owned by shared_ptr? about cppgraphqlgen HOT 5 CLOSED

Interesting, I never noticed the aliasing contructor on std::shared_ptr before.👍🏼

Perhaps because of that, I would always be inclined to make the member a std::shared_ptr as well. I worry that using references (or pointers, which is equivalent for lifetime purposes) would be too error prone, but perhaps there could be an exception for the operation types which requires those to be wrapped in a std::shared_ptr.

I think it would also need to be possible to return a type-erased object wrapper by value then, and that version of the wrapper object would need to somehow make clear that it should never be stored in a std::shared_ptr which could out-live the reference to the contained type.

Alternatively, the resolvers could just flow a std::shared_ptr or std::weak_ptr for the root object down to all of the accessors in service::FieldParams. That wouldn't let you mix and match in your object hierarchy with lifetimes tied to other objects, but you could at least tie the lifetime of all of the aliased member std::shared_ptrs to the executing operation.

from cppgraphqlgen.

I think it would also need to be possible to return a type-erased object wrapper by value then, and that version of the wrapper object would need to somehow make clear that it should never be stored in a std::shared_ptr which could out-live the reference to the contained type.

I don't think I understand the problem. How type-erase object can be returned instead of real object wrapper?

Alternatively, the resolvers could just flow a std::shared_ptr or std::weak_ptr for the root object down to all of the accessors in service::FieldParams. That wouldn't let you mix and match in your object hierarchy with lifetimes tied to other objects, but you could at least tie the lifetime of all of the aliased member std::shared_ptrs to the executing operation.

I've been there. It is a rabbithole of keeping stack of parent objects pushing new ones diving into graph and poping then on the way out.

PS. Migration guide is a bit misleading suggesting that shared_from_this is not essential.

Change your class declarations so that they no longer inherit from the generated object namespace classes. If you need the shared_from_this() method, you can replace that with std::enable_shared_from_this.

Can I safely assume that wrapper of the parent outlives all children wrappers?

from cppgraphqlgen.

I think it would also need to be possible to return a type-erased object wrapper by value then, and that version of the wrapper object would need to somehow make clear that it should never be stored in a std::shared_ptr which could out-live the reference to the contained type.

I don't think I understand the problem. How type-erase object can be returned instead of real object wrapper?

The real object::MemberField wrapper is the type-erased object in this case. I meant that AwaitableObject would need to accept a by-value version of the wrapper to guarantee there aren't any other std::shared_ptr references to it keeping it alive beyond the executing operation.

Alternatively, the resolvers could just flow a std::shared_ptr or std::weak_ptr for the root object down to all of the accessors in service::FieldParams. That wouldn't let you mix and match in your object hierarchy with lifetimes tied to other objects, but you could at least tie the lifetime of all of the aliased member std::shared_ptrs to the executing operation.

I've been there. It is a rabbithole of keeping stack of parent objects pushing new ones diving into graph and poping then on the way out.

Couldn't it all be chained to a single top-level std::shared_ptr so they all share the operation's lifetime? Come to think of it, you might even be able to use the service::RequestState for that without other modifications.

PS. Migration guide is a bit misleading suggesting that shared_from_this is not essential.

Change your class declarations so that they no longer inherit from the generated object namespace classes. If you need the shared_from_this() method, you can replace that with std::enable_shared_from_this.

It's required if you need shared_from_this(), but std::make_shared (or the std::shared_ptr constructors) should still work without it. I don't think it's essential in all cases.

Can I safely assume that wrapper of the parent outlives all children wrappers?

Sort of. The resolver won't hold onto it after it's returned and consumed, but if a user were caching the wrapper objects somewhere between operations with a std::shared_ptr, it might still outlive the reference. I don't think it's provably safe as long the wrapper object is itself in a std::shared_ptr.

from cppgraphqlgen.

Couldn't it all be chained to a single top-level std::shared_ptr so they all share the operation's lifetime? Come to think of it, you might even be able to use the service::RequestState for that without other modifications.

Not all objects are owned by their parent(or by any single object). Graph is evolving in runtime. Some objects have direct parent (like to one held as class member) but others are not. Most of objects are actually held by shared_ptr and lifetime extension works nicely. However it seems a bit overkill to keep all members as shared_ptr even when logically their lifetime is tightly coupled with parent lifetime.
Allowing members (MemberField in this example) outlive their parents breaks too many assumptions.

It's required if you need shared_from_this(), but std::make_shared (or the std::shared_ptr constructors) should still work without it. I don't think it's essential in all cases.

Oh. That makes sense.

Sort of. The resolver won't hold onto it after it's returned and consumed, but if a user were caching the wrapper objects somewhere between operations with a std::shared_ptr, it might still outlive the reference. I don't think it's provably safe as long the wrapper object is itself in a std::shared_ptr.

For now I think I will stick to fake pointers std::shared_ptr<MemberField>(std::shared_ptr<void>{},&member); until I find more elegant solution. I do not plan any wrapper caching. I consider wrappers as library internal objects.

from cppgraphqlgen.

Couldn't it all be chained to a single top-level std::shared_ptr so they all share the operation's lifetime? Come to think of it, you might even be able to use the service::RequestState for that without other modifications.

I might try to build another sample that takes this approach and see how it turns out.

from cppgraphqlgen.