You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of an open question. Right now the higher level abstractions use a UniquePtr to hold a reference to the inner FFI types for opencascade.
This works, but then it becomes harder to clone and use shapes in multiple contexts. I'm not sure yet if we desire that functionality, but maybe shared_ptr makes more sense for holding those FFI pointers.
I can imagine scenarios where we'd want to store references to intermediate shapes that are created, perhaps stored in multiple parts of the model code that get referenced later when building new shapes on top of them. shared_ptr might be better suited to a scenario like that.
The text was updated successfully, but these errors were encountered:
This is more of an open question. Right now the higher level abstractions use a
UniquePtr
to hold a reference to the inner FFI types for opencascade.This works, but then it becomes harder to clone and use shapes in multiple contexts. I'm not sure yet if we desire that functionality, but maybe shared_ptr makes more sense for holding those FFI pointers.
I can imagine scenarios where we'd want to store references to intermediate shapes that are created, perhaps stored in multiple parts of the model code that get referenced later when building new shapes on top of them.
shared_ptr
might be better suited to a scenario like that.The text was updated successfully, but these errors were encountered: